Clarifying suspend/resume on i386+SMP

grigorovl

Member

Reaction score: 3
Messages: 57

I have seen different threads claiming different things. So the question is,

Is it possible in 8.2 to get a working resume in i386 with SMP enabled, with either ACPI or zzz?

I tried and it never wakes, ThinkPad X60, Core Duo, Intel graphics.

(It puzzles me how OpenBSD which is much smaller and doesn't even focus on notebooks, has a working suspend/resume for i386+SMP. I mean, FreeBSD is a much larger project + a greater user base. I mainly use notebooks and not being able to suspend/resume is a huge turn-off. I think many users are staying away from FreeBSD due to this fact. If development was focused on fixing this issue, rather than making PC-BSD (useless without suspend/resume), more users would have been accumulated.)
 

jkim@

Member
Developer

Reaction score: 7
Messages: 20

i386+SMP does NOT support suspend/resume at all. amd64 does.
 

avilla@

Well-Known Member
Developer

Reaction score: 59
Messages: 258

jkim@ said:
i386+SMP does NOT support suspend/resume at all. amd64 does.
I am not able to get it working, though.

Code:
FreeBSD echo.hoth 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r220359:
Tue Apr  5 15:39:25 CEST 2011     root@echo.hoth:/usr/obj/usr/src/sys/HPDV6  amd64
 

jkim@

Member
Developer

Reaction score: 7
Messages: 20

grigorovl said:
Is it something you plan on implementing by 9.X? Or do we have to wait till 10?
It's been on my TODO list for very long time but I couldn't find free time to do the actual work. :-(
 

jkim@

Member
Developer

Reaction score: 7
Messages: 20

avilla@ said:
I am not able to get it working, though.

Code:
FreeBSD echo.hoth 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r220359:
Tue Apr  5 15:39:25 CEST 2011     root@echo.hoth:/usr/obj/usr/src/sys/HPDV6  amd64
Usually the problem comes from (various) device drivers. You can start debugging device driver issues without going into sleep state, i.e.,:

Code:
sysctl debug.bootverbose=1
sysctl debug.acpi.suspend_bounce=1
acpiconf -s 3
If you see any failures, that's really device drivers' fault. Also, video controller may not resume properly, which gives you false impression of resume failures. For video controller issues for console, you can try this:

Code:
kldload vesa
Some video controllers (Intel and NVIDIA) require even more complex resume methods. If that's the case, X.org drivers can help some times.

Good luck.
 

warudemaru

Member

Reaction score: 1
Messages: 30

jkim@ said:
Usually the problem comes from (various) device drivers. You can start debugging device driver issues without going into sleep state, i.e.,:
What is the problem then, if resume works with SMP disabled only? I guess it's the matter of waking up the other core, how can we debug/fix that one? And by the way, if it's that case then is amd64 really different from i386 that it won't work for the latter?
 

jkim@

Member
Developer

Reaction score: 7
Messages: 20

warudemaru said:
What is the problem then, if resume works with SMP disabled only? I guess it's the matter of waking up the other core, how can we debug/fix that one? And by the way, if it's that case then is amd64 really different from i386 that it won't work for the latter?
i386 does not have enough code to wake up APs ("other cores"). amd64 has totally different implementation, which includes waking up APs.
 
Top