Re: [xen-4.0.1-rc5-pre] [pvops 2.6.32.16] Complete freeze within 2 days, no info in serial log

[Konrad Rzeszutek Wilk <konrad.wilk@Oracle.COM>]

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?

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.