[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081025.001703.261277154.davem@davemloft.net>
Date: Sat, 25 Oct 2008 00:17:03 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: cfriesen@...tel.com
Cc: linuxppc-dev@...abs.org, romieu@...zoreil.com,
jesse.brandeburg@...el.com, netdev@...r.kernel.org
Subject: Re: [BUG] oops in net_rx_action on 64-bit powerpc
From: "Chris Friesen" <cfriesen@...tel.com>
Date: Fri, 24 Oct 2008 23:42:48 -0600
> David Miller wrote:
> > From: "Chris Friesen" <cfriesen@...tel.com>
> > Date: Fri, 24 Oct 2008 17:39:00 -0600
> >
> >> So...it would appear that the NAPI code is somehow buggy, and
> >> 6ba33ac should probably be reverted until the problem is found and
> >> fixed.
> > No I think the problem is simple enough that someone should study the
> > ->poll() routine quickly and audit it's return values.
>
> Assuming that amd8111e_rx_poll() is the proper routine, there is
> only one exit point, and it returns "num_rx_pkt". This variable is
> initialized to zero and increments for each packet sent up the
> stack.
The problematic case in this routine seem to be when the driver
processes exactly "budget" number of packets.
In this case it should not call __netif_rx_complete(), it should instead
use the rx_not_empty label.
Probably the simplest fix is to get rid of the rx_not_empty label and
protect the entire:
/* Receive descriptor is empty now */
spin_lock_irqsave(&lp->lock, flags);
__netif_rx_complete(dev, napi);
writel(VAL0|RINTEN0, mmio + INTEN0);
writel(VAL2 | RDMD0, mmio + CMD0);
spin_unlock_irqrestore(&lp->lock, flags);
code block with a test such as:
if (rx_pkt_limit > 0)
(yes, greater than zero, not >= 0)
then replace the rx_not_empty goto with a simple break.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists