Re: Resume failed after Suspend on Thinkpad x201i
2012/8/6 Zack Breckenridge zbr...@gmail.com: At this point, after having simply read through the sources and done some research, it looks like remote debugging might not be necessary, or even very useful, in this case after all (though it would be nice to have for future debugging endeavors so I will look into your suggestions, thank you). So once again, on my hardware and probably Honest Qiao's as well, the call the vesa_bios_post() on resume really boils down to: x86bios_call(regs, X86BIOS_PHYSTOSEG(vesa_bios_offs + 3), X86BIOS_PHYSTOOFF(vesa_bios_offs + 3)); I think this is used to normalize the graphics card state [see: http://fxr.watson.org/fxr/source/dev/fb/vesa.c#L1506], before using VBE (real mode) state restore code to restore the state of the graphics device. All it's doing is executing the POST code in the VESA option ROM, copied to 0xc by the BIOS (and this is an old legacy boot method, apparently. UEFI BIOSes support this for backward compatibility). So there's real mode code at this location and the x86emu library is used to execute it, etc. This call is what is causing my screen to blank. However, it is also what is causing my display to power on after a resume. If I comment out the call to vesa_bios_post() in vesa_load_state(), then set debug.acpi.suspend_bounce=1 and go S3, everything just works. The screen even flashes when the VESA state restore code is executed and I can use the VESA driver as usual - for example I can change the video mode with vidcontrol MODE_280. But if I actually let the machine power down, on resume the display never powers back on. I was hoping I could use the VESA DPMS driver to power it back on and everything would just work (though this would still be a temporary hack). So I'm looking for a general way of powering on the display after resume that works for everyone. Obviously this code worked for the original developer(s) hardware and may work well for a set of hardware out there. One line of inquiry I'm following is how i915kms powers the device on after a resume - because it does and works just fine. Zack On Sun, Aug 5, 2012 at 12:14 AM, 乔楚 honestq...@gmail.com wrote: 2012/8/5 matt sendtom...@gmail.com: On 08/03/12 23:39, 乔楚 wrote: 2012/8/3 Zack Breckenridge zbr...@gmail.com: 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 Honest Qiao: Regarding hot air, are you running powerd? Try powerd -a adaptive -b adaptive as root and wait 5 minutes to see if the hot air stops. If it works, try man powerd for installation instructions. Lenovo laptops are thermally designed for low CPU utilization. I can almost
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 honestq...@gmail.com wrote: 2012-07-23 05:45, Zack Breckenridgezbr...@gmail.com 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 Breckenridgezbr...@gmail.com 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/7/20 Zack Breckenridge zbr...@gmail.com: 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 honestq...@gmail.com wrote: On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Wed, Jul 4, 2012 at 4:23 PM, mbsd m...@isgroup.com.ua 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: vendor 0x8087 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: vendor 0x8087 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
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, 乔楚 honestq...@gmail.com wrote: 2012/7/20 Zack Breckenridge zbr...@gmail.com: 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 honestq...@gmail.com wrote: On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Wed, Jul 4, 2012 at 4:23 PM, mbsd m...@isgroup.com.ua 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:
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 zbr...@gmail.com 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, 乔楚 honestq...@gmail.com wrote: 2012/7/20 Zack Breckenridge zbr...@gmail.com: 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 honestq...@gmail.com wrote: On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Wed, Jul 4, 2012 at 4:23 PM, mbsd m...@isgroup.com.ua 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:
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 honestq...@gmail.com wrote: On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Wed, Jul 4, 2012 at 4:23 PM, mbsd m...@isgroup.com.ua 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: vendor 0x8087 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: vendor 0x8087 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
Re: Re: Resume failed after Suspend on Thinkpad x201i
On Wed, Jul 4, 2012 at 4:23 PM, mbsd m...@isgroup.com.ua 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: 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 ___ 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
