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

["Bjørn Mork" <bjorn@mork.no>]

"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