Re: [SeaBIOS] SeaBIOS error with Juniper FreeBSD kernel
Brandon Bennett <bennetb@gmail.com> writes:
Are all versions based on FreeBSD 4.11? Are newer versions still affected?
Newer versions should be based on 6.1 but there are a lot of changes. I haven't had a chance to test with something newer yet.
Sorry for the delay due to vacation... I just confirmed the issue running "JUNOS 11.1R3.5 built 2011-06-25 00:17:21 UTC" which is as new as it officially gets at the moment. I don't think the FreeBSD version really matters. I believe the issue is related to the "platform_early_bootinit", whatever that is, which is Juniper specific code. I assume they are checking the SMBIOS for some data which is present on the real hardware, and this check triggers the crash.
From the 11.1R3.5 boot:
Hit [Enter] to boot immediately, or space bar for command prompt. Booting [/kernel]... platform_early_bootinit: M/T Series Early Boot Initialization kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0xbff3fffc fault code = supervisor write, page not present instruction pointer = 0x20:0xc0a22377 stac Fatal trap 30: reserved (unknown) fault while in kernel mode instruction pointer = 0x20:0xc09f4e66 stack pointer = 0x28:0xc1021a00 frame pointer = 0x28:0xc1021a10 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 0 () trap number = 30 dog: ERROR - reset of uninitialized watchdog panic: reserved (unknown) fault (null)(c0c4f4a0,c0c4f4a0,c0be3672,c1021948,a) at 0xc0a14867 (null)(c0be3672,1e,c10219c0,1,1) at 0xc05a723e (null)(a,0,a,ffff7fff,ffffffff) at 0xc0a289dd (null)(c10219c0) at 0xc0a29921 (null)(0,c021b4b,3030000,c0c22a00,c0c54400) at 0xc0a15e7b (null)(c0c22a00,63,5,c1021bac,63) at 0xc09f50c2 (null)(63,10,1000000,1,c0bbe530) at 0xc05e66f3 (null)(63,c1021bac,c0be340e,3f8,1002580) at 0xc05c7ca5 (null)(c0bbe52c,c05c7c45,c1021bac,a,c1021bcc) at 0xc05c7df5 (null)(c0bbe52c,28,c1021cc4,c0be33fe,a) at 0xc05c8f73 (null)(c0c4d0a0,c1021c84,c1021c38,c05c8f73,c0bbe604) at 0xc0a287da (null)(c0bbe604,c,0,0,0) at 0xc0a28c2a (null)(c1021c84) at 0xc0a296e8 (null)(cffffef0,ffffef0,4,c00e0000,c00e0000) at 0xc0a15e7b (null)(0,c0bc71c6,4,10,0) at 0xc0a0f7df (null)(c0be5837,c1021d34,c1021d30,a,c1021d54) at 0xc0a0f8ed (null)(c0bc1e40,c0b6f924,c1021d84,c0a1e5a9,80) at 0xc0b3a694 (null)(80,c0a15ec0,f,3,20) at 0xc0b3ad7b (null)(1026000) at 0xc0a1e5a9 (null)() at 0xc04aa67d dog: ERROR - reset of uninitialized watchdog dog: ERROR - reset of uninitialized watchdog Uptime: 1s Also confirmed that 11.1R3.5 is working with SeaBIOS modified as follows: 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); Bjørn
On Mon, Aug 01, 2011 at 03:49:11PM +0200, Bjørn Mork wrote:
I just confirmed the issue running
"JUNOS 11.1R3.5 built 2011-06-25 00:17:21 UTC"
which is as new as it officially gets at the moment. [...] Also confirmed that 11.1R3.5 is working with SeaBIOS modified as follows: [...] - void *finaltable = malloc_high(structure_table_length); + void *finaltable = malloc_fseg(structure_table_length);
I'm not really sure how best to handle this. The smbios table can be larger than the current space reserved for the f-segment (when there are a large number of CPUs). Some ideas: There is actually space in the f-segment that is unused, but not given to the malloc_fseg pool. That space could be given to the pool - though the available space will still vary depending on the code size. It's also possible to relocate the 32bit "run-time" code to high memory which would then free up more space in the f-segment (at the cost of some high memory being reserved from the OS). As above, though, the f-segment is still fundamentally limited by the 16bit code size. 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. -Kevin
"Kevin O'Connor" <kevin@koconnor.net> writes:
On Mon, Aug 01, 2011 at 03:49:11PM +0200, Bjørn Mork wrote:
I just confirmed the issue running
"JUNOS 11.1R3.5 built 2011-06-25 00:17:21 UTC"
which is as new as it officially gets at the moment. [...] Also confirmed that 11.1R3.5 is working with SeaBIOS modified as follows: [...] - void *finaltable = malloc_high(structure_table_length); + void *finaltable = malloc_fseg(structure_table_length);
I'm not really sure how best to handle this. The smbios table can be larger than the current space reserved for the f-segment (when there are a large number of CPUs).
Some ideas:
There is actually space in the f-segment that is unused, but not given to the malloc_fseg pool. That space could be given to the pool - though the available space will still vary depending on the code size.
It's also possible to relocate the 32bit "run-time" code to high memory which would then free up more space in the f-segment (at the cost of some high memory being reserved from the OS). As above, though, the f-segment is still fundamentally limited by the 16bit code size.
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? The attached patch works-for-me, and boots JUNOS as long as the number of CPUs is low enough for malloc_fseg to succeed. Bjørn
On Tue, Aug 02, 2011 at 11:33:09AM +0200, Bjørn Mork wrote:
"Kevin O'Connor" <kevin@koconnor.net> 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. -Kevin
"Kevin O'Connor" <kevin@koconnor.net> writes:
On Tue, Aug 02, 2011 at 11:33:09AM +0200, Bjørn Mork wrote:
"Kevin O'Connor" <kevin@koconnor.net> 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
On 08/03/2011 03:42 PM, Bjørn Mork wrote:
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.
Is fixing JUNOS out of the question? AFAICT, Seabios complies with all relevant standards. -- error compiling committee.c: too many arguments to function
Avi Kivity <avi@redhat.com> writes:
On 08/03/2011 03:42 PM, Bjørn Mork wrote:
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.
Is fixing JUNOS out of the question?
Yes, I would say so. The ability to run it on non-Juniper hardware is undocumented and unsupported to the degree that the functionality probably rather would be removed than fixed to support something like SeaBIOS.
AFAICT, Seabios complies with all relevant standards.
Yes, I have no reason to believe otherwise. But still it does behave sufficiently different from other BIOSes for low CPU count machines to fail in this particular case. I see this as another end of the discussion about whether Linux should try to configure PC hardware in the same manner as Windows, as that is the configuration which will be tested by hardware vendors. Most OS vendors will test their systems with the big proprietary BIOSes and not with SeaBIOS. Does that make sense? Bjørn
On 08/03/2011 04:48 PM, Bjørn Mork wrote:
Is fixing JUNOS out of the question?
Yes, I would say so. The ability to run it on non-Juniper hardware is undocumented and unsupported to the degree that the functionality probably rather would be removed than fixed to support something like SeaBIOS.
AFAICT, Seabios complies with all relevant standards.
Yes, I have no reason to believe otherwise. But still it does behave sufficiently different from other BIOSes for low CPU count machines to fail in this particular case.
I see this as another end of the discussion about whether Linux should try to configure PC hardware in the same manner as Windows, as that is the configuration which will be tested by hardware vendors. Most OS vendors will test their systems with the big proprietary BIOSes and not with SeaBIOS.
Does that make sense?
It does, I wasn't sure if you're working on behalf of Juniper or not. I guess the options are: - build time switch - run time switch, controlled by qemu via fwcfg - run time decision based on size - do nothing -- error compiling committee.c: too many arguments to function
On Wed, Aug 03, 2011 at 02:42:15PM +0200, Bjørn Mork wrote:
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
If a reasonable limit is placed on the size of the SMBIOS table then in practice the allocation will always succeed. All of the f-segment allocations with the exception of the mptable are small. The mptable allocation should probably have an upper bound placed on it as well. There's currently 2048 bytes reserved for malloc_fseg (CONFIG_MAX_BIOSTABLE), and the current smbios uses 263 bytes with one cpu and 938 bytes with 16 cpus (memory size may also change size slightly). -Kevin
于 2011-8-4 7:48, Kevin O'Connor 写道:
On Wed, Aug 03, 2011 at 02:42:15PM +0200, Bjørn Mork wrote:
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
If a reasonable limit is placed on the size of the SMBIOS table then in practice the allocation will always succeed.
All of the f-segment allocations with the exception of the mptable are small. The mptable allocation should probably have an upper bound placed on it as well. There's currently 2048 bytes reserved for malloc_fseg (CONFIG_MAX_BIOSTABLE), and the current smbios uses 263 bytes with one cpu and 938 bytes with 16 cpus (memory size may also change size slightly).
-Kevin
_______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios In which situation would we allocate more that 16 VCPUS in qemu for 1 VM? I remember the performance is not very good when the number of virtual CPU is more than the real number of host's, So could we just put a limit about it, for a simple solution?
-- Best Regards Wayne Xia mail:xiawenc@linux.vnet.ibm.com tel:86-010-82450803
On Thu, Aug 04, 2011 at 10:42:45AM +0800, Wayne Xia wrote:
于 2011-8-4 7:48, Kevin O'Connor 写道:
On Wed, Aug 03, 2011 at 02:42:15PM +0200, Bjørn Mork wrote:
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
If a reasonable limit is placed on the size of the SMBIOS table then in practice the allocation will always succeed.
All of the f-segment allocations with the exception of the mptable are small. The mptable allocation should probably have an upper bound placed on it as well. There's currently 2048 bytes reserved for malloc_fseg (CONFIG_MAX_BIOSTABLE), and the current smbios uses 263 bytes with one cpu and 938 bytes with 16 cpus (memory size may also change size slightly). In which situation would we allocate more that 16 VCPUS in qemu for 1 VM? I remember the performance is not very good when the number of virtual CPU is more than the real number of host's, So could we just put a limit about it, for a simple solution?
Limit the total number of CPUs? No - it's useful to be able to simulate many cpus. As before, we can limit the situations where smbios is put into low mem though. -Kevin
On Thu, Aug 04, 2011 at 10:42:45AM +0800, Wayne Xia wrote:
In which situation would we allocate more that 16 VCPUS in qemu for 1 VM? I remember the performance is not very good when the number of virtual CPU is more than the real number of host's, So could we just put a limit about it, for a simple solution?
What kind of low spec HW are you using that does not have more then 16 real cpus? -- Gleb.
participants (5)
-
Avi Kivity -
Bjørn Mork -
Gleb Natapov -
Kevin O'Connor -
Wayne Xia