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] new netfront and occasional receive path lockup

To: Christophe Saout <christophe@xxxxxxxx>
Subject: Re: [Xen-devel] new netfront and occasional receive path lockup
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Mon, 23 Aug 2010 12:04:17 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 23 Aug 2010 09:06:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1282573612.7881.2.camel@xxxxxxxxxxxxxxxxxxxx>
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>
References: <1282495384.12843.11.camel@xxxxxxxxxxxxxxxxxxxx> <1282573612.7881.2.camel@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-12-10)
On Mon, Aug 23, 2010 at 04:26:52PM +0200, Christophe Saout wrote:
> Hi yet again,
> [not quoting everything again]
> I finally managed to trigger the issue on the test VM, which is now
> stuck in that state since last night and can be inspected.  Apparently
> the tx ring on the netback side is full, since every packet sent is
> immediately dropped (as seen from ifconfig output).  No interrupts
> moving on the guest.

What is the kernel and hypervisor in Dom0? And what is it in DomU?

> Still I'm wondering what would be the best course of action trying to
> debug this now.  Should I have compiled some debugger into the
> hypervisor? (gdbsx apparently needs that)

Sure. An easier path might be to do 'xm debug-keys q' which should
trigger the debug irq handler. In DomU that should print out all of the
event channel bits which we can analyze that and see if the
proper bits are not set (and hence the IRQ handler isn't picking up
from the ring buffer).

Xen-devel mailing list