[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