From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51301) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qg1Vb-0002xf-SM for qemu-devel@nongnu.org; Sun, 10 Jul 2011 17:25:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qg1Va-0006T4-Su for qemu-devel@nongnu.org; Sun, 10 Jul 2011 17:25:47 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:38934) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Qg1Va-0006Sg-DD for qemu-devel@nongnu.org; Sun, 10 Jul 2011 17:25:46 -0400 Message-ID: <0895461378D74EC49BD787BDBFF8C934@FSCPC> From: "Sebastian Herbszt" References: <20100228193904.GA15352@morn.localdomain><20100228204137.GA23442@redhat.com> <87d3y3p4sc.fsf@nemi.mork.no><20100414012749.GB29097@morn.localdomain><87ochmmhma.fsf@nemi.mork.no> <87sjqi9jsx.fsf@nemi.mork.no><20110707235009.GB12991@morn.localdomain><87fwmh9puv.fsf@nemi.mork.no> <20110710204100.GA25495@morn.localdomain> In-Reply-To: <20110710204100.GA25495@morn.localdomain> Date: Sun, 10 Jul 2011 23:25:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [SeaBIOS] SeaBIOS error with Juniper FreeBSD kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor , =?iso-8859-1?Q?Bj=F8rn_Mork?= Cc: Brandon Bennett , seabios@seabios.org, qemu-devel@nongnu.org Kevin O'Connor wrote: > I investigated this a bit and I believe the Juniper OS has two SMBIOS > bugs: it crashes when the table is in high memory, and when searching Are all versions based on FreeBSD 4.11? Are newer versions still affected? > So, moving the SMBIOS back to the f-segment would fix this. But, > there's an issue with that. > > The SMBIOS table is normally pretty small (eg, 263 bytes), but it > increases with the amount of ram and number of CPUs. If one starts > QEmu with 255 cpus, the SMBIOS size is over 11K. Fitting that into > the f-segment (64K shared with all the other 16bit code and data) is > going to be a real problem. This is also an issue for the mptable > (which is over 5K at 255 cpus), but newer OSes don't care about > mptable - not so for the smbios table though. You might want to introduce CONFIG_SMBIOS_LOCATION and check for space shortage in the F-segment case. Bochs BIOS panics if all requested tables don't fit into the available space. Sebastian