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