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

[Bjørn Mork]

Bjørn Mork <address@hidden> writes:
> "Kevin O'Connor" <address@hidden> 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