On Sunday 29 March 2009 04:13 pm, Gustau Perez wrote: > > Then, it is something else, e.g., acpi_video(4). You can try > > setting debug.acpi.disabled="video" in /boot/loader.conf for > > example. > > > > Jung-uk Kim > > Sorry for the delay. Tried loading acpi_video in > /boot/loader.conf. After having a terminal, I checked the available > mibs with sysctl -a | grep acpi.video. Only get > hw.acpi.reset_video. The man page didn't throw the waited ray of > light :) So, its BIOS does not support ACPI video extension. :-) > I also tried suspending from the terminal, without X's running. > I tried vbetool (dpms off/on and post). I wasn't brave enought to > try vbestate save and restore. It seems many modern graphics boards do not support this function any way. :-( > Finally I decided it was time to use all the arsenal available > :) so I decided to remove everything not necessary. So usb and > friends, firewire, cbb and pccard, if_bge, if_rum, snd_hda and > nouveau were removed from the kernel. Tried going single user mode, > remove them and acpiconf -s 3. Guess what happened :) Let me guess, it worked? ;-) > Checking messages doesn't show anything unsual. But if you want > them or if I can try others things to debug, let me know. If it worked fine, you can try each driver and tell us what breaks suspend/resume process. If you can find the culprit, you can file a PR and you may able to work around it by adding 'kldunload whatever' and 'kldload whatever' from rc.suspend and rc.resume respectively. BTW, bge(4) is already known for suspend/resume problem if my memory serves. Jung-uk KimReceived on Mon Mar 30 2009 - 14:15:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC