From owner-freebsd-stable@FreeBSD.ORG Sat Feb 26 05:18:27 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3ECA106564A; Sat, 26 Feb 2011 05:18:27 +0000 (UTC) (envelope-from cb@severious.net) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id B07098FC13; Sat, 26 Feb 2011 05:18:27 +0000 (UTC) Received: from [192.168.69.99] (adsl-76-200-93-223.dsl.hstntx.sbcglobal.net [76.200.93.223]) by ion.gank.org (Postfix) with ESMTPSA id 47BC7E5763; Fri, 25 Feb 2011 22:59:25 -0600 (CST) Message-ID: <4D6888A8.20505@severious.net> Date: Fri, 25 Feb 2011 22:59:20 -0600 From: Craig Boston User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jkim@freebsd.org Subject: FreeBSD 8.1 regression in x86bios.c X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cb@severious.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 05:18:27 -0000 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. Craig