From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [pciback] BUG: spinlock wrong CPU on CPU#2, xenwatch/40 lock: ffff88001dd9d310, .magic: dead4ead, .owner: xenwatch/40, .owner_cpu: 0 Date: Wed, 10 Nov 2010 09:27:26 -0500 Message-ID: <20101110142726.GB16120@dumpdata.com> References: <179943669.20101110101110@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <179943669.20101110101110@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Sander Eikelenboom Cc: "Xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Wed, Nov 10, 2010 at 10:11:10AM +0100, Sander Eikelenboom wrote: > Hi Konrad, > > I saw you have made a branch for upstream pciback in your tree ? Wow, you are quick, I just made it on Monday. There is still some extra work required as the 2.6.37-rc1 does not have the XenBus backend up-ported. So that branch is not ready. > I have one request, would it be possible to allow a wildcard (*) for the function .. so xen-pciback.hide=(04:00.*) would work just as it does in the domU .cfg ? Good idea - will do it. > > Apart from that i sometimes get this when starting a domain with pci devices passed through: > > Nov 10 09:48:04 localhost kernel: [ 893.055513] BUG: spinlock wrong CPU on CPU#2, xenwatch/40 > Nov 10 09:48:04 localhost kernel: [ 893.056268] lock: ffff88001dd9d310, .magic: dead4ead, .owner: xenwatch/40, .owner_cpu: 0 Yeah, that one is tied in the fact that the XenBus backend thread is taking the spinlock and in pciback we call xenstore, which can go to sleep, and then we can wake up on another CPU. I need to talk to Ian about the XenBus thread to see how this can be made safe.