[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |