[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [SeaBIOS] SeaBIOS error with Juniper FreeBSD kernel

From: Bjørn Mork
Subject: Re: [Qemu-devel] [SeaBIOS] SeaBIOS error with Juniper FreeBSD kernel
Date: Tue, 02 Aug 2011 11:33:09 +0200
User-agent: Gnus/5.110017 (No Gnus v0.17) Emacs/23.2 (gnu/linux)

"Kevin O'Connor" <address@hidden> 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

The attached patch works-for-me, and boots JUNOS as long as the number
of CPUs is low enough for malloc_fseg to succeed.


>From 66522176f711bbf609e10100fb713fc3ed6101c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <address@hidden>
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 <address@hidden>
 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) {

reply via email to

[Prev in Thread] Current Thread [Next in Thread]