On Friday 25 February 2011 11:59 pm, Craig Boston wrote:> Hi all,
>
> My laptop (Toshiba Portege R100) stopped working with an early boot
> hang at some point between 8.0 and 8.1. After it broke last year I
> had ended up just reverting to an earlier kernel, but finally found
> the time to do a binary search and narrow it down.
>
> The offending commit is:
> http://svn.freebsd.org/viewvc/base?view=revision&revision=205647
>
<http://svn.freebsd.org/viewvc/base?view=revision&revision=205647>
>
> Fix stupid typos. Some VESA BIOSes directly call BIOS interrupt
> handlers within the VBE interrupt handler. Unfortunately it was
> causing real mode page faults because we were fetching instructions
> from bogus addresses. Pass me the pointyhat, please.
>
> PR: kern/144654
> MFC after: 3 days
>
> With this commit in place, the system hangs almost immediately on
> boot, right after probing kdbmux. With debug.x86bios.{call,int}
> enabled from the loader, the final lines before the hang are:
>
> avail memory = 1299705856 (1239 MB)
> kbd1 at kbdmux0
> Calling int 0x10 (ax=0x4f00 bx=0x0000 cx=0x0000 dx=0x0000 es=0x9e00
> di=0x0000)
> Exiting int 0x10 (ax=0x004f bx=0x0000 cx=0x0000 dx=0x0000 es=0x9e00
> di=0x0000)
> Calling int 0x10 (ax=0x4f01 bx=0x0000 cx=0x0144 dx=0x0000 es=0x0200
> di=0x0000)
>
> Then a hard hang. With the 2 lines in x86bios.c reverted, the
> system boots fine (even on a fresh 8.2 build with just that commit
> backed out). The debug output from a successful boot looks like
> this:
>
> kbd1 at kbdmux0
> Calling int 0x10 (ax=0x4f00 bx=0x0000 cx=0x0000 dx=0x0000 es=0x9e00
> di=0x0000)
> Exiting int 0x10 (ax=0x004f bx=0x0000 cx=0x0000 dx=0x0000 es=0x9e00
> di=0x0000)
> Calling int 0x10 (ax=0x4f01 bx=0x0000 cx=0x0144 dx=0x0000 es=0x0200
> di=0x0000)
> Exiting int 0x10 (ax=0xb13e bx=0x2065 cx=0x9e32 dx=0x1023 es=0x0200
> di=0x0028)
> Calling int 0x10 (ax=0x4f01 bx=0x0000 cx=0x0143 dx=0x0000 es=0x9c00
> di=0x0000)
> Exiting int 0x10 (ax=0xb13e bx=0x1065 cx=0x9e32 dx=0x1023 es=0x9c00
> di=0x0028)
> Calling int 0x10 (ax=0x4f01 bx=0x0000 cx=0x0141 dx=0x0000 es=0x0200
> di=0x0000)
> Exiting int 0x10 (ax=0xb13e bx=0x0865 cx=0x9e32 dx=0x1023 es=0x0200
> di=0x0028)
> (many more lines)
>
> In any event, I'm not sure if this is a true bug, or just a broken
> BIOS, but either way I thought you might want to know about it.
See the exit status of the "working" cases. Bogus status (%ax ==
0xb13e) was returned, which means the VBE calls failed and aborted.
So, yes, I guess it is one of those broken VESA BIOSes. :-(
Jung-uk Kim