On Tue, 09 Jun 2009 21:30:43 +0300 Avi Kivity <avi@xxxxxxxxxx> wrote: > Dan Williams wrote: > > On Mon, Jun 8, 2009 at 5:04 PM, Stephen Hemminger<shemminger@xxxxxxxxxx> wrote: > > > >> I did some more debugging, and the problem appears to be that > >> booting with nosmp still leaves all the CPU's present in the cpu > >> possible mask. So code like dma engine (or loopback device), that > >> use alloc_percpu get broken. > >> > >> Not sure why all the cpu's are still showing up in the possible mask. > >> Rusty? do you have an answer. > >> > > > > Would this recent commit also fix this issue? > > > > commit a4c0364be3f43d3e17fe19270f8b3d64881606e6 > > Author: Avi Kivity <avi@xxxxxxxxxx> > > Date: Sat Jun 6 12:34:39 2009 +0300 > > > > KVM: Explicity initialize cpus_hardware_enabled > > > > Under CONFIG_MAXSMP, cpus_hardware_enabled is allocated from the heap and > > not statically initialized. This causes a crash on reboot when kvm thinks > > vmx is enabled on random nonexistent cpus and accesses nonexistent percpu > > lists. > > > > Fix by explicitly clearing the variable. > > > > Cc: stable@xxxxxxxxxx > > Reported-and-tested-by: Yinghai Lu <yinghai@xxxxxxxxxx> > > Signed-off-by: Avi Kivity <avi@xxxxxxxxxx> > > > > This only affects reboots. But yes, the cpumask code has bugs. Does > the .config involved select MAXSMP? > Patch does not fix the problem. Not sure if it is KVM only problem. Look like possible cpumask always equals what ACPI / SMP tables report. So currently looking into alloc_percpu which may not handle the possible but never used cpus. It is x86-64 config and does not have MAXSMP set. It does have NR_CPUS set. -- -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
