Date: Mon, 6 Aug 2012 08:44:43 -0700 From: Zack Breckenridge <zbrdge@gmail.com> To: =?UTF-8?B?5LmU5qWa?= <honestqiao@gmail.com> Cc: freebsd-acpi <freebsd-acpi@freebsd.org> Subject: Re: Resume failed after Suspend on Thinkpad x201i Message-ID: <CA%2BXA1umDN1RZJbQ_aATETyvKUKUE6zaQ-Hb0TfC2qgPR-PrzvA@mail.gmail.com> In-Reply-To: <CAMAY4Vgn%2BvYWVPbm%2B2_xjaKiRUi_dq6=J_DRPgvHT2c9T=TTMw@mail.gmail.com> References: <201207021729413382845@gmail.com> <4FF2599B.6050409@gmail.com> <201207031411248300207@gmail.com> <1341437029.4017.5.camel@localhost> <CALBk6yLgUUvbZUhEhNgbqKOz8bc5eAM9anuP0ZSDR=qd6SstUw@mail.gmail.com> <CALBk6yK1fSg2ksVP4hmQz1pN-NVqXVGb3enjcE9t-rq0qXQQfA@mail.gmail.com> <2012072016090861869410@gmail.com> <CA%2BXA1um8xQmdXsP%2B0qJuqnWoPUD-EHnM9vGTUTifE_8nChh-zg@mail.gmail.com> <CAMAY4VjDwTLLG3y0G0Z9X4=-=-F1pgaN=7vwJxsaNgikr8YzcQ@mail.gmail.com> <CA%2BXA1umP9AyncDO-OA-q_ntDjcqRYT7hs6fV3MTvo==3M9Kd5w@mail.gmail.com> <2012080201072126960020@gmail.com> <CA%2BXA1umRifYErG4CYTfZ6AZEH6KpF7dLfbt9Up7bJfLOYEmvTg@mail.gmail.com> <CAMAY4VhY8baF1B=VY0A%2BqX=jRRYSOeLRSWfSjT6VOTtOUkKh7g@mail.gmail.com> <501DA226.8000707@gmail.com> <CAMAY4Vgn%2BvYWVPbm%2B2_xjaKiRUi_dq6=J_DRPgvHT2c9T=TTMw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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(®s, 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 0xc0000 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=3D1 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, =C7=C7=B3=FE <honestqiao@gmail.com> wrote: > 2012/8/5 matt <sendtomatt@gmail.com>: >> On 08/03/12 23:39, =C7=C7=B3=FE wrote: >>> >>> 2012/8/3 Zack Breckenridge <zbrdge@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=3D3#L1497]. >>>> vesa_bios_post() ultimately calls x86bios_call() [see: >>>> http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=3D10#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=3D1 >>>> # sysctl debug.kdb.enter=3D1 >>>> 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-unsubscribe@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. Leno= vo >> laptops are thermally designed for low CPU utilization. I can almost boi= l >> water on mine during buildworld. Without powerd, they run at full therma= l >> profile and act as excellent hand warmers. >> >> Zack: Regarding remote debugging, do you have an expresscard/cardbus/etc >> slot? Although hard to find you may be able to find a firewire card for >> that. Not sure if that would work or not...same goes for a USB->Serial >> console, my guess is that it wouldn't work? >> >> Matt > > Regarding powerd: > I know powerd. > I also set it autostart in rc.conf: > powerd_enable=3D"YES" > powerd_flags=3D"-a adaptive -b adaptive" > And I know that sysctl named dev.cpu.0.freq will change between 333 to > 2333 with system load. > > But, When I shutdown the system, the battery indicator finally closed, > the fan also continue to operate; > Because the fan is in operation, and blow hot air, indicating that the > CPU does not really stop working. > > So my system did not really close.If I do not press the power button > to force shut down the power supply, the battery LED is always on, > whether connected to AC power. > If I accidentally put it in a laptor bag, he will become hot. > > > Regarding extend slot: > Lenovo thinkpad x201 only has USB slot. It hasn't Serial slot. > I also think that a USB =3D> serial can not be with the remote debugging.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BXA1umDN1RZJbQ_aATETyvKUKUE6zaQ-Hb0TfC2qgPR-PrzvA>