Date: Mon, 28 Feb 2011 12:33:44 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: cb@severious.net Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.1 regression in x86bios.c Message-ID: <201102281233.58810.jkim@FreeBSD.org> In-Reply-To: <4D6888A8.20505@severious.net> References: <4D6888A8.20505@severious.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102281233.58810.jkim>