Re: [Xen-devel] new netfront and occasional receive path lockup

[Christophe Saout <christophe@xxxxxxxx>]

Hi again,

> I've been looking at the code, if there might be a race condition
> somewhere, something like where one could run into a situation where the
> hrtimer doesn't run and Dom0 believes the DomU should be polling and
> doesn't emit an interrupt or something, but I'm afraid I don't know
> enough to judge this (I mean, there are spinlocks which look safe to
> me).

Hmm, looking a bit more.

rx.sring->private.netif.smartpoll_active lies in a piece of memory that
is shared between netback and netfront, is that right?

If that is so, the tx spinlock in netfront only protects against
simultaneous modifications from another thread in netfront, so netback
can read smartpoll_active while netfront is fiddling with it.  Is that
safe?

Note that when the lockup occurs, /proc/interrupts in the guest doesn't
show any interrupts arriving from for eth0 anymore.  Are there any
conditions where netback waits for netfront to retrieve packages even
when new packages arrive? (like e.g. when the ring is full and there is
backlog into the network stack or something?) Any way to debug this from
the Dom0 side?  Like looking into the state of the ring from userspace?
Debug options?

        Christophe



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