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

["Ky Srinivasan" <ksrinivasan@xxxxxxxxxx>]

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
valid?

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
interrupt
>> 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,
we 
> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel