[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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
http://lists.xensource.com/archives/html/xen-devel/2006-05/msg00919.html

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.
Kirk


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