Skip site navigation (1)Skip section navigation (2)
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>