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/
Home Products Support Community News


[Xen-devel] netfront.c: gnttab_query_foreign_access returns non zero in

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] netfront.c: gnttab_query_foreign_access returns non zero in network_tx_buf_gc
From: "Kirk Allan" <kallan@xxxxxxxxxx>
Date: Thu, 25 May 2006 09:11:33 -0600
Delivery-date: Thu, 25 May 2006 08:12:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I've been working form the netfront.c in the testing tree and using SLES
10 RC1 for i386 on a SMP box.  When I stress the network using iperf in
a domU, domU acting as client on a gigabit network, I occasionally get a
panic at the dev_kfree_skb_irq(skb); line.  This is the same panic as
reported in

The trace  indicates that the skb is bad and it looks like the skb is
an id.  Investigating further, the condition occurs if the
gnttab_query_foreign_access returns non zero on a second or latter
iteration through the for loop.  If it return non zero, the the code
takes the 'goto out' which by passes fixing up  np->tx.rsp_cons.  Then
the next time in network_tx_buf_gc we reuse  np->tx.rsp_cons which is at
the location of a previously completed skb and the skb gets an id and
not a skb.

Looking at the unstable tree, the goto has been removed and replaced
with a break.  However, it looks like if gnttab_query_foreign_access
returns non zero between np->tx.rsp_cons and prod, then the 
np->tx.rsp_cons = prod; could advance  np->tx.rsp_cons too far causing
other problems latter (I have not tested this yet though).

The problem I'm having is that I can't find the root cause as to why
gnttab_query_foreign_access returns an 8 (GTF_reading?) and not 0.  I've
looked in netback.c and and xen/common/grant_table.c and am not seeing
it (not that it's not there).

Thanks for any help and understanding.

Xen-devel mailing list