|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Network drop to domU (netfront: rx->offset: 0, size: 429
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
|
|
|
|
|