On Tue, 09 Jun 2009 21:30:43 +0300 Avi Kivity <[email protected]> wrote:
> Dan Williams wrote: > > On Mon, Jun 8, 2009 at 5:04 PM, Stephen Hemminger<[email protected]> > > 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 <[email protected]> > > 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: [email protected] > > Reported-and-tested-by: Yinghai Lu <[email protected]> > > Signed-off-by: Avi Kivity <[email protected]> > > > > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
