Re: [GIT]: Networking

From: Ayaz Abdulla
Date: Thu Jul 02 2009 - 19:00:15 EST




Eric Dumazet wrote:
Ayaz Abdulla a écrit :


Eric Dumazet wrote:

Eric Dumazet a écrit :


Ingo Molnar a écrit :


The following changes since commit
52989765629e7d182b4f146050ebba0abf2cb0b7:
Linus Torvalds (1):
Merge git://git.kernel.org/.../davem/net-2.6

are available in the git repository at:

master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master

Hm, something in this lot quickly wrecked networking here - see the
tx timeout dump below. It starts with:

[ 351.004596] WARNING: at net/sched/sch_generic.c:246
dev_watchdog+0x10b/0x19c()
[ 351.011815] Hardware name: System Product Name
[ 351.016220] NETDEV WATCHDOG: eth0 (forcedeth): transmit queue 0
timed out

Config attached. Unfortunately i've got no time to do bisection today.



forcedeth might have a problem, in its netif_wake_queue() logic, but
I could not see why a recent patch could make this problem visible now.

CPU0/1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
is not a new cpu either :)

forcedeth uses an internal tx_stop without appropriate barrier.

Could you try following patch ?

(random guess as I dont have much time right now)


Oh well this patch was soooo stupid, sorry Ingo.


We might have a race in napi_schedule(), leaving interrupts disabled
forever.
I cannot test this patch, I dont have the hardware...

Thanks

diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 1094d29..3b4e076 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -3514,11 +3514,13 @@ static irqreturn_t nv_nic_irq(int foo, void
*data)
nv_msi_workaround(np);

#ifdef CONFIG_FORCEDETH_NAPI
- napi_schedule(&np->napi);
-
- /* Disable furthur irq's
- (msix not enabled with napi) */
- writel(0, base + NvRegIrqMask);
+ if (napi_schedule_prep(&np->napi)) {
+ /*
+ * Disable further irq's (msix not enabled with napi)
+ */
+ writel(0, base + NvRegIrqMask);
+ __napi_schedule(&np->napi);
+ }

Yes, good catch. There is a race condition here with napi poll.

I would prefer to do the following to keep the code simple and clean.

writel(0, base + NvRegIrqMask);
napi_schedule(&np->napi);



CC trimmed down to network devs only :)

It would be racy too ...

check drivers/net/amd8111e.c, drivers/net/natsemi.c ...

If this cpu inconditionaly calls writel(0, base + NvRegIrqMask); while another cpu just called writel(np->irqmask, base + NvRegIrqMask),
we end with disabled interrupts ?
<BCC linux-kernel>

Yes, but the next instruction is to call napi_schedule() which will re-enable interrupts in napi function.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/