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



Hi,

Thank you for your explanation. I'm on a short holiday starting tonight,
so i won't be able to rebuild a new kernel until next week.

My tests are running, they are simple HTTP-checks with a interval of 2
seconds. The two domU's on the same dom0.

I'll keep this running for a few days and get back with some results.

-  
Met vriendelijke groet,

Wido den Hollander
Hoofd Systeembeheer / CSO
Telefoon Support Nederland: 0900 9633 (45 cpm)
Telefoon Support BelgiÃ: 0900 70312 (45 cpm)
Telefoon Direct: (+31) (0)20 50 60 104
Fax: +31 (0)20 50 60 111
E-mail: support@xxxxxxxxxxxx
Website: http://www.pcextreme.nl
Kennisbank: http://support.pcextreme.nl/
Netwerkstatus: http://nmc.pcextreme.nl


On Wed, 2009-05-20 at 06:01 -0700, Keir Fraser wrote:
> 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
> 
> 

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
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®.