diff mbox

[SeaBIOS] SeaBIOS error with Juniper FreeBSD kernel

Message ID 8739hlb5t4.fsf@nemi.mork.no
State New
Headers show

Commit Message

Bjørn Mork Aug. 1, 2011, 1:49 p.m. UTC 
Brandon Bennett <bennetb@gmail.com> writes:

>> Are all versions based on FreeBSD 4.11?
>> Are newer versions still affected?
>
> Newer versions should be based on 6.1 but there are a lot of changes.
> I haven't had a chance to test with something newer yet.

Sorry for the delay due to vacation...

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. I don't think the
FreeBSD version really matters.  I believe the issue is related to the
"platform_early_bootinit", whatever that is, which is Juniper specific
code.  I assume they are checking the SMBIOS for some data which is
present on the real hardware, and this check triggers the crash.


From the 11.1R3.5 boot:


Hit [Enter] to boot immediately, or space bar for command prompt.
Booting [/kernel]...               
platform_early_bootinit: M/T Series Early Boot Initialization
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xbff3fffc
fault code              = supervisor write, page not present
instruction pointer     = 0x20:0xc0a22377
stac

Fatal trap 30: reserved (unknown) fault while in kernel mode
instruction pointer     = 0x20:0xc09f4e66
stack pointer           = 0x28:0xc1021a00
frame pointer           = 0x28:0xc1021a10
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, IOPL = 0
current process         = 0 ()
trap number             = 30
dog: ERROR - reset of uninitialized watchdog
panic: reserved (unknown) fault
(null)(c0c4f4a0,c0c4f4a0,c0be3672,c1021948,a) at 0xc0a14867
(null)(c0be3672,1e,c10219c0,1,1) at 0xc05a723e
(null)(a,0,a,ffff7fff,ffffffff) at 0xc0a289dd
(null)(c10219c0) at 0xc0a29921
(null)(0,c021b4b,3030000,c0c22a00,c0c54400) at 0xc0a15e7b
(null)(c0c22a00,63,5,c1021bac,63) at 0xc09f50c2
(null)(63,10,1000000,1,c0bbe530) at 0xc05e66f3
(null)(63,c1021bac,c0be340e,3f8,1002580) at 0xc05c7ca5
(null)(c0bbe52c,c05c7c45,c1021bac,a,c1021bcc) at 0xc05c7df5
(null)(c0bbe52c,28,c1021cc4,c0be33fe,a) at 0xc05c8f73
(null)(c0c4d0a0,c1021c84,c1021c38,c05c8f73,c0bbe604) at 0xc0a287da
(null)(c0bbe604,c,0,0,0) at 0xc0a28c2a
(null)(c1021c84) at 0xc0a296e8
(null)(cffffef0,ffffef0,4,c00e0000,c00e0000) at 0xc0a15e7b
(null)(0,c0bc71c6,4,10,0) at 0xc0a0f7df
(null)(c0be5837,c1021d34,c1021d30,a,c1021d54) at 0xc0a0f8ed
(null)(c0bc1e40,c0b6f924,c1021d84,c0a1e5a9,80) at 0xc0b3a694
(null)(80,c0a15ec0,f,3,20) at 0xc0b3ad7b
(null)(1026000) at 0xc0a1e5a9
(null)() at 0xc04aa67d
dog: ERROR - reset of uninitialized watchdog
dog: ERROR - reset of uninitialized watchdog
Uptime: 1s



Also confirmed that 11.1R3.5 is working with SeaBIOS modified as
follows:





Bjørn

Comments

Kevin O'Connor Aug. 2, 2011, 12:36 a.m. UTC | #1 
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.

-Kevin
diff mbox

Patch

diff --git a/src/smbios.c b/src/smbios.c
index 8df0f2d..c96deb5 100644
--- a/src/smbios.c
+++ b/src/smbios.c
@@ -17,7 +17,7 @@  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);
     if (!ep || !finaltable) {
         warn_noalloc();
         free(ep);