From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [Bug #13116] Can't boot with nosmp Date: Tue, 9 Jun 2009 11:36:56 -0700 Message-ID: <20090609113656.46ed6335@nehalam> References: <20090608091544.53a94235@nehalam> <20090608170437.1c2386a5@nehalam> <4A2EAA53.7060006@redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4A2EAA53.7060006-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Avi Kivity Cc: Dan Williams , Rusty Russell , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List On Tue, 09 Jun 2009 21:30:43 +0300 Avi Kivity wrote: > Dan Williams wrote: > > On Mon, Jun 8, 2009 at 5:04 PM, Stephen Hemminger 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 > > 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org > > Reported-and-tested-by: Yinghai Lu > > Signed-off-by: Avi Kivity > > > > 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. --