From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Steven Hand" Subject: Re: netfront.c: gnttab_query_foreign_access returns nonzero in network_tx_buf_gc Date: Thu, 25 May 2006 17:37:58 +0100 Message-ID: <04b301c68019$96989e80$0302a8c0@Violet> References: <447574C5.39DB.0076.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Kirk Allan , 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). Yes, this definitely looks like a bug; the 'break' in -unstable is not really much better than the 'goto out:' in -testing since in either case we can't easily correctly recover. > 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). Well all this means is that netback is still using the grant which should of course be impossible since the ring pointers have been advanced. I.e. something is borked. Can you try this with a debug build of xen? It would be interesting to see if xen complains about any grant refs prior to this occurance... cheers, S.