Re: disabled CST_CNT write
on 08/07/2012 13:19 Taku YAMAMOTO said the following: In addition, that does not interfere with jkim's acpi_cx_native2.diff; I've been enjoying MWAIT C3 with varying sleep depth based upon AC availability. Are you saying that you have thoroughly tested that patch? :-) I don't see any reason not to commit it then. Jung-uk? -- Andriy Gapon ___ 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:
