rtl8192du
rtl8192du copied to clipboard
lwfinger
Strange USB Behavior
I'm noticing that, within the past week, when I've installed this driver on a system I get very strange behavior. Prior to about a week ago, I had no issues with the driver on Xubuntu 13.10. I then did a reinstallation of Xubuntu 13.10 and grabbed the latest version of this code. When I attempted to use the wireless card (by connecting to my 5GHz network), it doesn't actually do anything in the way of prompting about security and, instead, seems to lock-up my system. From that point moving forward, many things on the system do not respond any longer and I also cannot actually shut the system down. If I try, it gets to the point where it tries to kill all processes and hangs eternally.
I noticed that one difference was that I had upgraded to kernel 3.11.0.17. I've tried going back to the originaly 3.11.0.12 kernel included in Ubuntu 13.10 (and recompiling for that level) and I still see the same behavior.
I swapped over to Arch to see what my results were there and I had the exactly same issues (lock-up and everything). On Arch, I used their current kernel (which is in the 3.13 line) along with a LTS kernel (3.10 line). Same results each time.
My assumption is that something within the past month has changed stuff in this driver. Is anyone else seeing this?
Do you know about "git bisect"? It was designed to handle exactly this case. You should read how to use it to tell you what commit caused the problem.
One question before you start the bisection? Have you installed the firmware? You can do that with 'sudo make install'.
Yeah. The procedure that I follow is pretty simple:
(as regular user) make sudo make install sudo modprobe 8192du
I don't know that much about git but I'll see what I can find. I'm familiar with tracking bugs down in software I just suck at code management :).
So I spent some time using the git bisect feature to find the offending code. Based on what I've found, this is the offending commit:
commit eb36bf5adb44978d47f48087ada2704f7eb8bbf1 Author: Larry Finger [email protected] Date: Wed Feb 26 22:47:48 2014 -0600
I looked over your changes and it isn't apparent to me why there's a problem at the moment. However, I've duplicated my results a number of times over (3 now). I was able to confirm that I didn't have this problem a number of times on each one of the tests. I am only able to recreate the problem if I'm running the very latest code.
(Perhaps to my own demise) I'm going to continue to look it over and see if I can figure out what the problem is. Thanks for pointing me to that as I now know how to get a working driver when I'm tired of putting up with the problem. :)
I spent more time today working on this and I was able to stop the problems by just renaming the firmware out of the way and then using the updated driver. So far, the device seems to work without a problem and I'm able to connect/disconnect without hanging NetworkManager and causing other system problems.
hi haljhon.i have same problem with you.can you explain how you solve it.thanks
The way that I eliminated the problem for myself with the latest code was by renaming the firmware file that was placed by the code. If it can't load the firmware to the device it looks like everything is normal.
I'm not really sure how to answer this question since I don't really know what I'm doing... I've added some logging statements to the driver in an attempt to figure out what happens. From the best I can tell, we just fail out of the firmware load process and the device works.
My specific device is a TEW-664UB USB dongle.
If you unplug it and plug it back in, does it still work?
Please post the dmesg output from the point at which the device is plugged in. It is possible that your device does not need external firmware, but that is hard to believe.
Here's my dmesg output:
[261368.232457] usb 2-1.2: new high-speed USB device number 6 using ehci-pci [261368.327806] usb 2-1.2: New USB device found, idVendor=20f4, idProduct=664b [261368.327814] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [261368.327819] usb 2-1.2: Product: 802.11n NIC [261368.327822] usb 2-1.2: Manufacturer: Realtek [261368.327826] usb 2-1.2: SerialNumber: (hidden) [261368.328854] r8192du: EEPROM type is E-FUSE, E-CUT chip [261368.762314] r8192du: MacPhyMode: SINGLEMAC_SINGLEPHY [261368.797157] r8192du: MacPhyMode: SINGLEMAC_SINGLEPHY [261371.009286] pdmpriv->TxPowerTrackControl = 1 [261371.052683] IPv6: ADDRCONF(NETDEV_UP): wlan2: link is not ready [261371.053212] IPv6: ADDRCONF(NETDEV_UP): wlan2: link is not ready [261371.076743] IPv6: ADDRCONF(NETDEV_UP): wlan2: link is not ready [261371.112720] IPv6: ADDRCONF(NETDEV_UP): wlan2: link is not ready [261371.135677] IPv6: ADDRCONF(NETDEV_UP): wlan2: link is not ready [261376.250854] IPv6: ADDRCONF(NETDEV_CHANGE): wlan2: link becomes ready
Yes, I can unplug and plug the devices multiple times without a problem.
For troubleshooting, I added this code to the get_fw_from_file() function:
if (request_firmware(&fw, fw_name, device)) {
pr_err("request_firmware returned true, exiting process...\n");
return false;
}
It looks like this is what is happening based on the output of dmesg now:
[261857.903316] usbcore: deregistering interface driver rtl8192du [261871.701504] r8192du: EEPROM type is E-FUSE, E-CUT chip [261872.134212] r8192du: MacPhyMode: SINGLEMAC_SINGLEPHY [261872.135353] usbcore: registered new interface driver rtl8192du [261872.157933] r8192du: MacPhyMode: SINGLEMAC_SINGLEPHY [261872.288777] request_firmware returned true, exiting process... <-- [261874.308293] pdmpriv->TxPowerTrackControl = 1
If you do not have the firmware file available, then request_firmware() will return a non-zero value. The code is doing what it should, except that it should print an error message where you added your printout. I will add that now.
I just tested, and my device also works without loading the external firmware. It must have some primitive stuff built in, and it seems that the external firmware is killing the TEW-664UB. I may have to buy one of those for testing.
I just found a logic error in the external firmware loading. For devices with a single MAC like you have, the firmware does come from the internal EE-PROM. With the latest commit from today, you should not have to rename the firmware file or modify the Makefile.