I'm not sure if it was obvious, but yesterday I noticed that setting the
"MPS table mode" to 'Disabled' actually made SMP stop working, i.e. the
kernel only recognized a single CPU. This is of course not an option, so
I enabled (set to 'Full Table APIC') the setting again and played around
with my kernel config a bit. The kernel that crashed had
CONFIG_X86_MPPARSE=y, and if I disable that, it boots fine (with SMP,
and with the BIOS setting set to 'Full Table APIC').
So, I for one am quite happy now as I finally found a working
configuration. But I'd still like to know if this is a hardware-specific
issue, and/or a bug in Xen.
Konrad Rzeszutek Wilk wrote, on 10/31/2011 03:08 PM:
> Oh nice. What does you /proc/interrupts look like compared to
> baremetal?
While I was performing all my kernel tests, I saved the outputs of
`dmesg` and `cat /proc/interrupts`. Sorry for attaching a tarball, but
I'd like to give you as much information as possible. You'll probably
only need the latest tests (#5 to #7), but just in case, I also included
the others.
Contents of the tarball:
Baremetal tests:
xen-hp/1/: MPS mode 'Full Table APIC', CONFIG_X86_MPPARSE=y, SMP working
xen-hp/2/: MPS mode 'Full Table APIC', CONFIG_X86_MPPARSE=n, SMP working
xen-hp/3/: MPS mode 'Disabled', CONFIG_X86_MPPARSE=y, SMP not working
xen-hp/4/: MPS mode 'Disabled', CONFIG_X86_MPPARSE=n, SMP not working
Xen tests:
xen-hp/5/: MPS mode 'Disabled', CONFIG_X86_MPPARSE=n, SMP not working
xen-hp/6/: MPS mode 'Full Table APIC', CONFIG_X86_MPPARSE=n, SMP working
xen-hp/7/: MPS mode 'Full Table APIC', CONFIG_X86_MPPARSE=y, CRASHES
(Therefore, #6 is the best working solution; #7 is what originally
triggered the crash.)
Thanks.
xen-hp.tar.bz2
Description: application/bzip
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home