From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NlpxU-0005l1-F6 for qemu-devel@nongnu.org; Sun, 28 Feb 2010 15:41:48 -0500 Received: from [199.232.76.173] (port=33291 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NlpxU-0005kq-5A for qemu-devel@nongnu.org; Sun, 28 Feb 2010 15:41:48 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NlpxQ-0000Pb-A8 for qemu-devel@nongnu.org; Sun, 28 Feb 2010 15:41:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31653) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NlpxP-0000PP-S7 for qemu-devel@nongnu.org; Sun, 28 Feb 2010 15:41:44 -0500 Date: Sun, 28 Feb 2010 22:41:37 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] SeaBIOS error with Juniper FreeBSD kernel Message-ID: <20100228204137.GA23442@redhat.com> References: <20100221040555.GA16455@morn.localdomain> <20100228193904.GA15352@morn.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20100228193904.GA15352@morn.localdomain> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: Brandon Bennett , seabios@seabios.org, qemu-devel@nongnu.org On Sun, Feb 28, 2010 at 02:39:04PM -0500, Kevin O'Connor wrote: > On Sun, Feb 21, 2010 at 04:18:38PM -0700, Brandon Bennett wrote: > > > On Sat, Feb 20, 2010 at 9:05 PM, Kevin O'Connor = wrote: > > >> Should a kernel fail during boot, I'd suspect it doesn't like one of > > >> the apm/pcibios callbacks, or it doesn't like one of the > > >> smbios/mptable/acpi tables. =9AYou could try compiling the SeaBIOS c= ode > > >> (see http://seabios.org/Download ) and increasing the debugging by > > >> modifying src/config.h. =9ASpecifically, you could increase > > >> CONFIG_DEBUG_LEVEL, and set DEBUG_HDL_pcibios32 and DEBUG_HDL_apm to > > >> 1. =9AAlso, you could try disabling some of the features to see if t= hat > > >> prevents the fault (eg, disabling CONFIG_ACPI / CONFIG_SMBIOS / > > >> CONFIG_MPTABLE). > > > > >=20 > > I have narrowed it down to SMBIOS. If I disable CONFIG_SMBIOS the > > image boots up fine. >=20 > Gleb, have you seen this thread? >=20 > Some of the recent changes to smbios that look like possible culprits > are: >=20 > Make SMBIOS table pass MS SVVP test > Use MaxCountCPUs during building of per cpu tables. > Add malloc_high/fseg() and rework bios table creation to use them. >=20 If there is any seabios revision that works then it is possible to bisect to find problematic commit. > There were other changes, but the comments indicate they were only > ports of changes already in bochs. I suppose it's also possible the > lack of smbios is turning off some other feature in the guest (eg, > acpi) that's the real culprit. >=20 -- Gleb.