From patchwork Tue Aug 2 09:33:09 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Bj=C3=B8rn_Mork?= X-Patchwork-Id: 107867 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [140.186.70.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 121D0B71CC for ; Tue, 2 Aug 2011 19:34:09 +1000 (EST) Received: from localhost ([::1]:56344 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoBMQ-0003bC-PP for incoming@patchwork.ozlabs.org; Tue, 02 Aug 2011 05:34:02 -0400 Received: from eggs.gnu.org ([140.186.70.92]:51276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoBMI-0003ak-Sg for qemu-devel@nongnu.org; Tue, 02 Aug 2011 05:33:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoBMH-0004Vs-5Q for qemu-devel@nongnu.org; Tue, 02 Aug 2011 05:33:54 -0400 Received: from canardo.mork.no ([148.122.252.1]:55914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoBMG-0004VT-JI for qemu-devel@nongnu.org; Tue, 02 Aug 2011 05:33:53 -0400 Received: from nemi.mork.no (ip6-localhost [IPv6:::1]) by canardo.mork.no (8.14.3/8.14.3) with ESMTP id p729Xe2Q013497 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 2 Aug 2011 11:33:41 +0200 Received: from bjorn by nemi.mork.no with local (Exim 4.72) (envelope-from ) id 1QoBLa-0002aT-20; Tue, 02 Aug 2011 11:33:10 +0200 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: "Kevin O'Connor" Organization: m References: <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> <0895461378D74EC49BD787BDBFF8C934@FSCPC> <8739hlb5t4.fsf@nemi.mork.no> <20110802003637.GA3046@morn.localdomain> Date: Tue, 02 Aug 2011 11:33:09 +0200 In-Reply-To: <20110802003637.GA3046@morn.localdomain> (Kevin O'Connor's message of "Mon, 1 Aug 2011 20:36:38 -0400") Message-ID: <87y5zc9mzu.fsf@nemi.mork.no> User-Agent: Gnus/5.110017 (No Gnus v0.17) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.97.2 at canardo X-Virus-Status: Clean X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 148.122.252.1 Cc: Brandon Bennett , seabios@seabios.org, qemu-devel@nongnu.org, Sebastian Herbszt Subject: Re: [Qemu-devel] [SeaBIOS] SeaBIOS error with Juniper FreeBSD kernel X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org "Kevin O'Connor" writes: > On Mon, Aug 01, 2011 at 03:49:11PM +0200, Bjørn Mork wrote: >> I just confirmed the issue running >> >> "JUNOS 11.1R3.5 built 2011-06-25 00:17:21 UTC" >> >> which is as new as it officially gets at the moment. > [...] >> Also confirmed that 11.1R3.5 is working with SeaBIOS modified as >> follows: > [...] >> - void *finaltable = malloc_high(structure_table_length); >> + void *finaltable = malloc_fseg(structure_table_length); > > I'm not really sure how best to handle this. The smbios table can be > larger than the current space reserved for the f-segment (when there > are a large number of CPUs). > > Some ideas: > > There is actually space in the f-segment that is unused, but not given > to the malloc_fseg pool. That space could be given to the pool - > though the available space will still vary depending on the code size. > > It's also possible to relocate the 32bit "run-time" code to high > memory which would then free up more space in the f-segment (at the > cost of some high memory being reserved from the OS). As above, > though, the f-segment is still fundamentally limited by the 16bit code > size. > > Also, it's possible the code could try to use the f-segment if there > are less than say 16 cpus and use high memory when more cpus are > present. How about a variant over the last suggestion: Don't actually care bout the number of CPUs, but just fall back to malloc_high if malloc_fseg fails? The attached patch works-for-me, and boots JUNOS as long as the number of CPUs is low enough for malloc_fseg to succeed. Bjørn From 66522176f711bbf609e10100fb713fc3ed6101c4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= Date: Thu, 7 Jul 2011 17:45:32 +0200 Subject: [PATCH] SMBIOS: use malloc_fseg() to avoid boot error on JUNOS MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Falling back to using malloc_high if malloc_fseg fails to support large tables e.g. due to a high number of cpus. The SMBIOS table must be allocated from low memory to prevent this bug when booting JUNOS: kernel trap 12 with interrupts disabled instruction pointer = 0x8:0xc053a6ae stack pointer = 0x10:0xc09dce7c frame pointer = 0x10:0xc09dced4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = Idle interrupt mask = net tty bio cam trap number = 30 dog: ERROR - reset of uninitialized watchdog panic: unknown/reserved trap (null)(c087aa20,c087aa20,c07ebef2,c09dcd90,5) at0 (null)(c07ebef2,1e,c09dced4,0,0) at0 (null)(c09dce3c,0,c09dcdf4,c051c108) at0 (null)(c09d0010,c09d0010,10,0,c) at0 (null)(9e0010,10,c0100010,0,9e1000) at0 (null)(2) at0 (null)(c07ecd92,f,c07d33a6,c09dcf54,ffffffff) at0 (null)(c09dcfd4,f,3,8,0) at0 (null)(9e1000,0,0,0,0) at0 (null)() at0 dog: ERROR - reset of uninitialized watchdog dog: ERROR - reset of uninitialized watchdog Uptime: 0s Signed-off-by: Bjørn Mork --- src/smbios.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/smbios.c b/src/smbios.c index 8df0f2d..5ca85cd 100644 --- a/src/smbios.c +++ b/src/smbios.c @@ -17,7 +17,10 @@ smbios_entry_point_init(u16 max_structure_size, u16 number_of_structures) { struct smbios_entry_point *ep = malloc_fseg(sizeof(*ep)); - void *finaltable = malloc_high(structure_table_length); + void *finaltable = malloc_fseg(structure_table_length); + /* fall back to malloc_high() if the table is too big */ + if (!finaltable) + finaltable = malloc_high(structure_table_length); if (!ep || !finaltable) { warn_noalloc(); free(ep); -- 1.7.2.5