Re: Re: Resume failed after Suspend on Thinkpad x201i
2012/8/3 Zack Breckenridge : > First of all, let me note that the Kernel config file I posted was for > 10.0-CURRENT (a few weeks back now though). > > I've been looking into it, but still haven't developed a patch yet. I > have verified that the screen blanking issue, on my hardware, occurs > somewhere in the vm86 mode emulation code (which is how VESA is > implemented on amd64), ultimately called by vesa_bios_post(), which is > called in turn by vesa_load_state() on resume [see: > http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3#L1497]. > vesa_bios_post() ultimately calls x86bios_call() [see: > http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=10#L584] > and emulates the real mode VESA "initialization" code with a call to > x86emu_exec_call(). > > I think in order to figure out whats going on from here I will have to > do some DDB scripting and capture the output. I don't believe remote > debugging will be possible with my hardware (no serial, no > firewire)... Anyway, I'm working on it. > > So to verify that we are having the same issue, you can take the > following steps: > > 1) build a kernel with debugging and VESA enabled: > options VESA > options KDB > options DDB > 2) disable X, boot into the console and issue the following commands: > # sysctl debug.acpi.suspend_bounce=1 > # sysctl debug.kdb.enter=1 > db> break x86emu_exec_call > db> c > # zzz > [you should hit the breakpoint] > db> bt > x86emu_exec_call() ... > vesa_bios_post() ... > ... rest of backtrace ... > db> c > 3) after hitting that last c, your screen should go black. Then you > should be able to type "reboot" and reboot cleanly My screen go black, but type "reboot" no effect. I can be sure to type "reboot" and return. LED status: 1. Disk LED is light, and off at a moment. 2. "Z" LED is light, Battary and power LED is light. 3. Wifi LED is light. > > I'm pretty sure that if you get the same results, we are having the > same issue, though I can make no guarantees. > > When I shutdown from KDE, or type shutdown -p now from console, my laptor can't shutdown complete. The battary LED is light alawys, others LED is off, and vents of the laptor has been blowing hot air. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Re: Resume failed after Suspend on Thinkpad x201i
First of all, let me note that the Kernel config file I posted was for 10.0-CURRENT (a few weeks back now though). I've been looking into it, but still haven't developed a patch yet. I have verified that the screen blanking issue, on my hardware, occurs somewhere in the vm86 mode emulation code (which is how VESA is implemented on amd64), ultimately called by vesa_bios_post(), which is called in turn by vesa_load_state() on resume [see: http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3#L1497]. vesa_bios_post() ultimately calls x86bios_call() [see: http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=10#L584] and emulates the real mode VESA "initialization" code with a call to x86emu_exec_call(). I think in order to figure out whats going on from here I will have to do some DDB scripting and capture the output. I don't believe remote debugging will be possible with my hardware (no serial, no firewire)... Anyway, I'm working on it. So to verify that we are having the same issue, you can take the following steps: 1) build a kernel with debugging and VESA enabled: options VESA options KDB options DDB 2) disable X, boot into the console and issue the following commands: # sysctl debug.acpi.suspend_bounce=1 # sysctl debug.kdb.enter=1 db> break x86emu_exec_call db> c # zzz [you should hit the breakpoint] db> bt x86emu_exec_call() ... vesa_bios_post() ... ... rest of backtrace ... db> c 3) after hitting that last c, your screen should go black. Then you should be able to type "reboot" and reboot cleanly I'm pretty sure that if you get the same results, we are having the same issue, though I can make no guarantees. On Wed, Aug 1, 2012 at 10:07 AM, 乔楚/HonestQiao wrote: > > 2012-07-23 05:45, Zack Breckenridge wrote: > >Attached is the kernel configuration file I used to build my kernel without > >VESA. > > > >I went through the same process as you: setting suspend bounce, etc., and > >looking at the dmesg output. Again, I also looked at the witness output > >from my Intel driver when resuming X -- and I noticed that it simply wasn't > >able to reach the GPU. > > > >So I think it is some sort of bus error on resume and is related to our > >different BIOSes. Since it worked for me, probably some int 10 call in VESA > >was causing the error. In your case - not being able to issue commands to > >an ATA device could also be a bus issue, caused by NOT calling the proper > >INT 10 setup functions on resume. > > > >I'm going to build a debug kernel today and see if I can start tracking the > >problem to it's root. > > > >- Zack > > > > Are you new messages? > My kernel configuration file is similar to your. > But I removed the debugging options. > > Can you list a step to test? > I'll test each side to provide you with full information, which make it easy > to find the problem? ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Re: Resume failed after Suspend on Thinkpad x201i
2012-07-23 05:45, Zack Breckenridge wrote: >Attached is the kernel configuration file I used to build my kernel without >VESA. > >I went through the same process as you: setting suspend bounce, etc., and >looking at the dmesg output. Again, I also looked at the witness output >from my Intel driver when resuming X -- and I noticed that it simply wasn't >able to reach the GPU. > >So I think it is some sort of bus error on resume and is related to our >different BIOSes. Since it worked for me, probably some int 10 call in VESA >was causing the error. In your case - not being able to issue commands to >an ATA device could also be a bus issue, caused by NOT calling the proper >INT 10 setup functions on resume. > >I'm going to build a debug kernel today and see if I can start tracking the >problem to it's root. > >- Zack > Are you new messages? My kernel configuration file is similar to your. But I removed the debugging options. Can you list a step to test? I'll test each side to provide you with full information, which make it easy to find the problem?___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Re: Resume failed after Suspend on Thinkpad x201i
Oops, there was an error with the attachment. Here's a second try. - Zack On Sun, Jul 22, 2012 at 2:45 PM, Zack Breckenridge wrote: > Attached is the kernel configuration file I used to build my kernel > without VESA. > > I went through the same process as you: setting suspend bounce, etc., and > looking at the dmesg output. Again, I also looked at the witness output > from my Intel driver when resuming X -- and I noticed that it simply wasn't > able to reach the GPU. > > So I think it is some sort of bus error on resume and is related to our > different BIOSes. Since it worked for me, probably some int 10 call in VESA > was causing the error. In your case - not being able to issue commands to > an ATA device could also be a bus issue, caused by NOT calling the proper > INT 10 setup functions on resume. > > I'm going to build a debug kernel today and see if I can start tracking > the problem to it's root. > > - Zack > > On Sun, Jul 22, 2012 at 4:36 AM, 乔楚 wrote: > >> 2012/7/20 Zack Breckenridge : >> > If you look at the line: >> > >> > >> >> Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST >> > >> > in your dmesg output, and then grep through the source, you'll find >> this is >> > actually being printed >> > from "src/sys/dev/fb/vesa.c" . >> > >> > I had a similar problem. After syncing with FreeBSD 10-CURRENT and >> compiling >> > a kernel without >> > VESA support, I was able to get graphics to work on resume, but only >> when >> > running X. >> > >> > I don't think you actually have to sync with CURRENT though -- I think >> you >> > just need to compile without >> > VESA. I synced with CURRENT to get the newer Intel GMA driver and KMS >> > subsystem. Also, looking at >> > the Witness output from the Intel driver, it looks like the graphics >> card >> > simply isn't accessible after >> > this function in vesa.c is called, which means it probably causes the >> same >> > problem with your nvidia driver >> > as well. >> > >> > I believe this problem is related to the "x86bios_init_regs" function, >> > though I haven't had time to debug >> > it yet. Also, I'm running amd64. >> > >> > Try it out... >> > >> > - Zack >> > >> > On Fri, Jul 20, 2012 at 1:09 AM, 乔楚/HonestQiao >> wrote: >> >> >> >> >On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch >> >> > wrote: >> >> >> On Wed, Jul 4, 2012 at 4:23 PM, mbsd wrote: >> >> >>> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote: >> >> >> [SNIP] >> >> >> >> In All the test, the screen is light and black, system is hangup, >> >> nothing can be done. >> >> The only thing can be done, is push power button, to force it >> >> shutdown. >> >> >>> >> >> >>> Which graphic card have you used? If you have had nvidia, it's >> normal, >> >> >>> I've had the same problem "the screen is light and black". >> >> >> >> >> >> Can both of you show the output of `devinfo -v` from your systems? >> >> >> >> >> >> I was able to solve my suspend/resume issue with my nvidia-equipped >> >> >> notebook by forcing the module load ordering of vgapm in >> >> >> sys/isa/vga_isa.c: >> >> >> >> >> >> Index: sys/isa/vga_isa.c >> >> >> === >> >> >> --- sys/isa/vga_isa.c (revision 237779) >> >> >> +++ sys/isa/vga_isa.c (working copy) >> >> >> @@ -379,4 +379,4 @@ >> >> >> 0 >> >> >> }; >> >> >> >> >> >> -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); >> >> >> +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, >> >> >> SI_ORDER_ANY); >> >> >> >> >> >> >> >> >> The system requires however that I load the nvidia module in >> >> >> /boot/loader.conf (as opposed to loading it after system is up and >> >> >> running). >> >> >> >> >> >> -Brandon >> >> > >> >> >Oops, the patch above should instead be: >> >> > >> >> >Index: sys/isa/vga_isa.c >> >> >=== >> >> >--- sys/isa/vga_isa.c (revision 238266) >> >> >+++ sys/isa/vga_isa.c (working copy) >> >> >@@ -379,4 +379,4 @@ >> >> >0 >> >> > }; >> >> > >> >> >-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); >> >> >+DRIVER_MODULE_ORDERED(vgapm, vgapci, vgapm_driver, vgapm_devclass, >> >> >NULL, NULL, SI_ORDER_ANY); >> >> > >> >> >I made the edit for the diff on a clean tree, but I'm actually >> >> >building from another :) >> >> > >> >> >The above is correct. However, I'm still not sure this pertains to >> >> >your Intel video problem. >> >> > >> >> >-Brandon >> >> >> >> Yesterday, I upgrade my freebsd to FreeBSD 9.1-PRERELEASE. >> >> This method did not work. >> >> >> >> And command 'shutdown -p now' can shutdown the system, >> >> but the Screen is black and light, and Battery LED is light. >> >> This command can't power off. >> >> >> >> Whethe in: >> >> sysctl -w hw.acpi.reset_video=0 >> >> sysctl -w hw.pci.do_power_suspend=1 >> >> sysctl -w hw.pci.do_power_resume=1 >> >> Or in: >> >> sysctl -w hw.acpi.reset_video=0 >> >> sysctl -w h
Re: Re: Resume failed after Suspend on Thinkpad x201i
Attached is the kernel configuration file I used to build my kernel without VESA. I went through the same process as you: setting suspend bounce, etc., and looking at the dmesg output. Again, I also looked at the witness output from my Intel driver when resuming X -- and I noticed that it simply wasn't able to reach the GPU. So I think it is some sort of bus error on resume and is related to our different BIOSes. Since it worked for me, probably some int 10 call in VESA was causing the error. In your case - not being able to issue commands to an ATA device could also be a bus issue, caused by NOT calling the proper INT 10 setup functions on resume. I'm going to build a debug kernel today and see if I can start tracking the problem to it's root. - Zack On Sun, Jul 22, 2012 at 4:36 AM, 乔楚 wrote: > 2012/7/20 Zack Breckenridge : > > If you look at the line: > > > > > >> Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST > > > > in your dmesg output, and then grep through the source, you'll find this > is > > actually being printed > > from "src/sys/dev/fb/vesa.c" . > > > > I had a similar problem. After syncing with FreeBSD 10-CURRENT and > compiling > > a kernel without > > VESA support, I was able to get graphics to work on resume, but only when > > running X. > > > > I don't think you actually have to sync with CURRENT though -- I think > you > > just need to compile without > > VESA. I synced with CURRENT to get the newer Intel GMA driver and KMS > > subsystem. Also, looking at > > the Witness output from the Intel driver, it looks like the graphics card > > simply isn't accessible after > > this function in vesa.c is called, which means it probably causes the > same > > problem with your nvidia driver > > as well. > > > > I believe this problem is related to the "x86bios_init_regs" function, > > though I haven't had time to debug > > it yet. Also, I'm running amd64. > > > > Try it out... > > > > - Zack > > > > On Fri, Jul 20, 2012 at 1:09 AM, 乔楚/HonestQiao > wrote: > >> > >> >On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch > >> > wrote: > >> >> On Wed, Jul 4, 2012 at 4:23 PM, mbsd wrote: > >> >>> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote: > >> >> [SNIP] > >> > >> In All the test, the screen is light and black, system is hangup, > >> nothing can be done. > >> The only thing can be done, is push power button, to force it > >> shutdown. > >> >>> > >> >>> Which graphic card have you used? If you have had nvidia, it's > normal, > >> >>> I've had the same problem "the screen is light and black". > >> >> > >> >> Can both of you show the output of `devinfo -v` from your systems? > >> >> > >> >> I was able to solve my suspend/resume issue with my nvidia-equipped > >> >> notebook by forcing the module load ordering of vgapm in > >> >> sys/isa/vga_isa.c: > >> >> > >> >> Index: sys/isa/vga_isa.c > >> >> === > >> >> --- sys/isa/vga_isa.c (revision 237779) > >> >> +++ sys/isa/vga_isa.c (working copy) > >> >> @@ -379,4 +379,4 @@ > >> >> 0 > >> >> }; > >> >> > >> >> -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); > >> >> +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, > >> >> SI_ORDER_ANY); > >> >> > >> >> > >> >> The system requires however that I load the nvidia module in > >> >> /boot/loader.conf (as opposed to loading it after system is up and > >> >> running). > >> >> > >> >> -Brandon > >> > > >> >Oops, the patch above should instead be: > >> > > >> >Index: sys/isa/vga_isa.c > >> >=== > >> >--- sys/isa/vga_isa.c (revision 238266) > >> >+++ sys/isa/vga_isa.c (working copy) > >> >@@ -379,4 +379,4 @@ > >> >0 > >> > }; > >> > > >> >-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); > >> >+DRIVER_MODULE_ORDERED(vgapm, vgapci, vgapm_driver, vgapm_devclass, > >> >NULL, NULL, SI_ORDER_ANY); > >> > > >> >I made the edit for the diff on a clean tree, but I'm actually > >> >building from another :) > >> > > >> >The above is correct. However, I'm still not sure this pertains to > >> >your Intel video problem. > >> > > >> >-Brandon > >> > >> Yesterday, I upgrade my freebsd to FreeBSD 9.1-PRERELEASE. > >> This method did not work. > >> > >> And command 'shutdown -p now' can shutdown the system, > >> but the Screen is black and light, and Battery LED is light. > >> This command can't power off. > >> > >> Whethe in: > >> sysctl -w hw.acpi.reset_video=0 > >> sysctl -w hw.pci.do_power_suspend=1 > >> sysctl -w hw.pci.do_power_resume=1 > >> Or in: > >> sysctl -w hw.acpi.reset_video=0 > >> sysctl -w hw.pci.do_power_suspend=1 > >> sysctl -w hw.pci.do_power_resume=1 > >> > >> I can execute acpiconf -s 3, but can't resume the screen which is black > >> and light. > >> > >> Log for command 'acpiconf -s 3': > >> > >> Jul 20 16:06:53 x201i acpi: suspend at 20120720 16:06:53 > >> Jul 20 16:06:56
Re: Re: Resume failed after Suspend on Thinkpad x201i
2012/7/20 Zack Breckenridge : > If you look at the line: > > >> Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST > > in your dmesg output, and then grep through the source, you'll find this is > actually being printed > from "src/sys/dev/fb/vesa.c" . > > I had a similar problem. After syncing with FreeBSD 10-CURRENT and compiling > a kernel without > VESA support, I was able to get graphics to work on resume, but only when > running X. > > I don't think you actually have to sync with CURRENT though -- I think you > just need to compile without > VESA. I synced with CURRENT to get the newer Intel GMA driver and KMS > subsystem. Also, looking at > the Witness output from the Intel driver, it looks like the graphics card > simply isn't accessible after > this function in vesa.c is called, which means it probably causes the same > problem with your nvidia driver > as well. > > I believe this problem is related to the "x86bios_init_regs" function, > though I haven't had time to debug > it yet. Also, I'm running amd64. > > Try it out... > > - Zack > > On Fri, Jul 20, 2012 at 1:09 AM, 乔楚/HonestQiao wrote: >> >> >On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch >> > wrote: >> >> On Wed, Jul 4, 2012 at 4:23 PM, mbsd wrote: >> >>> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote: >> >> [SNIP] >> >> In All the test, the screen is light and black, system is hangup, >> nothing can be done. >> The only thing can be done, is push power button, to force it >> shutdown. >> >>> >> >>> Which graphic card have you used? If you have had nvidia, it's normal, >> >>> I've had the same problem "the screen is light and black". >> >> >> >> Can both of you show the output of `devinfo -v` from your systems? >> >> >> >> I was able to solve my suspend/resume issue with my nvidia-equipped >> >> notebook by forcing the module load ordering of vgapm in >> >> sys/isa/vga_isa.c: >> >> >> >> Index: sys/isa/vga_isa.c >> >> === >> >> --- sys/isa/vga_isa.c (revision 237779) >> >> +++ sys/isa/vga_isa.c (working copy) >> >> @@ -379,4 +379,4 @@ >> >> 0 >> >> }; >> >> >> >> -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); >> >> +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, >> >> SI_ORDER_ANY); >> >> >> >> >> >> The system requires however that I load the nvidia module in >> >> /boot/loader.conf (as opposed to loading it after system is up and >> >> running). >> >> >> >> -Brandon >> > >> >Oops, the patch above should instead be: >> > >> >Index: sys/isa/vga_isa.c >> >=== >> >--- sys/isa/vga_isa.c (revision 238266) >> >+++ sys/isa/vga_isa.c (working copy) >> >@@ -379,4 +379,4 @@ >> >0 >> > }; >> > >> >-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); >> >+DRIVER_MODULE_ORDERED(vgapm, vgapci, vgapm_driver, vgapm_devclass, >> >NULL, NULL, SI_ORDER_ANY); >> > >> >I made the edit for the diff on a clean tree, but I'm actually >> >building from another :) >> > >> >The above is correct. However, I'm still not sure this pertains to >> >your Intel video problem. >> > >> >-Brandon >> >> Yesterday, I upgrade my freebsd to FreeBSD 9.1-PRERELEASE. >> This method did not work. >> >> And command 'shutdown -p now' can shutdown the system, >> but the Screen is black and light, and Battery LED is light. >> This command can't power off. >> >> Whethe in: >> sysctl -w hw.acpi.reset_video=0 >> sysctl -w hw.pci.do_power_suspend=1 >> sysctl -w hw.pci.do_power_resume=1 >> Or in: >> sysctl -w hw.acpi.reset_video=0 >> sysctl -w hw.pci.do_power_suspend=1 >> sysctl -w hw.pci.do_power_resume=1 >> >> I can execute acpiconf -s 3, but can't resume the screen which is black >> and light. >> >> Log for command 'acpiconf -s 3': >> >> Jul 20 16:06:53 x201i acpi: suspend at 20120720 16:06:53 >> Jul 20 16:06:56 x201i kernel: acpi_timer0: switching timecounter, TSC-low >> -> ACPI-safe >> Jul 20 16:06:56 x201i kernel: (ada0:ahcich0:0:0:0): spin-down >> Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for \_SB_.LID_ >> (S3) >> Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for >> \_SB_.SLPB (S3) >> Jul 20 16:07:00 x201i kernel: uhub0: at usbus0, port 1, addr 1 >> (disconnected) >> Jul 20 16:07:00 x201i kernel: ugen0.2: at usbus0 >> (disconnected) >> Jul 20 16:07:00 x201i kernel: uhub2: at uhub0, port 1, addr 2 >> (disconnected) >> Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D0 to D3 >> Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D0 to D3 >> Jul 20 16:07:00 x201i kernel: wlan0: link state changed to DOWN >> Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D0 to D3 >> Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D0 to D3 >> Jul 20 16:07:00 x201i kernel: uhub1: at usbus1, port 1, addr 1 >> (disconnected) >> Jul 20 16:07:00 x201i kernel: ugen1.2: at usbus1 >> (disconnected) >> Jul
Re: Re: Resume failed after Suspend on Thinkpad x201i
If you look at the line: > Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST in your dmesg output, and then grep through the source, you'll find this is actually being printed from "src/sys/dev/fb/vesa.c" . I had a similar problem. After syncing with FreeBSD 10-CURRENT and compiling a kernel without VESA support, I was able to get graphics to work on resume, but only when running X. I don't think you actually have to sync with CURRENT though -- I think you just need to compile without VESA. I synced with CURRENT to get the newer Intel GMA driver and KMS subsystem. Also, looking at the Witness output from the Intel driver, it looks like the graphics card simply isn't accessible after this function in vesa.c is called, which means it probably causes the same problem with your nvidia driver as well. I believe this problem is related to the "x86bios_init_regs" function, though I haven't had time to debug it yet. Also, I'm running amd64. Try it out... - Zack On Fri, Jul 20, 2012 at 1:09 AM, 乔楚/HonestQiao wrote: > >On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch > > wrote: > >> On Wed, Jul 4, 2012 at 4:23 PM, mbsd wrote: > >>> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote: > >> [SNIP] > > In All the test, the screen is light and black, system is hangup, > nothing can be done. > The only thing can be done, is push power button, to force it > shutdown. > >>> > >>> Which graphic card have you used? If you have had nvidia, it's normal, > >>> I've had the same problem "the screen is light and black". > >> > >> Can both of you show the output of `devinfo -v` from your systems? > >> > >> I was able to solve my suspend/resume issue with my nvidia-equipped > >> notebook by forcing the module load ordering of vgapm in > >> sys/isa/vga_isa.c: > >> > >> Index: sys/isa/vga_isa.c > >> === > >> --- sys/isa/vga_isa.c (revision 237779) > >> +++ sys/isa/vga_isa.c (working copy) > >> @@ -379,4 +379,4 @@ > >> 0 > >> }; > >> > >> -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); > >> +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, > SI_ORDER_ANY); > >> > >> > >> The system requires however that I load the nvidia module in > >> /boot/loader.conf (as opposed to loading it after system is up and > >> running). > >> > >> -Brandon > > > >Oops, the patch above should instead be: > > > >Index: sys/isa/vga_isa.c > >=== > >--- sys/isa/vga_isa.c (revision 238266) > >+++ sys/isa/vga_isa.c (working copy) > >@@ -379,4 +379,4 @@ > >0 > > }; > > > >-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); > >+DRIVER_MODULE_ORDERED(vgapm, vgapci, vgapm_driver, vgapm_devclass, > >NULL, NULL, SI_ORDER_ANY); > > > >I made the edit for the diff on a clean tree, but I'm actually > >building from another :) > > > >The above is correct. However, I'm still not sure this pertains to > >your Intel video problem. > > > >-Brandon > > Yesterday, I upgrade my freebsd to FreeBSD 9.1-PRERELEASE. > This method did not work. > > And command 'shutdown -p now' can shutdown the system, > but the Screen is black and light, and Battery LED is light. > This command can't power off. > > Whethe in: > sysctl -w hw.acpi.reset_video=0 > sysctl -w hw.pci.do_power_suspend=1 > sysctl -w hw.pci.do_power_resume=1 > Or in: > sysctl -w hw.acpi.reset_video=0 > sysctl -w hw.pci.do_power_suspend=1 > sysctl -w hw.pci.do_power_resume=1 > > I can execute acpiconf -s 3, but can't resume the screen which is black > and light. > > Log for command 'acpiconf -s 3': > > Jul 20 16:06:53 x201i acpi: suspend at 20120720 16:06:53 > Jul 20 16:06:56 x201i kernel: acpi_timer0: switching timecounter, TSC-low > -> ACPI-safe > Jul 20 16:06:56 x201i kernel: (ada0:ahcich0:0:0:0): spin-down > Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for \_SB_.LID_ > (S3) > Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for > \_SB_.SLPB (S3) > Jul 20 16:07:00 x201i kernel: uhub0: at usbus0, port 1, addr 1 > (disconnected) > Jul 20 16:07:00 x201i kernel: ugen0.2: at usbus0 > (disconnected) > Jul 20 16:07:00 x201i kernel: uhub2: at uhub0, port 1, addr 2 > (disconnected) > Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D0 to D3 > Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D0 to D3 > Jul 20 16:07:00 x201i kernel: wlan0: link state changed to DOWN > Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D0 to D3 > Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D0 to D3 > Jul 20 16:07:00 x201i kernel: uhub1: at usbus1, port 1, addr 1 > (disconnected) > Jul 20 16:07:00 x201i kernel: ugen1.2: at usbus1 > (disconnected) > Jul 20 16:07:00 x201i kernel: uhub3: at uhub1, port 1, addr 2 > (disconnected) > Jul 20 16:07:00 x201i kernel: vga0: saving 4804 bytes of video state > Jul 20 16:07:00 x201i kernel: vga0: saving color palette >
Re: Re: Resume failed after Suspend on Thinkpad x201i
>On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch > wrote: >> On Wed, Jul 4, 2012 at 4:23 PM, mbsd wrote: >>> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote: >> [SNIP] In All the test, the screen is light and black, system is hangup, nothing can be done. The only thing can be done, is push power button, to force it shutdown. >>> >>> Which graphic card have you used? If you have had nvidia, it's normal, >>> I've had the same problem "the screen is light and black". >> >> Can both of you show the output of `devinfo -v` from your systems? >> >> I was able to solve my suspend/resume issue with my nvidia-equipped >> notebook by forcing the module load ordering of vgapm in >> sys/isa/vga_isa.c: >> >> Index: sys/isa/vga_isa.c >> === >> --- sys/isa/vga_isa.c (revision 237779) >> +++ sys/isa/vga_isa.c (working copy) >> @@ -379,4 +379,4 @@ >> 0 >> }; >> >> -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); >> +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, SI_ORDER_ANY); >> >> >> The system requires however that I load the nvidia module in >> /boot/loader.conf (as opposed to loading it after system is up and >> running). >> >> -Brandon > >Oops, the patch above should instead be: > >Index: sys/isa/vga_isa.c >=== >--- sys/isa/vga_isa.c (revision 238266) >+++ sys/isa/vga_isa.c (working copy) >@@ -379,4 +379,4 @@ >0 > }; > >-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); >+DRIVER_MODULE_ORDERED(vgapm, vgapci, vgapm_driver, vgapm_devclass, >NULL, NULL, SI_ORDER_ANY); > >I made the edit for the diff on a clean tree, but I'm actually >building from another :) > >The above is correct. However, I'm still not sure this pertains to >your Intel video problem. > >-Brandon Yesterday, I upgrade my freebsd to FreeBSD 9.1-PRERELEASE. This method did not work. And command 'shutdown -p now' can shutdown the system, but the Screen is black and light, and Battery LED is light. This command can't power off. Whethe in: sysctl -w hw.acpi.reset_video=0 sysctl -w hw.pci.do_power_suspend=1 sysctl -w hw.pci.do_power_resume=1 Or in: sysctl -w hw.acpi.reset_video=0 sysctl -w hw.pci.do_power_suspend=1 sysctl -w hw.pci.do_power_resume=1 I can execute acpiconf -s 3, but can't resume the screen which is black and light. Log for command 'acpiconf -s 3': Jul 20 16:06:53 x201i acpi: suspend at 20120720 16:06:53 Jul 20 16:06:56 x201i kernel: acpi_timer0: switching timecounter, TSC-low -> ACPI-safe Jul 20 16:06:56 x201i kernel: (ada0:ahcich0:0:0:0): spin-down Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for \_SB_.LID_ (S3) Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for \_SB_.SLPB (S3) Jul 20 16:07:00 x201i kernel: uhub0: at usbus0, port 1, addr 1 (disconnected) Jul 20 16:07:00 x201i kernel: ugen0.2: at usbus0 (disconnected) Jul 20 16:07:00 x201i kernel: uhub2: at uhub0, port 1, addr 2 (disconnected) Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D0 to D3 Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D0 to D3 Jul 20 16:07:00 x201i kernel: wlan0: link state changed to DOWN Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D0 to D3 Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D0 to D3 Jul 20 16:07:00 x201i kernel: uhub1: at usbus1, port 1, addr 1 (disconnected) Jul 20 16:07:00 x201i kernel: ugen1.2: at usbus1 (disconnected) Jul 20 16:07:00 x201i kernel: uhub3: at uhub1, port 1, addr 2 (disconnected) Jul 20 16:07:00 x201i kernel: vga0: saving 4804 bytes of video state Jul 20 16:07:00 x201i kernel: vga0: saving color palette Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP1: AE_BAD_PARAMETER Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP4: AE_BAD_PARAMETER Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP5: AE_BAD_PARAMETER Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for \_SB_.LID_ (S3) Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for \_SB_.SLPB (S3) Jul 20 16:07:00 x201i kernel: pci255: set ACPI power state D0 on \_SB_.UNCR.SAD_ Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.VID_ Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.IGBE Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EHC2 Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.HDEF Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP1 Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D3 to D0 Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP4 Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D3 to D0 Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_
Re: Re: Resume failed after Suspend on Thinkpad x201i
On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch wrote: > On Wed, Jul 4, 2012 at 4:23 PM, mbsd wrote: >> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote: > [SNIP] >>> >>> In All the test, the screen is light and black, system is hangup, nothing >>> can be done. >>> The only thing can be done, is push power button, to force it shutdown. >> >> Which graphic card have you used? If you have had nvidia, it's normal, >> I've had the same problem "the screen is light and black". > > Can both of you show the output of `devinfo -v` from your systems? > > I was able to solve my suspend/resume issue with my nvidia-equipped > notebook by forcing the module load ordering of vgapm in > sys/isa/vga_isa.c: > > Index: sys/isa/vga_isa.c > === > --- sys/isa/vga_isa.c (revision 237779) > +++ sys/isa/vga_isa.c (working copy) > @@ -379,4 +379,4 @@ > 0 > }; > > -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); > +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, SI_ORDER_ANY); > > > The system requires however that I load the nvidia module in > /boot/loader.conf (as opposed to loading it after system is up and > running). > > -Brandon Oops, the patch above should instead be: Index: sys/isa/vga_isa.c === --- sys/isa/vga_isa.c (revision 238266) +++ sys/isa/vga_isa.c (working copy) @@ -379,4 +379,4 @@ 0 }; -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); +DRIVER_MODULE_ORDERED(vgapm, vgapci, vgapm_driver, vgapm_devclass, NULL, NULL, SI_ORDER_ANY); I made the edit for the diff on a clean tree, but I'm actually building from another :) The above is correct. However, I'm still not sure this pertains to your Intel video problem. -Brandon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Re: Resume failed after Suspend on Thinkpad x201i
>On Wed, Jul 4, 2012 at 4:23 PM, mbsd wrote: >> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote: >[SNIP] >>> >>> In All the test, the screen is light and black, system is hangup, nothing >>> can be done. >>> The only thing can be done, is push power button, to force it shutdown. >> >> Which graphic card have you used? If you have had nvidia, it's normal, >> I've had the same problem "the screen is light and black". > >Can both of you show the output of `devinfo -v` from your systems? > >I was able to solve my suspend/resume issue with my nvidia-equipped >notebook by forcing the module load ordering of vgapm in >sys/isa/vga_isa.c: > >Index: sys/isa/vga_isa.c >=== >--- sys/isa/vga_isa.c (revision 237779) >+++ sys/isa/vga_isa.c (working copy) >@@ -379,4 +379,4 @@ >0 > }; > >-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); >+DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, SI_ORDER_ANY); > > >The system requires however that I load the nvidia module in >/boot/loader.conf (as opposed to loading it after system is up and >running). > >-Brandon devinfo -v : http://pastebin.com/BFBHt3Sr dmidecode: http://pastebin.com/dWVbe7t4 My x201i: Model: 3249A64 CPU: Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz MainBoard: Intel QM57. Graphics card is Intel GMA HD(integration). /etc/make.conf .. #KMS WITH_NEW_XORG="YES" WITH_KMS="YES" .. My kernel build with kms, which can support the Intel GMA HD graphics card. My gui is used KDE 4.8. Everything runs ok, except suspend/resume. The latest situation: When I close LCD，x201i will become to Sleep status. Sleep LED is light, LCD is close. But, no button can resume it. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Re: Resume failed after Suspend on Thinkpad x201i
On Wed, Jul 4, 2012 at 4:23 PM, mbsd wrote: > On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote: [SNIP] >> >> In All the test, the screen is light and black, system is hangup, nothing >> can be done. >> The only thing can be done, is push power button, to force it shutdown. > > Which graphic card have you used? If you have had nvidia, it's normal, > I've had the same problem "the screen is light and black". Can both of you show the output of `devinfo -v` from your systems? I was able to solve my suspend/resume issue with my nvidia-equipped notebook by forcing the module load ordering of vgapm in sys/isa/vga_isa.c: Index: sys/isa/vga_isa.c === --- sys/isa/vga_isa.c (revision 237779) +++ sys/isa/vga_isa.c (working copy) @@ -379,4 +379,4 @@ 0 }; -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0); +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, SI_ORDER_ANY); The system requires however that I load the nvidia module in /boot/loader.conf (as opposed to loading it after system is up and running). -Brandon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Re: Resume failed after Suspend on Thinkpad x201i
On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote: > >On 07/02/12 02:29, 乔楚/HonestQiao wrote: > >> Follow by step in > >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html > >> #sysctl debug.bootverbose=1 > >> #sysctl debug.acpi.suspend_bounce=1 > >> #acpiconf -s 3(or push Fn+F3) > >> > >> After a moment, the display is light and black, LED Sleep is light. > >> But it cant be resume. No button can do resume. > >> > >> Some useful info: > >> hw.acpi : http://pastebin.com/zknEPdVS > >> acpidump : http://pastebin.com/uH4hXywR > >> dmesg : http://pastebin.com/wdqi7mfW > >> > >> In /var/log/message: http://pastebin.com/fcWKMUd7 > >> Jul 2 16:43:22 x201i acpi: suspend at 20120702 16:43:22 > >> [It Can't resume, so I push power force to close my x201. ] > >> Jul 2 16:52:11 x201i syslogd: kernel boot file is /boot/kernel/kernel > >> > >> #uname -a > >> FreeBSD x201i.honestqiao 9.0-STABLE FreeBSD 9.0-STABLE #0: Wed Jun 13 > >> 22:36:36 CST 2012 root@x201i.honestqiao:/usr/obj/usr/src/sys/GENERIC > >> amd64 > >> #vmstat -i > >> interrupt total rate > >> irq1: atkbd0 16 0 > >> irq9: acpi0 727 4 > >> irq19: ehci1 338 2 > >> irq23: ehci0 255 1 > >> cpu0:timer 7607 50 > >> irq264: em0 135 0 > >> irq265: hdac0 66 0 > >> irq266: iwn0 15781105 > >> irq267: ahci0 5732 38 > >> cpu1:timer 1578 10 > >> cpu3:timer 1819 12 > >> cpu2:timer 1510 10 > >> irq268: vgapci03 0 > >> Total 35567237 > >> > >> #kldstat > >> Id Refs AddressSize Name > >> 1 85 0x8020 1301fa8 kernel > >> 21 0x81502000 2087f0 zfs.ko > >> 32 0x8170b000 5c68 opensolaris.ko > >> 42 0x81711000 484e0linux.ko > >> 51 0x8175a000 f4d8 aio.ko > >> 61 0x8176a000 29e0 coretemp.ko > >> 71 0x8176d000 3028 amdtemp.ko > >> 81 0x81771000 27398drm.ko > >> 91 0x81799000 ba40 mmc.ko > >> 101 0x817a5000 4218 mmcsd.ko > >> 121 0x817b 6568 cuse4bsd.ko > >> 131 0x817b7000 de08 tmpfs.ko > >> 143 0x817c5000 8ab0 libiconv.ko > >> 151 0x817ce000 24c8 libmchain.ko > >> 161 0x817d1000 11c8 cd9660_iconv.ko > >> 171 0x817d3000 11e0 msdosfs_iconv.ko > >> 181 0x817d5000 10768cpufreq.ko > >> 191 0x817e6000 59b8 acpi_ibm.ko > >> 201 0x817ec000 6668 sem.ko > >> 211 0x81a12000 15c2 fdescfs.ko > >> 221 0x81a14000 3dfd linprocfs.ko > >> 231 0x81a18000 a9bb fuse.ko > >> 241 0x81a23000 5f7b7i915kms.ko > >> 251 0x81a83000 123d iicbb.ko > >> 264 0x81a85000 12ff iicbus.ko > >> 271 0x81a87000 dc9 iic.ko > >> 281 0x81a88000 2be29drm2.ko > >> > >> #sysctl dev.acpi_ibm > >> dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras > >> dev.acpi_ibm.0.%driver: acpi_ibm > >> dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY > >> dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 > >> dev.acpi_ibm.0.%parent: acpi0 > >> dev.acpi_ibm.0.initialmask: 2060 > >> dev.acpi_ibm.0.availmask: 134217727 > >> dev.acpi_ibm.0.events: 1 > >> dev.acpi_ibm.0.eventmask: 134217727 > >> dev.acpi_ibm.0.hotkey: 388 > >> dev.acpi_ibm.0.lcd_brightness: 0 > >> dev.acpi_ibm.0.volume: 7 > >> dev.acpi_ibm.0.mute: 0 > >> dev.acpi_ibm.0.thinklight: 0 > >> dev.acpi_ibm.0.bluetooth: 0 > >> dev.acpi_ibm.0.wlan: 1 > >> dev.acpi_ibm.0.fan_speed: 3265 > >> dev.acpi_ibm.0.fan_level: 2 > >> dev.acpi_ibm.0.fan: 0 > >> > >> -- > >> > >> > >> ___ > >> freebsd-acpi@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org" > >Try setting hw.pci.do_power_resume and hw.pci.do_power_suspend to 0, > >then try each at 1, then try both at 1. > > > >Many times Thinkpads fail to resume because of something import getting > >turned off that needs to be on during suspend, or by trying to turn on > >things that don't like that during resume. Almost all my thinkpads have > >required some combo of the above settings. > > > >Also, try these tests in single user, to rule out some 3rd party kernel > >modules you have there. > > > >Matt > > > > > > #kldstat > kernel zfs.ko opensolaris.ko acpi_ibm.ko > #cat /root/set.sh > #!/bin/cs
Re: Re: Resume failed after Suspend on Thinkpad x201i
>On 07/02/12 02:29, 乔楚/HonestQiao wrote: >> Follow by step in >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html >> #sysctl debug.bootverbose=1 >> #sysctl debug.acpi.suspend_bounce=1 >> #acpiconf -s 3(or push Fn+F3) >> >> After a moment, the display is light and black, LED Sleep is light. >> But it cant be resume. No button can do resume. >> >> Some useful info: >> hw.acpi : http://pastebin.com/zknEPdVS >> acpidump : http://pastebin.com/uH4hXywR >> dmesg : http://pastebin.com/wdqi7mfW >> >> In /var/log/message: http://pastebin.com/fcWKMUd7 >> Jul 2 16:43:22 x201i acpi: suspend at 20120702 16:43:22 >> [It Can't resume, so I push power force to close my x201. ] >> Jul 2 16:52:11 x201i syslogd: kernel boot file is /boot/kernel/kernel >> >> #uname -a >> FreeBSD x201i.honestqiao 9.0-STABLE FreeBSD 9.0-STABLE #0: Wed Jun 13 >> 22:36:36 CST 2012 root@x201i.honestqiao:/usr/obj/usr/src/sys/GENERIC >> amd64 >> #vmstat -i >> interrupt total rate >> irq1: atkbd0 16 0 >> irq9: acpi0 727 4 >> irq19: ehci1 338 2 >> irq23: ehci0 255 1 >> cpu0:timer 7607 50 >> irq264: em0 135 0 >> irq265: hdac0 66 0 >> irq266: iwn0 15781105 >> irq267: ahci0 5732 38 >> cpu1:timer 1578 10 >> cpu3:timer 1819 12 >> cpu2:timer 1510 10 >> irq268: vgapci03 0 >> Total 35567237 >> >> #kldstat >> Id Refs AddressSize Name >> 1 85 0x8020 1301fa8 kernel >> 21 0x81502000 2087f0 zfs.ko >> 32 0x8170b000 5c68 opensolaris.ko >> 42 0x81711000 484e0linux.ko >> 51 0x8175a000 f4d8 aio.ko >> 61 0x8176a000 29e0 coretemp.ko >> 71 0x8176d000 3028 amdtemp.ko >> 81 0x81771000 27398drm.ko >> 91 0x81799000 ba40 mmc.ko >> 101 0x817a5000 4218 mmcsd.ko >> 121 0x817b 6568 cuse4bsd.ko >> 131 0x817b7000 de08 tmpfs.ko >> 143 0x817c5000 8ab0 libiconv.ko >> 151 0x817ce000 24c8 libmchain.ko >> 161 0x817d1000 11c8 cd9660_iconv.ko >> 171 0x817d3000 11e0 msdosfs_iconv.ko >> 181 0x817d5000 10768cpufreq.ko >> 191 0x817e6000 59b8 acpi_ibm.ko >> 201 0x817ec000 6668 sem.ko >> 211 0x81a12000 15c2 fdescfs.ko >> 221 0x81a14000 3dfd linprocfs.ko >> 231 0x81a18000 a9bb fuse.ko >> 241 0x81a23000 5f7b7i915kms.ko >> 251 0x81a83000 123d iicbb.ko >> 264 0x81a85000 12ff iicbus.ko >> 271 0x81a87000 dc9 iic.ko >> 281 0x81a88000 2be29drm2.ko >> >> #sysctl dev.acpi_ibm >> dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras >> dev.acpi_ibm.0.%driver: acpi_ibm >> dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY >> dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 >> dev.acpi_ibm.0.%parent: acpi0 >> dev.acpi_ibm.0.initialmask: 2060 >> dev.acpi_ibm.0.availmask: 134217727 >> dev.acpi_ibm.0.events: 1 >> dev.acpi_ibm.0.eventmask: 134217727 >> dev.acpi_ibm.0.hotkey: 388 >> dev.acpi_ibm.0.lcd_brightness: 0 >> dev.acpi_ibm.0.volume: 7 >> dev.acpi_ibm.0.mute: 0 >> dev.acpi_ibm.0.thinklight: 0 >> dev.acpi_ibm.0.bluetooth: 0 >> dev.acpi_ibm.0.wlan: 1 >> dev.acpi_ibm.0.fan_speed: 3265 >> dev.acpi_ibm.0.fan_level: 2 >> dev.acpi_ibm.0.fan: 0 >> >> -- >> >> >> ___ >> freebsd-acpi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org" >Try setting hw.pci.do_power_resume and hw.pci.do_power_suspend to 0, >then try each at 1, then try both at 1. > >Many times Thinkpads fail to resume because of something import getting >turned off that needs to be on during suspend, or by trying to turn on >things that don't like that during resume. Almost all my thinkpads have >required some combo of the above settings. > >Also, try these tests in single user, to rule out some 3rd party kernel >modules you have there. > >Matt > > #kldstat kernel zfs.ko opensolaris.ko acpi_ibm.ko #cat /root/set.sh #!/bin/csh sysclt -w sysctl debug.bootverbose=1 sysclt -w sysctl debug.acpi.suspend_bounce=1 sysclt -w hw.acpi.reset_video="$argv[1]" sysclt -w hw.pci.do_power_resume="$argv[2]" sysclt -w hw.pci.do_power_suspend="$argv[3]" Test:(8 times) /root/set.sh 0 0 0; acpiconf -s 3 /root/set.sh 0 0 1; acpico
