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

[Kevin O'Connor]

      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 <kevin(a)koconnor.net&gt; 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.  You could try compiling the SeaBIOS code
 (see http://seabios.org/Download ) and increasing the debugging by
 modifying src/config.h.  Specifically, you could increase
 CONFIG_DEBUG_LEVEL, and set DEBUG_HDL_pcibios32 and DEBUG_HDL_apm to
 1.  Also, you could try disabling some of the features to see if that
 prevents the fault (eg, disabling CONFIG_ACPI / CONFIG_SMBIOS /
 CONFIG_MPTABLE).
 
 I have narrowed it down to SMBIOS.  If I disable CONFIG_SMBIOS the
 image boots up fine.
Gleb, have you seen this thread?

Some of the recent changes to smbios that look like possible culprits
are:

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.

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.

-Kevin

[Qemu-devel] SeaBIOS error with Juniper FreeBSD kernel

[Gleb Natapov]

      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 <kevin(a)koconnor.net&gt; 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.  You could try compiling the SeaBIOS code
 (see http://seabios.org/Download ) and increasing the debugging by
 modifying src/config.h.  Specifically, you could increase
 CONFIG_DEBUG_LEVEL, and set DEBUG_HDL_pcibios32 and DEBUG_HDL_apm to
 1.  Also, you could try disabling some of the features to see if that
 prevents the fault (eg, disabling CONFIG_ACPI / CONFIG_SMBIOS /
 CONFIG_MPTABLE).
 
 I have narrowed it down to SMBIOS.  If I disable CONFIG_SMBIOS the
 image boots up fine.
 
 Gleb, have you seen this thread?
 
 Some of the recent changes to smbios that look like possible culprits
 are:
 
 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.
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.
--
			Gleb.

SeaBIOS error with Juniper FreeBSD kernel

[Bjørn Mork]

      Gleb Natapov <gleb(a)redhat.com&gt; writes:
  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:

  I have narrowed it down to SMBIOS.  If I disable
CONFIG_SMBIOS the
 image boots up fine.
 
 Gleb, have you seen this thread?
 
 Some of the recent changes to smbios that look like possible culprits
 are:
 
 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.
 If there is any seabios revision that works then it is possible to
 bisect to find problematic commit.
Hello,

I'm also bitten by this and have now attempted to bisect it.  The result
was: 

c95d2cee36db79c88253d43a90230ceadf0c26cf is first bad commit
commit c95d2cee36db79c88253d43a90230ceadf0c26cf
Author: Kevin O'Connor <kevin(a)koconnor.net&gt;
Date:   Wed Jul 29 20:41:39 2009 -0400

    Add auto-generated version info to each build.
    
    Add versioning info to initial debug and screen banner output.

:100644 100644 2e2ba1dbf46cb7a12eeaafbc394f3f279c10abf4
37589097295dde049f8512d99561a0320955fb41 M      Makefile
:040000 040000 29c4ea1e03416fce9b3aa963ece74050a7b5769a
2b5425a20726caeadba524e14756c8827dd66595 M      src



Which looks a bit strange... I'm afraid I'm unable to revert this on the
current HEAD due to other changes in the same area and my complete lack
of understanding any assembler.  But I have verified that 
 commit 8c8a880b584ccf8958d67e99a6750ba32d0b6454
is working for me, while 
 commit c95d2cee36db79c88253d43a90230ceadf0c26cf
has the mentioned problems.


However, I am not completely sure that I didn't mess up something which
affected the result.  I do note that the *working* version logs a 
"Bad SMBIOS data checksum" message:

olive@canardo:~$ kvm -L /usr/local/src/git/seabios/out -m 1024 -hda olive2.img  -nographic
-serial mon:stdio -monitor null 
Could not open option rom 'vapic.bin': No such file or directory
pci_add_option_rom: failed to find romfile "vgabios-cirrus.bin"
pci_add_option_rom: failed to find romfile "pxe-rtl8139.bin"
Consoles: serial port  
BIOS drive C: is disk0
BIOS 639kB/1047544kB available memory

FreeBSD/i386 bootstrap loader, Revision 1.1
(builder(a)ormonth.juniper.net, Tue Nov  3 08:19:23 UTC 2009)
Loading /boot/defaults/loader.conf 
/kernel text=0x74574c     smbios_init: Bad SMBIOS data checksum
data=0x42ba0+0x92e34 syms=[0x4+0x7f570+0x4+0xb12b2]
/boot/modules/if_bge.ko text=0xa98c data=0x364+0xc syms=[0x4+0xd50+0x4+0xd18]
/boot/modules/mpt_core.ko text=0x18dbc data=0x488+0x358 
/boot/modules/if_bce.ko text=0xd07c data=0x16d94+0x24e4 syms=[0x4+0x14d0+0x4+0x1787]
/boot/modules/acb.ko text=0x3d78 data=0x284+0x80 syms=[0x4+0xa70+0x4+0x9a4]
/boot/modules/mcs.ko text=0x4dc0 data=0x391+0xeb syms=[0x4+0xc40+0x4+0xbc2]
/boot/modules/scs.ko text=0x7c08 data=0x564+0x164 syms=[0x4+0x1110+0x4+0x1179]
/boot/modules/rcb.ko text=0x29c8 data=0x184+0x2c syms=[0x4+0x7e0+0x4+0x704]
/boot/modules/cb.ko text=0x63fc data=0x3b8+0x11c syms=[0x4+0xf20+0x4+0xe69]
/boot/modules/mesw.ko text=0x630c data=0x344+0x58 syms=[0x4+0xba0+0x4+0xe7a]
/boot/modules/cbd.ko text=0x1fcc data=0x9c+0xc syms=[0x4+0x540+0x4+0x445]
/boot/modules/sfccb.ko text=0xe30 data=0x1b0+0x14 syms=[0x4+0x540+0x4+0x4a5]
/boot/modules/mac_runasnonroot.ko text=0x7b4 data=0x4d0 syms=[0x4+0x310+0x4+0x39d]


Hit [Enter] to boot immediately, or space bar for command prompt.
Booting [/kernel]...               
platform_early_bootinit: M/T Series Early Boot Initialization
Olive CPU
GDB: debug ports: sio
[snip]


while the failing version does not cause this message:

olive@canardo:~$ kvm -L /usr/local/src/git/seabios/out -m 1024 -hda olive2.img  -nographic
-serial mon:stdio -monitor null 
Could not open option rom 'vapic.bin': No such file or directory
pci_add_option_rom: failed to find romfile "vgabios-cirrus.bin"
pci_add_option_rom: failed to find romfile "pxe-rtl8139.bin"
Consoles: serial port  
BIOS drive C: is disk0
BIOS 639kB/1047544kB available memory

FreeBSD/i386 bootstrap loader, Revision 1.1
(builder(a)ormonth.juniper.net, Tue Nov  3 08:19:23 UTC 2009)
Loading /boot/defaults/loader.conf 
/kernel text=0x74574c data=0x42ba0+0x92e34 syms=[0x4+0x7f570+0x4+0xb12b2]
/boot/modules/if_bge.ko text=0xa98c data=0x364+0xc syms=[0x4+0xd50+0x4+0xd18]
/boot/modules/mpt_core.ko text=0x18dbc data=0x488+0x358 
/boot/modules/if_bce.ko text=0xd07c data=0x16d94+0x24e4 syms=[0x4+0x14d0+0x4+0x1787]
/boot/modules/acb.ko text=0x3d78 data=0x284+0x80 syms=[0x4+0xa70+0x4+0x9a4]
/boot/modules/mcs.ko text=0x4dc0 data=0x391+0xeb syms=[0x4+0xc40+0x4+0xbc2]
/boot/modules/scs.ko text=0x7c08 data=0x564+0x164 syms=[0x4+0x1110+0x4+0x1179]
/boot/modules/rcb.ko text=0x29c8 data=0x184+0x2c syms=[0x4+0x7e0+0x4+0x704]
/boot/modules/cb.ko text=0x63fc data=0x3b8+0x11c syms=[0x4+0xf20+0x4+0xe69]
/boot/modules/mesw.ko text=0x630c data=0x344+0x58 syms=[0x4+0xba0+0x4+0xe7a]
/boot/modules/cbd.ko text=0x1fcc data=0x9c+0xc syms=[0x4+0x540+0x4+0x445]
/boot/modules/sfccb.ko text=0xe30 data=0x1b0+0x14 syms=[0x4+0x540+0x4+0x4a5]
/boot/modules/mac_runasnonroot.ko text=0x7b4 data=0x4d0 syms=[0x4+0x310+0x4+0x39d]


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 30: reserved (unknown) fault while in kernel mode
instruction pointer     = 0x20:0xc09ba131
stack pointer           = 0x28:0xc1021c6c
frame pointer           = 0x28:0xc1021ca4
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)(c0ba9440,c0ba9440,c0b40fd0,c1021bb4,5) at 0xc09a5757
(null)(c0b40fd0,1e,c1021c2c,1,1) at 0xc0593caf
(null)(c0b23132,0,c1021d14,c05b41e0,a) at 0xc09b9747
(null)(c1021c2c) at 0xc09ba631
(null)(c1021cb0) at 0xc09a6d8f
(null)(c1021d44,c0aa42a9,c0b42b37,c1021d34,c1021d30) at 0xc09a6d8f
(null)(c0b42b37,c1021d34,c1021d30,a,c1021d54) at 0xc09a001e
(null)(c0b21154,c0ad7f78,c1021d84,c09af90e,80) at 0xc0aa42a9
(null)(80,c09a6dd0,f,3,20) at 0xc0aa488e
(null)(1026000) at 0xc09af90e
(null)() at 0xc049bb8d
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xf000ff53
fault code              = supervisor write, page not present
instruction pointer     = 0x20:0xc05bc3bd
stack pointer           = 0x28:0xc1021920
frame pointer           = 0x28:0xc1021940
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 0 ()
trap number             = 12
dog: ERROR - reset of uninitialized watchdog
panic: page fault
XXXXX: ERROR platform_boot_mastership_relinquish not defined:XXXXXdog: ERROR - reset of
uninitialized watchdog
dog: ERROR - reset of uninitialized watchdog
Uptime: 1s



I guess this can affect the result if it means that SMBIOS is being
disabled/ignored. I can confirm Brandon's findings that disabling
CONFIG_SMBIOS on current head also gives me a working image.


Bjørn

SeaBIOS error with Juniper FreeBSD kernel

[Kevin O'Connor]

      On Tue, Apr 13, 2010 at 08:48:35PM +0200, Bjørn Mork wrote:
  Gleb Natapov <gleb(a)redhat.com&gt; writes:
  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:
 > I have narrowed it down to SMBIOS.  If I disable CONFIG_SMBIOS the
 > image boots up fine.
 If there is any seabios revision that works then it is
possible to
 bisect to find problematic commit.
 I'm also bitten by this and have now
attempted to bisect it.  The result
 was: 
 
 c95d2cee36db79c88253d43a90230ceadf0c26cf is first bad commit
 commit c95d2cee36db79c88253d43a90230ceadf0c26cf
It looks like memory layout changes in the f-segment is tickling the
underlying bug.  I don't think SMBIOS, the above commit, or the other
commit identified earlier are the root cause of the problem.  Instead,
I'd guess these commits just change the memory layout enough to avoid
the root cause.

This looks like it is going to require some careful study with a
debugger and some execution traces.  Unfortunately, since this image
isn't available for download it makes it difficult to track down.

-Kevin

SeaBIOS error with Juniper FreeBSD kernel

[Bjørn Mork]

      "Kevin O'Connor" <kevin(a)koconnor.net&gt; writes:

  It looks like memory layout changes in the f-segment
is tickling the
 underlying bug.  I don't think SMBIOS, the above commit, or the other
 commit identified earlier are the root cause of the problem.  Instead,
 I'd guess these commits just change the memory layout enough to avoid
 the root cause.
Sounds like a reasonable explanation.  Is there anything I can do to try
to pin down the problem?

  This looks like it is going to require some careful
study with a
 debugger and some execution traces.  Unfortunately, since this image
 isn't available for download it makes it difficult to track down.
I understand that.  But I'm afraid I can't provide any such image.

I don't think Juniper has done anything extra-ordinary at this point
however, so I'll try to see if I can create a freely distributable image
triggering the bug using the same tools as them.  Will let you know if I
succeed. 


Bjørn

SeaBIOS error with Juniper FreeBSD kernel

[Bjørn Mork]

      Bjørn Mork <bjorn(a)mork.no&gt; writes:
  "Kevin O'Connor"
<kevin(a)koconnor.net&gt; writes:

  It looks like memory layout changes in the
f-segment is tickling the
 underlying bug.  I don't think SMBIOS, the above commit, or the other
 commit identified earlier are the root cause of the problem.  Instead,
 I'd guess these commits just change the memory layout enough to avoid
 the root cause.
 Sounds like a reasonable explanation.  Is there anything I can do to try
 to pin down the problem?

  This looks like it is going to require some
careful study with a
 debugger and some execution traces.  Unfortunately, since this image
 isn't available for download it makes it difficult to track down.
 I understand that.  But I'm afraid I can't provide any such image.

 I don't think Juniper has done anything extra-ordinary at this point
 however, so I'll try to see if I can create a freely distributable image
 triggering the bug using the same tools as them.  Will let you know if I
 succeed.
It's been a while with little work and little progress on my side... But
I looked at this again today, and found that it may be related to the
SMBIOS table being allocated with malloc_high().  Does that make sense?

Anyway, the problematic OS boots without problems with current seabios
from git if I make this change:


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);




I tried malloc_low() too, and that works as well.  But malloc_fseg()
seems appropriate, unless I've misunderstood something here.  Which very
well can be.  I am not going to claim any understanding at all.

Does the above make any sense, or is this just another example of 
"tickling the underlying bug"?


Bjørn

SeaBIOS error with Juniper FreeBSD kernel

[Kevin O'Connor]

      On Thu, Jul 07, 2011 at 05:45:02PM +0200, Bjørn Mork wrote:
  It's been a while with little work and little
progress on my side... But
 I looked at this again today, and found that it may be related to the
 SMBIOS table being allocated with malloc_high().  Does that make sense?
 
 Anyway, the problematic OS boots without problems with current seabios
 from git if I make this change:
 
 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);
Thanks.

It's possible that the OS has an error in handling the SMBIOS when it
is in high-memory (located above 1meg).  (For example, older versions
of Linux crash when the mptable is in high memory.)

However, it would be really odd for the OS to work some times with the
SMBIOS in high memory and sometimes fail.

  I tried malloc_low() too, and that works as well.  But
malloc_fseg()
 seems appropriate, unless I've misunderstood something here.  Which very
 well can be.  I am not going to claim any understanding at all.
malloc_low and malloc_fseg would both put the table in the first
megabyte of physical ram.  Of the two, malloc_fseg would be
preferable.

  Does the above make any sense, or is this just another
example of 
 "tickling the underlying bug"?
I have to wonder if the reorganization of memory just caused the bug
to not pop up.  If you disable SMBIOS, can you confirm the problem
reliably goes away on multiple versions of SeaBIOS?

-Kevin

SeaBIOS error with Juniper FreeBSD kernel

[Bjørn Mork]

      "Kevin O'Connor" <kevin(a)koconnor.net&gt; writes:
  On Thu, Jul 07, 2011 at 05:45:02PM +0200, Bjørn Mork
wrote:
  It's been a while with little work and little
progress on my side... But
 I looked at this again today, and found that it may be related to the
 SMBIOS table being allocated with malloc_high().  Does that make sense?
 
 Anyway, the problematic OS boots without problems with current seabios
 from git if I make this change:
 
 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);
 Thanks.

 It's possible that the OS has an error in handling the SMBIOS when it
 is in high-memory (located above 1meg).  (For example, older versions
 of Linux crash when the mptable is in high memory.)
I looked at a couple of physical machines with vendor BIOSes, and they
seem to put the table in low memory:

# dmidecode 2.9
SMBIOS 2.4 present.
71 structures occupying 2506 bytes.
Table at 0x000F06F0.


# dmidecode 2.9
SMBIOS 2.4 present.
80 structures occupying 2858 bytes.
Table at 0x000E0010.


Makes me think that this would be the safest approach for SeaBIOS as
well.  With the patch above, I get this location:

# dmidecode 2.9
SMBIOS 2.4 present.
10 structures occupying 263 bytes.
Table at 0x000FDA00.


Without it, I get:

# dmidecode 2.9
SMBIOS 2.4 present.
10 structures occupying 263 bytes.
Table at 0x1FFFFEF0.



  However, it would be really odd for the OS to work
some times with the
 SMBIOS in high memory and sometimes fail.
Yes.  Just to be perfectly clear: The crash with SMBIOS in high memory
happens every time with "recent" (anything from 2009 or later) SeaBIOS
versions.

I must admit that I right now am wondering whether I somehow screwed up
the previous testing of older versions.  I am not at all sure under what
circumstances older SeaBIOS would work with SMBIOS enabled.

  I tried
malloc_low() too, and that works as well.  But malloc_fseg()
 seems appropriate, unless I've misunderstood something here.  Which very
 well can be.  I am not going to claim any understanding at all.
 malloc_low and malloc_fseg would both put the table in the first
 megabyte of physical ram.  Of the two, malloc_fseg would be
 preferable.
That's what I thought.  Glad I could be right about something :-)

  Does the above
make any sense, or is this just another example of 
 "tickling the underlying bug"?
 I have to wonder if the reorganization of memory just caused the bug
 to not pop up.  If you disable SMBIOS, can you confirm the problem
 reliably goes away on multiple versions of SeaBIOS?
Yes.  Tested with current HEAD and with a number of revisions around the
beginning of 2009, i.e. version 0.4.0.  Just to be sure, I selected an
intermediate version as well: 0.5.1.  And I can confirm that the problem
goes away there too when I disable SMBIOS.


Bjørn

SeaBIOS error with Juniper FreeBSD kernel

[Kevin O'Connor]

      On Fri, Jul 08, 2011 at 09:46:32AM +0200, Bjørn Mork wrote:
  "Kevin O'Connor"
<kevin(a)koconnor.net&gt; writes:
 > It's possible that the OS has an error in handling the SMBIOS when it
 > is in high-memory (located above 1meg).  (For example, older versions
 > of Linux crash when the mptable is in high memory.)
[...]
  However, it
would be really odd for the OS to work some times with the
 SMBIOS in high memory and sometimes fail.
 
 Yes.  Just to be perfectly clear: The crash with SMBIOS in high memory
 happens every time with "recent" (anything from 2009 or later) SeaBIOS
 versions.
 
 I must admit that I right now am wondering whether I somehow screwed up
 the previous testing of older versions.  I am not at all sure under what
 circumstances older SeaBIOS would work with SMBIOS enabled.
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
for the table it only checks the first 16byte aligned "_SM_" signature
it finds.

The first bug looks likely because when one runs QEmu with "-d
in_asm,int,exec" there is a "check_exception" near the end of the log
with an address that is similar to the address of the high-memory
SMBIOS table.

The second bug causes the OS to ignore the SMBIOS table if the SeaBIOS
code layout happens to put an "_SM_" signature on a 16byte boundary
before the real SMBIOS table - this led to "Bad SMBIOS data checksum"
messages.  When this happened, the OS would go on to boot okay because
it then didn't try to read the real SMBIOS table from high-memory.
Since SeaBIOS has the signature in its code (it needs it to build the
table) there was roughly a 1 in 16 chance that a random build would
happen to place code in a place that would confuse the OS and cause it
to ignore the real SMBIOS table.

Long story short, the Juniper OS probably started failing at commit
2929c352b but bisect didn't find it because random other builds would
pass due to the second bug.

  >> I tried malloc_low() too, and that works as
well.  But malloc_fseg()
 >> seems appropriate, unless I've misunderstood something here.  Which very
 >> well can be.  I am not going to claim any understanding at all.
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.

I'm not sure what to do.
-Kevin

SeaBIOS error with Juniper FreeBSD kernel

[Sebastian Herbszt]

      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

SeaBIOS error with Juniper FreeBSD kernel

[Brandon Bennett]

  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.

-Brandon