[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [PATCH] SMP dom0 boot fix

Thanks Kier. With this fix applied, I am able to boot SMP dom0. The box
I am testing on is x86_64 machine with two hardware threads. However, if
I turn on SMT in the Linux configuration, the kernel takes a fault in
early startup (a NULL pointer reference at find_busiest_group +144). It
appears that the sched domain hierarchy is not correctly set up  here.
Looking at the new smpboot.c, is turning on SMT support no longer

K. Y
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 10/28/05 11:45 am >>> 

On 28 Oct 2005, at 16:15, Keir Fraser wrote:

> On 28 Oct 2005, at 15:59, Ryan Harper wrote:
>> At this point send_IPI_allbutself() has been invoked and the system
>> just sits and waits on CPU1 to run the function.  But, CPU1's
>> evtchn_upcall_mask was set (1), so I'm guessing the pending
>> is never acknowledged.
> Okay, the good news is that's the same bug I was able to repro last 
> week. Turns out that CPU1's upcall mask is getting weirdly set under

> its feet. Since it's waiting on the big kernel lock, which is held by

> CPU0, which is waiting for acknowledgement of an interrupt in CPU1,
> have a deadlock.
> Given the problem is in that one changeset, this can't be hard to 
> track down now.

Now fixed in our staging tree. sizeof_vcpu_shift in 
arch/xen/x86_64/xen_entry.S should be 4, not 3.

  --  Keir

Xen- devel mailing list
Xen- devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen- devel

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.