From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 17:34:10 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 99B8F1065672; Mon, 28 Feb 2011 17:34:10 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: cb@severious.net Date: Mon, 28 Feb 2011 12:33:44 -0500 User-Agent: KMail/1.6.2 References: <4D6888A8.20505@severious.net> In-Reply-To: <4D6888A8.20505@severious.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102281233.58810.jkim@FreeBSD.org> Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.1 regression in x86bios.c X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 17:34:10 -0000 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 > > > 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