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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

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 ?

--
Sander



Tuesday, August 3, 2010, 5:51:26 PM, you wrote:

>   On 08/03/2010 08:45 AM, Konrad Rzeszutek Wilk wrote:
>> On Tue, Aug 03, 2010 at 05:30:57PM +0200, Sander Eikelenboom wrote:
>>> Hi All,
>>>
>>> I'm experiencing for what it seems a random freeze with current 
>>> xen-4.0-testing, pvops dom0 2.6.32.16 kernel, most of the time within 2 
>>> days after rebooting.
>>>
>> You did not experience the freeze with 2.6.32.15?

> There have been a few updates to the .32.16 kernel too (and now its 
> .17...).  But it would be very useful to identify which the last working 
> kernel was.

>>> Symptoms:
>>> - Complete freeze, only power cycle does work.
>>> - No bug output/stacktrace in serial log / on screen.
>>> - Not able to get into hypervisor with ctrl-a (doesn't react to keyboard)
>>> - No info in syslog.
>>>
>>> Are there any more boot options I could give a try in the hope it will give 
>>> some debug output ?
>> The Linux kernel has some of those 'DETECT_SPINLOCK_HANG' or
>> 'DETECT_WORK..something' flags. It might be a good idea to compile those
>> and see when your machine freezes if after 2 minutes the kernel starts
>> spitting out what is hung. That could give some idea.
>>

> If Xen doesn't respond then it isn't a kernel spinlock problem; it looks 
> more system-wide than that.  I notice the kernel command line has lots 
> of hidden PCI devices.  Sander, is there any particular activity (esp 
> passthrough device activity) which might correspond to the hang?

>      J



-- 
Best regards,
 Sander                            mailto:linux@xxxxxxxxxxxxxx


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel