From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: new netfront and occasional receive path lockup Date: Mon, 23 Aug 2010 17:53:13 -0700 Message-ID: <4C7317F9.2060009@goop.org> References: <1282495384.12843.11.camel@leto.intern.saout.de> <1282502275.14390.59.camel@leto.intern.saout.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1282502275.14390.59.camel@leto.intern.saout.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christophe Saout Cc: "Xu, Dongxiao" , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 08/22/2010 11:37 AM, Christophe Saout wrote: > 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? It depends on exactly how it is used. But any use cross-cpu shared memory must carefully consider access ordering, and possibly have explicit barriers to make sure that the expected ordering is actually seen by all cpus. J > 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@lists.xensource.com > http://lists.xensource.com/xen-devel >