This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [xen-4.0.1-rc5-pre] [pvops] Complete freeze wi

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] [xen-4.0.1-rc5-pre] [pvops] Complete freeze within 2 days, no info in serial log
From: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
Date: Thu, 5 Aug 2010 17:12:30 +0200
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 05 Aug 2010 08:30:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100805145214.GC5697@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Eikelenboom IT services
References: <698099271.20100803173057@xxxxxxxxxxxxxx> <20100803154541.GA16122@xxxxxxxxxxxxxxxxxxx> <4C583AFE.7080001@xxxxxxxx> <1048476317.20100805114844@xxxxxxxxxxxxxx> <20100805145214.GC5697@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Konrad,

Thx for your response, and i saw Linus pulled the swiotlb code .. way to go !

Thursday, August 5, 2010, 4:52:14 PM, you wrote:

> On Thu, Aug 05, 2010 at 11:48:44AM +0200, Sander Eikelenboom wrote:
>> Hi Konrad/Jeremy,
>> I have tested the last 2 days with the vm's with passthroughed devices 
>> shutdown, and no freeze so far.
>> I'm running now with one of the vm's that runs an old 2.6.33 kernel from an 
>> old tree from Konrad together with some hacked up patches for xhci/usb3 
>> support.
>> That seems to be running fine for some time now (although not a full 2 days 
>> yet).
>> So my other vm seems to cause the freeze.
>> - This one uses the devel/merge.2.6.35-rc6.t2 as domU kernel, i think i 
>> should try an older version of pci-front/xen-swiotlb perhaps.
>> - It has both a usb2 and usb3 controller passed through, but the xhci module 
>> has much changed since the hacked up patches from the kernel in de working 
>> domU vm
>> - Most probably the drivers for the videograbbers will have changed
>> So i suspect:
>>    - newer pci-front / xen-swiotlb
>>    - xhci/usb3 driver
>>    - drivers videograbber
>> Most probable would be a roque dma transfer that can't be catched by xen / 
>> pciback I guess, and therefore would be hard to debug ?

> The SWIOTLB "brains" by themselves haven't changed since the
> uhh...2.6.33. The code internals that just got Ack-ed upstream looks quite
> similar to the one that Jeremy carries in xen/stable-2.6.32.x. The
> outside plumbing parts are the ones that changed.

> The fixes in the pci-front, well, most of those are "burocractic" in
> nature - set the ownership to this, make hotplug work, etc. The big
> fixes were the MSI/MSI-X ones but those were big news a couple of months
> ago (and I think that was when 2.6.34 came out).

> The videograbber (vl4) stack trace you sent to me some time ago looked
> liked a mutex was held for a very very long time... which I wonder if
> that is the cmpxch compiler bug that has hit some folks. Are you using
> Debian?

Yes i'm using Debian, i saw that bug fix too, but since Jeremy didn't include 
it in stable yet i also didn't :-)
Well you gave me a pointer here, looking again it seems to hang on the device 
on the usb2 controller and not the usb3.
So to rule out the usb3 stuff i will drop that usb2 controller and see if that 
works. If so, it must be a problem in the driver.
Since that grabber + usb2 controller worked for quite a while grabbing 

> But we can do something easy. I can rebase my 2.6.33 kernel with the
> latest Xen-SWIOTLB/SWIOTLB engine + Xen PCI front, and we can eliminate the
> SWIOTLB/PCIfront being at fault here.. Let me do that if your  2.6.33
> VM guest is running fine for the last two days.

I will first try the above, if that doesn't work out,  i will try the 2.6.33 
again for longer and report back !

Thx Again !

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>