[Edimax Rt73 Drivers For Mac
Denna Repaci
From the looks of the first line shown, my system thinks that the USB adapter is being disconnected. I hadn't touched anything, but the connection was then lost, so I had to "ifdown" and "ifup" my wlan0.
If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.
Jeremy, I'm experiencing similar issue in 10.04 (and never seen in 9.10). The wireless device is a D-Link DWA-111. Removing and re-pluggin again this USB adapter, it no longer works, requiring a reboot (while in 9.10 I was able to remove and replug again and again).
7. Blacklisting the modules should have no effect, they are loaded by rt73usb anyway, however blacklisting them did alleviate the issue, even if it has not gone away
8. Could not use ndiswrapper as it conflicted with rt73usb and I had no clue how to remove the driver, blacklisting it did not work. I'd like to avoid ndiswrapper anyway.
This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu development release -live/current/ . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.
I have the same issue and (like others) I can recreate it at will. When I connect my USB wireless card it seem to work properly (just some seconds). After that I can see the error in every tty console:
I experienced this bug too. I have WiFi adapter Edimax 7318USg, and in 10.04 everything was fine, but now in 10.10 it's not. This happens very often and causes disconnection. It's very annoying. How can I help?
Hi, it's me again. Is there something going on with this bug? This is very annoying one. Usb modem hangs up couple times a day and I have to manually plug it in and plug it out, or execute "rmmod rt73usb && modprobe rt73usb" to restore the connection with the net. Why Unity is more important? What can I do to help.
I would like to add that symptoms are consistent with previous posters - network icon shows previous state, I'm unable to reconnect the adapter and as far as I know only rebooting helps. Will try removing and reattaching the adapter.
(2) I posted problems I had with one of these Ralink-based adapters years ago. I used that same adapter on an up-to-date Debian machine recently, and it has worked flawlessly under moderate use with Debian's separate "firmware-ralink" package. I have yet to try it again on Ubuntu.
(3) I understand that this driver is built in part from an open-source driver (part of the Linux kernel; should be mostly standard across Ubuntu and Debian), and in part from binary firmware images provided freely by Ralink. Maybe Ubuntu is using an old or incorrect version of the firmware? I will try to compare more sometime.
Also, Wolfgang Kufner, why did you immediately change the "affects" away from rt2x00 a few months back? Did you have a particular reason to believe that it's not a problem with the rt2x00 driver? Maybe you knew that this is a problem with the firmware, not with the open-source rt2x00 code?
Regarding my previous comment (1) above: the various reported messages are different. You can check the Linux kernel source for the meaning of "error -71" for instance. The ones mentioned so far by various observers on this thread are:
In summary of my last 2 comments: all people commenting on this report are not necessarily experiencing the same bug. They just all happen to be using Ralink-based USB devices which share a driver/firmware framework. The issues could be related but not necessarily.
1) I plug the USB Wifi (TP-Link TL-WN321G) and wait for it to disconnect. The nm-applet will still say it's connected so I'm using the Dropbox applet as an indicator. Syslog would then spit out the rt2x00usb_vendor_request error. It just happens without triggering it. Sometimes I'm doing something, sometimes I'm not, either way I'll have this error. Also, it's not time dependent, sometimes it'll go on for 5hours or more, sometimes for 5 mins.
Sorry for the delay on this. I've noted these problems on the rt2x00-users mailing list, where development for the supported Ralink drivers takes place. For help in debugging, they've suggested you try the official Ralink driver (a.k.a. "legacy driver") found here:
_support/support.php?sn=501
I believe you would need the "RT2501USB(RT73:RT2571W/RT2573/RT2671)" package. It's freely available, based on a simple usage agreement, but it is not really "maintained" (the in-kernel driver is the main support) and it is certainly a "use at your own risk" situation. It takes some work to properly extract, compile, and insert the driver into your system...if you want to proceed and have trouble, perhaps I can help.
I get similar messages (with "error -110") on Ubuntu 12.04 beta, with linux 3.2.0-18. Actually, I got this message since the alpha milestone, with all kernels I used. Never had this problem in previous releases. I have an RT73 device.
Shahar Or, thank you for reporting this and helping make Ubuntu better. This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from .
Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.
I cant reprodude,it happend at random several times. 1 per day. But its interesting that problems started after moving the adsl modem to another room lengthening the distance between modem and usb-wifi stick. (due to family reasons i cant put modem to its old central place )
darren, if you have a bug in Ubuntu, the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux
No need exists to comment here at this time. After reading the above documentation in it's entirety, if you have further questions, you are welcome to redirect them to the appropriate mailing list or forum via , or you may contact me directly.
I'm encountering exactly the same bug with rt73 drivers for onboard ralink wifi chip.. Ubuntu-based LInux Mint 17.. And 3.14--30 kernels.. What th eheck! This is still a bug?! 5 years and no solution?!
joshyg6, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu (not Linux Mint) by executing the following in a terminal while booted into the default Ubuntu kernel (not a mainline one) via:
ubuntu-bug linux
Reporting in from 16.04LTS, this bug still exists and Bug #1388416 appears to be describing the same bug and is marked Confirmed. I just signed up to post this so I'm still unfamiliar with the platform to find a way to link to it here.
I have the same issue, though it appeared to change behaviors after a recent restart-required update. Before the behavior was that after dropping, hot replugging resolved the issue 90% of the time; after the recent update hot replugging does nothing. At first I fell back to rebooting every time and then dug around for a bit and eventually found a more palatable work-around.
Issuing a restart command to the network-manager service often works, though you may need to restart your browser. Sometimes rfkill likes to soft-block the device especially after hot replugging so if it still isn't working try checking there.
I did notice the errors issued by ieee80211/rt2x00usb would be a quantity of 110s, then two or three 71s, and finally one or two 19s. This leads me to believe that something is hanging in the works or maybe the supplicant, that leads to the protocol error and eventual bailing out at the end. I'm not entirely qualified to guess, but I'd say it's possibly an issue in the kernel or systemd, but maybe network-manager. I doubt the module itself is to blame (since it worked in the past), but this is all my own conjecture and I have zero visibility deeper than the logs (I'd poke the guts but I moved from Arch to Ubuntu to avoid this kind of thing honestly). Incidentally back on 2.6.x kernel contemporary with the initial bug report up top, this problem existed on Arch so it perhaps is a chronic kernel issue.
As well, the fact that this bug has existed across releases, kernel versions, and the transition to systemd points more to the driver than anything else. I also tested wicd (currently using that now) and the problem persists, which means network-manager isn't the primary source of the bug. All of these can still be in play or making the problem worse but aren't the sole cause.
If I can get sight into the drivers (both rt73 and rt2x00USB), I might be able to pin down more specifics. For the actual bug fixers, I'd advise to check and see if the non-USB version of this chipset shares the problem to isolate the bug some more.
1) There were some places missing a lock (this change did not affect this bug, however).
2) The DPO driver performed the 32-bit register writes as two 16-bit single write commands instead of one four byte multi-write command. I suspected that this might lead to race conditions setting the registers (not atomic) which was causing the Wi-Fi chip to hang. I thought it possible that the Wi-Fi chip firmware might buffer the two 16-bit single writes and then perform a single 32-bit write to the register, thus making it atomic. I asked SparkLAN about this, but received no reply. Note that the DPO driver performs the 32-bit register reads as a single four byte multi-read, just like the main line kernel driver does.