From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Harper Subject: Re: Re: [PATCH] SMP dom0 boot fix Date: Fri, 28 Oct 2005 11:07:18 -0500 Message-ID: <20051028160718.GM22394@us.ibm.com> References: <5916684ed3d62883c5aa18c358b24b21@cl.cam.ac.uk> <20051028145930.GL22394@us.ibm.com> <537fa3b9fb43e4581f282edb2ced8627@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <537fa3b9fb43e4581f282edb2ced8627@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Ian Pratt , xen-devel List-Id: xen-devel@lists.xenproject.org * Keir Fraser [2005-10-28 10:41]: > > 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. That fixed it for me here. Thanks! -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com