[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Network drop to domU (netfront: rx->offset: 0, size: 4294967295)



On 20/05/2009 05:50, "PCextreme B.V. - Wido den Hollander"
<wido@xxxxxxxxxxxx> wrote:

>> If it's an issue that crops up with many guests then I suppose it's
> more likely a netback issue, which is a pain.
> 
> I already assumed this would be a pain, any way to determine if it is a
> netback issue? Adding some verbose messages to the kernel?

The visible effects of the bug start in dom0, when it presents a buffer
reference (aka a 'grant reference') to Xen as provided to it by domU. Xen
notes that the grant reference is bogus (the xm dmesg output shows the flag
field of the grant is zero, which means it's currently unused). Now, does
that mean domU forgot to initialise the buffer grant, or got out of sync
somehow, or is the dom0 which has got out of sync? It's rather hard to tell.
But dom0 is more likely to be affected by scaling to large numbers of
domains than a domU is. The logic in domU netfront doesn't change, whereas
dom0 netback has the actual multiplexing job. Hence dom0 is more likely to
be the culprit.

If you define DEBUG at the very top of dom0's drivers/xen/netback/netback.c
you will get more debug output from dom0 kernel when things go wrong. It may
be not much extra help unfortunately, but extra tracing could be added I
suppose (the pain being of course that each such change will require a dom0
reboot or a netback module reload, which itself may require domains to be
restarted).

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.