From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kirk Allan" Subject: netfront.c: gnttab_query_foreign_access returns non zero in network_tx_buf_gc Date: Thu, 25 May 2006 09:11:33 -0600 Message-ID: <447574C5.39DB.0076.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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