The module rt2500.ko that is built using the net-wireless/rt2500-1.1.0_beta2-r2 ebuild is causing tx errors on ra0. I have built out the daily CVS from 20050802 and this issue has been fixed in the CVS build (possibly in the beta3 release too). There aren't very many errors (probably around 1%) but you definitely notice network latency. Below is some detail from netstat and ifconfig (this is with minimal traffic just to report the error) trogdor ~ # ifconfig ra0 ra0 Link encap:Ethernet HWaddr 00:12:17:71:E4:17 inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::212:17ff:fe71:e417/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:836 errors:0 dropped:0 overruns:0 frame:0 TX packets:914 errors:3 dropped:3 overruns:0 carrier:0 collisions:28 txqueuelen:1000 RX bytes:348089 (339.9 Kb) TX bytes:174722 (170.6 Kb) Interrupt:17 trogdor ~ # netstat -s Ip: 67975 total packets received 0 forwarded 0 incoming packets discarded 64135 incoming packets delivered 37263 requests sent out 113 dropped because of missing route Icmp: 49 ICMP messages received 0 input ICMP message failed. ICMP input histogram: destination unreachable: 1 echo replies: 48 1 ICMP messages sent 0 ICMP messages failed ICMP output histogram: destination unreachable: 1 Tcp: 984 active connections openings 0 passive connection openings 0 failed connection attempts 6 connection resets received 5 connections established 63633 segments received 36847 segments send out 12 segments retransmited 0 bad segments received. 37 resets sent Udp: 450 packets received 0 packets to unknown port received. 0 packet receive errors 480 packets sent TcpExt: ArpFilter: 0 156 TCP sockets finished time wait in fast timer 571 delayed acks sent Quick ack mode was activated 38 times 319 packets directly queued to recvmsg prequeue. 7287 packets directly received from backlog 363202 packets directly received from prequeue 55880 packets header predicted 256 packets header predicted and directly queued to user TCPPureAcks: 1334 TCPHPAcks: 1786 TCPRenoRecovery: 0 TCPSackRecovery: 0 TCPSACKReneging: 0 TCPFACKReorder: 0 TCPSACKReorder: 0 TCPRenoReorder: 0 TCPTSReorder: 0 TCPFullUndo: 0 TCPPartialUndo: 0 TCPDSACKUndo: 0 TCPLossUndo: 4 TCPLoss: 0 TCPLostRetransmit: 0 TCPRenoFailures: 0 TCPSackFailures: 0 TCPLossFailures: 0 TCPFastRetrans: 0 TCPForwardRetrans: 0 TCPSlowStartRetrans: 0 TCPTimeouts: 5 TCPRenoRecoveryFail: 0 TCPSackRecoveryFail: 0 TCPSchedulerFailed: 0 TCPRcvCollapsed: 0 TCPDSACKOldSent: 38 TCPDSACKOfoSent: 0 TCPDSACKRecv: 1 TCPDSACKOfoRecv: 0 TCPAbortOnSyn: 0 TCPAbortOnData: 4 TCPAbortOnClose: 4 TCPAbortOnMemory: 0 TCPAbortOnTimeout: 1 TCPAbortOnLinger: 0 TCPAbortFailed: 0 TCPMemoryPressures: 0 Reproducible: Always Steps to Reproduce: 1. emerge rt2500 2. modprobe rt2500 3. surf! Actual Results: ifconfig reports tx errors, network latency Expected Results: no tx errors FYI to anyone with the same problem, read the instructions found at http://gentoo-wiki.com/HARDWARE_rt2500_on_AMD64 to get and install the cvs daily build
This is in the summary anyway but I forgot to add that this is with a Linksys WMP54g v4, lspci info is as follows: 0000:00:0c.0 Network controller: RaLink Ralink RT2500 802.11 Cardbus Reference Card (rev 01)
Another FYI that I wanted to add just in case someone else is having the same issue. I was unable to use the standard /etc/init.d/net.ra0 to start the interface and am unable to gather any reason as to why the script failed (a --verbose flag would be nice or, perhaps there is a log I don't know of (dmesg and /var/log/messages said nothing)). To work around the issue I added the following to /etc/conf.d/net preup() { ifconfig ra0 down iwconfig ra0 essid MY_ESSID return 0 } # preup For some reason the cvs module I'm using won't allow you to set any attributes to the wireless card via iwconfig if the interface has been set as up via ifconfig, also the /etc/conf.d/wireless script would fail unless I set up an essid prior to the wireless settings being set to the card from /etc/conf.d/wireless... weird. I hope this helps.
Can you please try beta3? It would be nice if you could provide a patch for beta3, so that I can actually fix this bug.
I have tested and received tx errors and latency with the beta3 driver. I also recieved 1 tx error with the cvs build from 2005-08-02 after 3 days of constant mythtv traffic so the code in CVS is still not working perfectly with this card. On the patch issue I am not that familiar with kernel development... or C either so the best I could do is just a diff between the CVS and beta2 which is a sloppy way to fix this IMHO. I am well aware that this driver is in a very experimental stage and anyone who uses this driver should keep that in mind that errors are going to occour. When I find a CVS build that does not give me a tx error within a week of traffic I will repost a date. Let me know if there is anything else I can do.
Reporting upstream is a good idea for unstable drivers. Just go to the rt2500 mailing list and write a mail about your issue. They are usually happy to receive some feedback.
