rt2x00.serialmonkey.com

Hmm, I have to admit I did not try those since they seem to require a non-standard configuration method for WPA connections.

I hope I have some time to try it anway soon, but if not, it could take up to three weeks. Sorry!

-Malte

With rt2x00 CVS as existing immediately prior to your commit of 22nd September, and with a stock 2.6.22.6 kernel, together with patches of rt2x00mac_tx_rts_cts() in rt2x00mac.c, IEEE80211_TXCTL_LONG_RETRY_LIMIT in rt2x00_compat.h and IEEE80211_HW_WEP_INCLUDE_IV in rt73usb.c, and changing REGISTER_TIMEOUT to 500 in rt2x00usb.h, I still get the same error with my rt73 stick in the circumstances described earlier in this thread. Apart from that the rt2x00 works fine (no problems with association and, before it hangs on vendor_request_errors, reasonable throughput). This is with it plugged into a USB2 port.

The rt73 stick works correctly with the legacy driver.

I have also now tried with your (IvD's) git kernel tree, as last committed by you just over an hour ago, and I get the same problem, although it takes longer to establish itself. When it does, the reported error is now writing to the PHY_CSR4 register, rather than reading from the PHY_CSR3 register, and the offset is different, and the error number varies (mainly -110, but also -71 and -19). Here is a typical log extract:

Sep 25 00:54:26 laptop kernel: phy4 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x3090 with error -110.
Sep 25 00:54:27 laptop kernel: phy4 -> rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x3090 with error -110.
Sep 25 00:54:27 laptop kernel: phy4 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x3090 with error -71.
Sep 25 00:54:27 laptop kernel: phy4 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x3090 with error -19.
Sep 25 00:54:27 laptop last message repeated 3 times
Sep 25 00:54:27 laptop kernel: phy4 -> rt73usb_rf_write: Error - PHY_CSR4 register busy. Write failed.
Sep 25 00:54:27 laptop kernel: phy4 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x3090 with error -19.
Sep 25 00:54:27 laptop last message repeated 4 times
Sep 25 00:54:27 laptop kernel: phy4 -> rt73usb_rf_write: Error - PHY_CSR4 register busy. Write failed.
Sep 25 00:54:27 laptop kernel: phy4 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x3090 with error -19.
Sep 25 00:54:27 laptop last message repeated 4 times
Sep 25 00:54:27 laptop kernel: phy4 -> rt73usb_rf_write: Error - PHY_CSR4 register busy. Write failed.
Sep 25 00:54:27 laptop kernel: phy4 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x3090 with error -19.
Sep 25 00:54:27 laptop last message repeated 4 times

However, if I don't provoke these errors by logging into my laptop with ssh, in general use I now get quite an unstable connection with disassociation after a minute or so of use, so there is also something else amiss with the latest git version.

Chris

On examining this further, I have had your kernel running all morning on my laptop and the disassociation is not very problematic after all. The association is dropped at 30 minutes intervals and then it reassociates itself again without any dramas - probably this is something done by the AP rather than rt2x00. Apart from the vendor_request_error lock-ups when I try to ssh into my laptop, it is working quite well.

I am going to go back to a stable kernel + legacy driver again now but if there is any further information you need about the vendor_request_error lock-ups, let me know.

Chris

I have tested today's git kernel and I no longer get these errors. I have to apply Adam Baker's patch to get 802.11g speeds, but apart from that it seems to work well with my rt73 stick.

Chris

Hello,

I have also tested latest git to see whether the issue still crops up - it does not (at least for now). Also, the driver feels much snappier. I'll be sure to let you know of further problems, but for now, I'd recommend marking this as no longer reproducible/probably fixed in your issues list. Woohoo!