WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] new netfront and occasional receive path lockup
From: Christophe Saout <christophe@xxxxxxxx>
Date: Sun, 22 Aug 2010 20:37:55 +0200
Delivery-date: Sun, 22 Aug 2010 11:38:46 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=saout.de; s=default; t=1282502278; bh=rSl2+q2fmKkqH9epDr5iG2p3FoM/o5lSd//Gvf00qhs=; h=Subject:From:In-Reply-To:References:Date:Message-ID; b=JMguU5VO0rAgFmubcvjRA23o1bXwU1b0mBEnmCVe4mSdVOpqUKdfjLcCDpP+jBS9W IGduJNNqAyx5E+wwwL/SMIExRECBVdy18ONUKpAiWKzJpuKCD0/rr4Vn8UNYE9Sj7U QMmHtYUwJ1CPAPs2WWO2keelV4PAAeMsOte6xsog=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1282495384.12843.11.camel@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1282495384.12843.11.camel@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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