8:39 p.m.
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> 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
9:41 p.m.
New subject: [Qemu-devel] SeaBIOS error with Juniper FreeBSD kernel
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>
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.
8:48 p.m.
New subject: SeaBIOS error with Juniper FreeBSD kernel
Gleb Natapov <gleb(a)redhat.com> 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>
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
3:27 a.m.
New subject: SeaBIOS error with Juniper FreeBSD kernel
On Tue, Apr 13, 2010 at 08:48:35PM +0200, Bjørn Mork wrote:
Gleb Natapov <gleb(a)redhat.com> 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
12:51 p.m.
New subject: SeaBIOS error with Juniper FreeBSD kernel
"Kevin O'Connor" <kevin(a)koconnor.net> 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
5:45 p.m.
New subject: SeaBIOS error with Juniper FreeBSD kernel
Bjørn Mork <bjorn(a)mork.no> writes:
"Kevin O'Connor" <kevin(a)koconnor.net> 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
1:50 a.m.
New subject: SeaBIOS error with Juniper FreeBSD kernel
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
9:46 a.m.
New subject: SeaBIOS error with Juniper FreeBSD kernel
"Kevin O'Connor" <kevin(a)koconnor.net> 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
10:41 p.m.
New subject: SeaBIOS error with Juniper FreeBSD kernel
On Fri, Jul 08, 2011 at 09:46:32AM +0200, Bjørn Mork wrote:
"Kevin O'Connor" <kevin(a)koconnor.net> 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
11:25 p.m.
New subject: SeaBIOS error with Juniper FreeBSD kernel
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
2901
days inactive
3399
days old
10 comments
5 participants
participants (5)
-
Bjørn Mork -
Brandon Bennett -
Gleb Natapov -
Kevin O'Connor -
Sebastian Herbszt