From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: new netfront and occasional receive path lockup Date: Mon, 23 Aug 2010 12:04:17 -0400 Message-ID: <20100823160417.GA19344@phenom.dumpdata.com> References: <1282495384.12843.11.camel@leto.intern.saout.de> <1282573612.7881.2.camel@leto.intern.saout.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1282573612.7881.2.camel@leto.intern.saout.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christophe Saout Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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).