Re: Sleep/resume in FreeBSD 9 on a ThinkPad
I have the same issue. http://lists.freebsd.org/pipermail/freebsd-acpi/2012-July/007641.html 2012/11/15 Stefan Horomnea stefan.horom...@gmail.com the ___ 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
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
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
