# Clarifying suspend/resume on i386+SMP



## grigorovl (Mar 31, 2011)

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@ (Apr 6, 2011)

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


----------



## avilla@ (Apr 6, 2011)

jkim@ said:
			
		

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



I am not able to get it working, though.


```
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
```


----------



## grigorovl (Apr 6, 2011)

jkim@ said:
			
		

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


Is it something you plan on implementing by 9.X? Or do we have to wait till 10?


----------



## jkim@ (Apr 15, 2011)

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@ (Apr 15, 2011)

avilla@ said:
			
		

> I am not able to get it working, though.
> 
> 
> ```
> ...



Usually the problem comes from (various) device drivers.  You can start debugging device driver issues without going into sleep state, i.e.,:


```
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:


```
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 (Apr 27, 2011)

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@ (Apr 28, 2011)

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.


----------

