Date: Mon, 28 Feb 2011 14:36:05 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-stable@FreeBSD.org Cc: cb@severious.net Subject: Re: FreeBSD 8.1 regression in x86bios.c Message-ID: <201102281436.09812.jkim@FreeBSD.org> In-Reply-To: <201102281233.58810.jkim@FreeBSD.org> References: <4D6888A8.20505@severious.net> <201102281233.58810.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Boundary-00=_pk/aN156ePK4xTq Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Monday 28 February 2011 12:33 pm, Jung-uk Kim wrote: > 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. :-( Please try the attached patch and let me know if it makes any difference. Thanks, Jung-uk Kim --Boundary-00=_pk/aN156ePK4xTq Content-Type: text/plain; charset="iso-8859-1"; name="x86bios.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="x86bios.diff" Index: sys/compat/x86bios/x86bios.c =================================================================== --- sys/compat/x86bios/x86bios.c (revision 219101) +++ sys/compat/x86bios/x86bios.c (working copy) @@ -291,25 +291,6 @@ x86bios_emu_outl(struct x86emu *emu, uint16_t port outl(port, val); } -static void -x86bios_emu_get_intr(struct x86emu *emu, int intno) -{ - uint16_t *sp; - uint32_t iv; - - emu->x86.R_SP -= 6; - - sp = (uint16_t *)((vm_offset_t)x86bios_seg + emu->x86.R_SP); - sp[0] = htole16(emu->x86.R_IP); - sp[1] = htole16(emu->x86.R_CS); - sp[2] = htole16(emu->x86.R_FLG); - - iv = x86bios_get_intr(intno); - emu->x86.R_IP = iv & 0xffff; - emu->x86.R_CS = (iv >> 16) & 0xffff; - emu->x86.R_FLG &= ~(F_IF | F_TF); -} - void * x86bios_alloc(uint32_t *offset, size_t size) { @@ -567,7 +548,6 @@ x86bios_unmap_mem(void) static void x86bios_init(void *arg __unused) { - int i; mtx_init(&x86bios_lock, "x86bios lock", NULL, MTX_SPIN); @@ -598,9 +578,6 @@ x86bios_init(void *arg __unused) x86bios_emu.emu_outb = x86bios_emu_outb; x86bios_emu.emu_outw = x86bios_emu_outw; x86bios_emu.emu_outl = x86bios_emu_outl; - - for (i = 0; i < 256; i++) - x86bios_emu._x86emu_intrTab[i] = x86bios_emu_get_intr; } static void --Boundary-00=_pk/aN156ePK4xTq--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102281436.09812.jkim>