Date: Thu, 2 Aug 2012 15:24:53 -0700 From: Zack Breckenridge <zbrdge@gmail.com> To: =?UTF-8?B?5LmU5qWaL0hvbmVzdFFpYW8=?= <honestqiao@gmail.com> Cc: freebsd-acpi <freebsd-acpi@freebsd.org> Subject: Re: Re: Resume failed after Suspend on Thinkpad x201i Message-ID: <CA%2BXA1umRifYErG4CYTfZ6AZEH6KpF7dLfbt9Up7bJfLOYEmvTg@mail.gmail.com> In-Reply-To: <2012080201072126960020@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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, =E4=B9=94=E6=A5=9A/HonestQiao <honestqiao@= gmail.com> wrote: > > 2012-07-23 05:45, Zack Breckenridge<zbrdge@gmail.com> wrote: > >Attached is the kernel configuration file I used to build my kernel with= out > >VESA. > > > >I went through the same process as you: setting suspend bounce, etc., an= d > >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 was= n'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 V= ESA > >was causing the error. In your case - not being able to issue commands t= o > >an ATA device could also be a bus issue, caused by NOT calling the prope= r > >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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BXA1umRifYErG4CYTfZ6AZEH6KpF7dLfbt9Up7bJfLOYEmvTg>