FreeBSD 8.1 regression in x86bios.c

[Craig Boston]

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.

Craig