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

[Bjørn Mork]

"Kevin O'Connor" <address@hidden> writes:
> On Tue, Aug 02, 2011 at 11:33:09AM +0200, Bjørn Mork wrote:
>> "Kevin O'Connor" <address@hidden> writes:
>> > Also, it's possible the code could try to use the f-segment if there
>> > are less than say 16 cpus and use high memory when more cpus are
>> > present.
>> 
>> How about a variant over the last suggestion: Don't actually care bout
>> the number of CPUs, but just fall back to malloc_high if malloc_fseg
>> fails?
>
> This could make testing painful - small changes in the code could
> cause a different table layout that is OS visible.  I'd prefer a more
> strict cutoff.  Though, I suppose the cutoff could be by the table
> size itself instead of by number of CPUs.

This is of course your call to make...

But I must admit that I fail to see the advantage.  I agree that having
the table moved around depending on some variable is a problem.  Which
variable doesn't really matter. At least I don't see a fixed cutoff size
as any more predictable than a f-segment allocation failure, given that
I have no clue as to what SMBIOS table size is to be expected.  Maybe go
for the number of CPUs then.  But what if additional data is added to
the table, making f-segment allocation fail?  Then you will end up with
three different results depending on small changes instead of two:

 1) nCPU <= 16 and f-segment allocation OK: SMBIOS in f-segment
 2) nCPU > 16: SMBIOS in high mem
 3) nCPU <= 16 and f-segment allocation failed: no SMBIOS table

I don't think that makes testing any less painful...

Anyway, I would appreciate if some solution was found which allowed
JUNOS to boot with an unmodified SeaBIOS with SMBIOS enabled, as long as
the number of CPUs is limited.


Bjørn