[Prism54-devel] [Bug 56] NETDEV WATCHDOG: eth2: transmit timed out
bugzilla-daemon at mcgrof.com
bugzilla-daemon at mcgrof.com
Thu Nov 11 04:05:30 UTC 2004
http://prism54.org/cgi-bin/bugzilla/show_bug.cgi?id=56
------- Additional Comments From hwertz at avalon.net 2004-11-11 04:05 -------
Word, guys.. I've had the same problems with an Inspiron 5000e (which does
have the 440BX/ZX chipset.) However, I have *solved* my problems. I don't know
if I need all these steps or not, but there's not a lot so I'll just list all I
did..
1) I built the prism54-1.2 driver off the site, it seems to work better
than the one in 2.6.8.1 (which is supposedly also version 1.2 8-).
2) I had found that if I generate any broadcast traffic it seems to kick
the card back on when it does hang, so I don't get those 20 second dead times
under load. Also for me when the card went down *entirely* it appears it was
during these 20 second dead times that the card just didn't come back up. I
just did arping -q -b -I eth0 1.2.3.4, since that shouldn't really generate
significant traffic (pinging the broadcast address works too but is more chatty.)
3) Also, I found the (much shorter) hangs I was getting virtually stopped
when I did a iwconfig eth0 retry lifetime 100ms. Conversely, they get much
worse if I either increase the retry lifetime or any of the retry limits. This
suggests pretty strongly to me it's a firmware bug being hit like you guys say.
This doesn't affect it hanging or not, but iwpriv eth0 s_frameburst 1300
also seems to kick the throughput up nicely for me 8-). I do have a shell
script that monitors the signal strength and drops or raises bitrate
accordingly, since the firmware likes to drop it off unnecessarily.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the Prism54-devel
mailing list