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

[Kevin O'Connor <kevin@koconnor.net>]

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