Re: new netfront and occasional receive path lockup

[Christophe Saout <christophe@saout.de>]

Hi Konrad,

> > 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?

The hypervisor is from the Xen 4.0.0 release and the Dom0 is from
Jeremy's 2.6.32 stable branch for pvops Dom0 (and lately with the
xen/dom0/backend branches merged in top because I hoped there might be
some fixes that help).  The same kernel has been working fine as guest,
but my newer one where I took an upstream 2.6.35, applied some of the
upstream fixes branches and also pulled the xen/netfront in, is now
causeing this issue.  Everything else is working just fine, so I am
pretty sure it is related to a netfront-specific change and not to
anything else.

> > hypervisor? (gdbsx apparently needs that)
> 
> Sure.

Also, I noticed that "gdb /path/to/vmlinux /proc/kcore" does allow me to
inspect the memory.  I'll try to see if I can pinpoint some of the
interesting memory locations.

> 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).

I'm not exactly sure how to read the output of that.
http://www.saout.de/assets/xm-debug-q.txt

	Christophe