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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to