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

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, 乔楚/HonestQiao <honestq...@gmail.com> wrote:
>
> 2012-07-23 05:45, 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
> >
>
> 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"

Reply via email to