g_timer, jiffies + 2 * HZ);
> + /* fire a link change interrupt to start the watchdog */
> + E1000_WRITE_REG(&adapter->hw, ICS, E1000_ICS_LSC);
> return 0;
> }
Hi Auke,
Could you explain the race, how it would be triggered, and what it might
look like if it were
on of the NIC, but the weird packets did not
appear on there at all. I have seen this problem personally, but that box
seems to have disappeared.
Is there any reason these packets would not be reported in the above
statistics? And if an interrupt sharing error is out, where could these
pac
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: g
Wake-on: d
Current message level: 0x0007 (7)
Link detected: yes
Any ideas? or debugging info greatly appreciated.
Thanks,
Shaw
es are a pain. The watchdog timer task
had a couple of race conditions that were thought to be better fixed by
removing it all together. Please, let's not go down that road again!
Check out what you have to say about it, Auke. ;)
http://www.spinics.net/lists/netdev/msg03656.html
Shaw
-
To unsu
0;
> +
> +err_out_exit:
> + kmem_cache_destroy(kevent_cache);
> + return err;
> +}
It's probably best to treat kmem_cache_create like a black box and check for
it returning null.
Thanks,
Shaw
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
d the tx
>> timeouts we've seen reported in this list? The watchdog will eventually
>> find the "lost" skbuff and mistakenly think that the hardware transmit
>> has
>> hung and stop the queue.
>>
>> Could one of you plese tell me how this r
rhaps this could be the culprit behind the tx
timeouts we've seen reported in this list? The watchdog will eventually
find the "lost" skbuff and mistakenly think that the hardware transmit has
hung and stop the queue.
Could one of you plese tell me how this race is avoided, if indeed
vailable ;)
Would one of you pplease give an update on the status of the bug? If a cause
was ever found and if the tx_timeout_factor was intended as a fix or
temporary workaround? I feel like I must have missed something, because I
never saw the tx_timeout_factor patch go through netdev at all..
used to sleep instead of the
watchdog_task approach. Perhaps I missed the discussion of this, I'm
only finding the patch itself with google.
Thanks,
Shaw
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
thing like this is needed, I'm not familiar
enough w/ the code to know if this is okay.
All explanations and comments are greatly appreciated.
Thanks,
Shaw
diff -u -uprN -X linux-2.6.16.11/Documentation/dontdiff linux-2.6.16.11/drivers/net/e1000/e1000.h linux-2.6.16.11.e1000_patch/drivers/net/e
e1000_down. It's against 2.6.16.9.
Thanks,
Shaw
diff -u -uprN -X linux-2.6.16.9/Documentation/dontdiff linux-2.6.16.9/drivers/net/e1000/e1000_main.c linux-2.6.16.9-patch/drivers/net/e1000/e1000_main.c
--- linux-2.6.16.9/drivers/net/e1000/e1000_main.c 2006-04-18 23:10:14.0 -0700
+++ l
n because it will see netif_running() ==
> 0.
I'll bite! Here's a patch to add a call to flush_scheduled_work() in
e1000_down. It's against 2.6.16.9.
Shaw
diff -u -uprN -X linux-2.6.16.9/Documentation/dontdiff linux-2.6.16.9/drivers/net/e1000/e1000_main.c linux-2.6.16.9-p
12 matches
Mail list logo
