rt73usb seems to fail

Exactly same problem & results for me, with Belkin's F5D7050B device. Usb id is 050d:705a.
It worked fine with the legacy rt73 driver from previous kernels.
But not with rt73usb that came with the latest kernel update (2.6.20-11-generic).

lsmod reports the following drivers:
rt2500usb 30592 0
rt73usb 33536 0
rt2x00lib 11904 2 rt2500usb,rt73usb
usbcore 134280 5 rt2500usb,rt73usb,ehci_hcd,uhci_hcd

iwconfig reports:
lo no wireless extensions.
eth0 no wireless extensions.
wmaster0 IEEE 802.11g Frequency:2.412 GHz
          RTS thr:off Fragment thr=2346 B
wlan0 IEEE 802.11g ESSID:""
          Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated
          RTS thr:off Fragment thr=2346 B
          Encryption key:off
          Link Quality:0 Signal level:0 Noise level:0
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

Thank you for you bug report.

Is this issue still in feisty?

I'm sorry, but at this time I can't check it because I don't own the device.

Well, I have the device in my hands at this time. It doesn't work for me in Feisty. When I plugged into de USB port, the system get very slow. I was researching about it and the problem comes when the device is tried to be gotten up. It's to say, the command "sudo ifconfig rausb0" takes 99% of processor. When I unplug the device I get a: " [ 445.868.000] BUG: soft lockup detected on CPU#0 ".

I compiled the latest CVS from rt2x00.serialmonkey.com and i didn't have the problem that I mentioned before. Mode monitor and mode managed working properly. However the injection failed. I readed the serialmonkey forum and it seems that the latest CVS have problems with injection. Therefore, i downloaded older CVS(december CVS, it's explained in the forum), I compiled it and it works perfectly. Managed is working without problems and I can capture and inject using monitor mode. Moreover, the huge %CPU usage is commented at the forum.

Please, link here these forums post and give us:

 - dmesg output
 - lspci -vv output
 - lspci -vvn output

Thank you very much.

Hi,

I'm still having the same problem in feisty.

Before plugging the usb device, I manually do "modprobe rt73usb" otherwise the system becomes unusable just like in Jaco's comment.

After the device is plugged the rt2570 driver gets automatically loaded and I'm thinking that it should not happen.
Belkin's F5D7050B device, has usb id 050d:705a and it works only with rt73.

Attached is the requested output.

The only way to make it work is to blacklist rt73usb & rt2570 and manually build the rt73 driver from serialmonkey site.
Then it works with manual configuration (not roaming mode) in Network manager.

Attached the lspci -vvn output correctly

Thread where a guy recommend to use an older CVS snapshot (due to injection issues): http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=3054
Thread about "High load average with rt73": http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=3071
Thread where it's explained how to build a "31-dec CVS snapshot", that works great, at least for me.

I guess that the attachments will be more useful than the threads xD.

Thanks for your work,
Jacob.

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug does not meet the criteria for a stable release update and is being marked as Won't Fix for this particular version of the kernel. You can learn more about the stable release update process at https://wiki.ubuntu.com/StableReleaseUpdates .
However, the issue that you reported is one that should be possible to test with the live environment of the Desktop CD of the development release - Gutsy Gibbon. It would help us greatly if you could test with it so we can work on getting it fixed in the actively developed kernel. You can find out more about the development release at http://www.ubuntu.com/testing/ .
If you do decide to test with the development release of Ubuntu please comment on this bug report and include at least the minimal information requested at http://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help.