Bjørn Mork bjorn@mork.no writes:
"Kevin O'Connor" kevin@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