From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 10 16:54:21 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C37241065673 for ; Fri, 10 Aug 2012 16:54:21 +0000 (UTC) (envelope-from honestqiao@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD188FC17 for ; Fri, 10 Aug 2012 16:54:21 +0000 (UTC) Received: by qcsg15 with SMTP id g15so1308432qcs.13 for ; Fri, 10 Aug 2012 09:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/jkFWKoYLIn7OY1uLavxHD3a0TSXEWuUsbpLwtd55yI=; b=hSGmEPuWwBA7711hp1bK359HkU5i+bF3MVDHwUa+hH3yOMF/f/CiAh3GRgPV0BXw4z 6aHArRLoxFIHobMmwMDDGpiYSEMnaEAv2T9B2+0C/sr0+2c1qfdjmdEjqagM1M/UcgeS 3EnA7An+ODln0jJepFnBjBpl/prVK/8WBJKYbUgB07I22efo/8TX4PBzUtUq4+Rau3nU 1/ZRhAfs9kRnVLV2eiY+3GFbwHm+qI4sken4TwCytva5UHqsDG1sd1QpMfJe3tkXmlB/ qnyaX0XW39Q9oDxAIFukpjqDejQ+qcvd8rCaaXfCrvOBoPvAIdoLSS72UJ7X20OYxvTe OAAA== Received: by 10.224.222.141 with SMTP id ig13mr351719qab.32.1344617660617; Fri, 10 Aug 2012 09:54:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.224 with HTTP; Fri, 10 Aug 2012 09:53:40 -0700 (PDT) In-Reply-To: References: <201207021729413382845@gmail.com> <4FF2599B.6050409@gmail.com> <201207031411248300207@gmail.com> <1341437029.4017.5.camel@localhost> <2012072016090861869410@gmail.com> <2012080201072126960020@gmail.com> <501DA226.8000707@gmail.com> From: =?UTF-8?B?5LmU5qWa?= Date: Sat, 11 Aug 2012 00:53:40 +0800 Message-ID: To: Zack Breckenridge Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi Subject: Re: Resume failed after Suspend on Thinkpad x201i X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:54:21 -0000 2012/8/6 Zack Breckenridge : > 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, =E4=B9=94=E6=A5=9A wrote: >> 2012/8/5 matt : >>> On 08/03/12 23:39, =E4=B9=94=E6=A5=9A wrote: >>>> >>>> 2012/8/3 Zack Breckenridge : >>>>> >>>>> First of all, let me note that the Kernel config file I posted was fo= r >>>>> 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 i= s >>>>> 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#L58= 4] >>>>> 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 t= o >>>>> 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. Len= ovo >>> laptops are thermally designed for low CPU utilization. I can almost bo= il >>> water on mine during buildworld. Without powerd, they run at full therm= al >>> profile and act as excellent hand warmers. >>> >>> Zack: Regarding remote debugging, do you have an expresscard/cardbus/et= c >>> 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= . Thank you for your hard work. I want to know, is there any way to solve problems that can not be shutdown the system. As I said earlier, command "shutdown -p now" can shutdown the os, but it can not turn off the battery and can not real turn off CPU and fan. This Problem made =E2=80=8B=E2=80=8Bme a headache. Every time I have to hol= d the power button to force shutdown. I'm afraid that when forgotten, will lead to serious consequences.