Hello, I have this Wifi USB Adapter from Digitus with a realtek chip: Bus 002 Device 006: ID 0bda:8172 Realtek Semiconductor Corp. RTL8191S WLAN Adapter It's basically working on my Ubuntu box with a custom kernel 3.2.5. However, every few minutes (I'd say every 2-5 minutes), the connection speed drops to 0kb/s. So basically, I am still connected to the access point, but there is no data going through the network (no ping, no web page loading, etc). Several seconds later (usually about 10-30 seconds), everything is back to normal. I'm not sure if it's related to the problem, but there are several messages like this in dmesg: [38017.423303] r8712u: [r8712_got_addbareq_event_callback] mac = 7c:4f:b5:xx:xx:xx, seq = 35744, tid = 0 [39099.504553] r8712u: [r8712_got_addbareq_event_callback] mac = 7c:4f:b5:xx:xx:xx, seq = 32, tid = 0 [42088.211260] r8712u: [r8712_got_addbareq_event_callback] mac = 7c:4f:b5:xx:xx:xx, seq = 46944, tid = 0 [43687.872683] r8712u: [r8712_got_addbareq_event_callback] mac = 7c:4f:b5:xx:xx:xx, seq = 43328, tid = 0 [45528.835405] r8712u: [r8712_got_addbareq_event_callback] mac = 7c:4f:b5:xx:xx:xx, seq = 16, tid = 4 However, the connection drops a lot more often than these messages are being displayed. Also, I'm not sure if this is true, but If i let terminal in the background that constantly pings my router, the connection seems to be more stable. I'm not sure about this yet, but will keep an eye on it. => Could this be related to some kind of powermanagement? i.e. the Wifi-chip is sent to some kind of sleep mode? Also: I could not find a newer firmware for this driver on the net. So right now I'm using the default firmware shipped with Ubungu 11.10. Please tell me if you need more information. I have no problem doing some C programming if it's required for debugging. But I am not experienced in driver or kernel development.
Not sure if Larry is interested in this or not -- let's ask... :-)
Okay, I guess I was wrong on the Ping-thing. It just blocked again while the ping was running. I also tried to compile the driver from the realtek website directly (I only found a driver for RTL8191SU there, while lsusb says RTL8191S. But I think that's the same then...) However, that driver doesn't even compile and throws a lot of errors like event_tasklet and xmit_tasklet having an uncomplete type and a failing include to "linux/smp_lock.h". Maybe not compatible with recent Linux kernels(?).
The driver on the Realtek Web site is not compatible with later kernels. If you want to try it, please post the version you downloaded, and the kernel you wish to use. I'll post the corresponding patch. The vendor driver uses features removed from the kernel, and most do not work with 64-bit systems. I have two different units with RTL8191SU chips, and neither shows this problem.
Hey, 1: Can you confirm that my adapter is actually the same as the SU version? 2: Version 2.6.6.0.20110401 with kernel 3.2.5 3: Well, I would only try the realtek driver if it would help locating the probelm. Do you think it's even worth debugging this? If not, i will just give it back to the vendor as it doesn't work as advertised and go back to my old ralink adaptor (and write a bug report for that one as it only works correctly with patched vendor drivers and is buggy in the kernel, too).
Created attachment 72471 [details] Patch to allow vendor driver v2.6.6.0.20110401 to compile and run Whether you want to use this patch is up to you. Your USB ID matches one the two different units that I have. As far as I know, all the chips with the same ID are the same. Testing with the vendor driver would have some value for me. As I cannot duplicate your result, it would be useful to know if this is something that Realtek fixed. The kernel driver (kernel V3.2 and later) is based on the 8/31/10 version. I have not looked into what is different between 8/31/10 and 4/1/11 versions.
One other question - what is the Digitus model number?
It's this little guy: http://www.digitus.info/en/products/network/300mbps-wireless-lan-series/wireless-300n-usb-adapter-dn-7053-2/ I will try the realtek driver tomorrow and report back. I will also do some tests on Windows to make sure it's not a hardware issue.
Oh well, that diddn't quite work out :/ When I loaded the driver and looked at network manager, it found several networks, but all of them were displayed with a very low signal strength (0%?). When trying to connect, the driver crashed and the kernel hung up (had to SysRq to get out). Managed to get a dmesg right before the complete hangup.
Created attachment 72477 [details] dmesg photo File was cleared during reboot. Photograph only :/
I think this was with the vendor driver. Is that correct? If so, I'm not that interested in fixing it. This morning, I found a bug that would affect kernel 3.2.5. A work-around will be posted.
Created attachment 72478 [details] Patch to fix locking problem when using wicd The problem does not appear to affect NetworkManager, but it fails with wicd. This patch is needed for 3.2.0 and later.
Created attachment 72479 [details] Patch to fix formware load when using wicd This patch also fixes a problem that fails regularly with wicd and only infrequently with NetworkManager. It applies to kernel 3.2.6 and 3.3-rc4 and later.
Hey, The Crash only exists in the vendor driver. So don't mind fixing it, I'm not interested in using that driver anyway (it was just for testing). I will update to kernel version 3.2.7 now and apply your patches and see what happens.
The new kernel with both of your patches is now running for approx. two hour and I had no problem for now (at least I couldn't see one). I hope that fixed it :) I'm now on 3.2.7 with both of your patches. I had to include the shorter one by myself as it conflicted with your other file (both do something at around the same line in the source). What also changed, is that I'm now getting a _lot_ more of the message from my first post in dmesg (sometimes 5 per minute, sometimes none for 5 minutes but a lot more on average). I will write again if the problem comes back. btw: I noticed that this driver is in staging for a long time already. Will this ever be moved to stable? Or will there be a replacement some day? Or will it just reside in staging until the devices are outdated enough so nobody uses them any more? Just curious...
The driver is generally as stable as many drivers in the drivers/net/wireless tree, but is still in staging because it does not use mac80211. Doing that rewrite is on my TODO list, but with low priority. Is it OK if I add a Tested-by line for you in the official patch?
Sure. Tested-by: Adrian Batzill <agib@gmx.de>
A patch referencing this bug report has been merged in Linux v3.4-rc1: commit 9f4bc8cf3fe750ed093856a5f5d41c11cc12ad22 Author: Larry Finger <Larry.Finger@lwfinger.net> Date: Sat Feb 25 18:10:20 2012 -0600 staging: r8712u: Fix regression introduced by commit a5ee652