Greetings,
I've recently bought myself an USB device, based on the RTL8192CU
chipset, running under 64bit kernel 3.15.0-rc6 at the moment.
Firmware is installed where it should be.
Debuglog of the kernel is here: http://pastebin.com/Eh6pBbra
The problem is this: I am running the device in managed mode and let it
connect to my AP.
First all works as intended, but after a short while the device always
stops working altogether.
No output in the kernel log, not even about deauthenticating but it just
stops working at all, no traffic anymore, I've got to unplug it or
unload and reload the driver and then the same starts all over again.
This seems to be a long lasting regression
(https://www.google.com/#q=linux+rtl8192cu+disconnects+linux+) and
there's also a repository on Github containing the original Realtek
driver ported up to kernel version 3.11
(https://github.com/pvaret/rtl8192cu-fixes), because the kernel driver
seemed to be not working flawlessly until then.
So my question is: what else could/should I do to get a stable, working
wifi connection with that device on my linux box that lasts more than
just a few minutes?
Thanks in advance.
On 05/23/2014 03:43 AM, Marc St?rmer wrote:
> Greetings,
>
> I've recently bought myself an USB device, based on the RTL8192CU chipset,
> running under 64bit kernel 3.15.0-rc6 at the moment.
>
> Firmware is installed where it should be.
>
> Debuglog of the kernel is here: http://pastebin.com/Eh6pBbra
>
> The problem is this: I am running the device in managed mode and let it connect
> to my AP.
>
> First all works as intended, but after a short while the device always stops
> working altogether.
>
> No output in the kernel log, not even about deauthenticating but it just stops
> working at all, no traffic anymore, I've got to unplug it or unload and reload
> the driver and then the same starts all over again.
>
> This seems to be a long lasting regression
> (https://www.google.com/#q=linux+rtl8192cu+disconnects+linux+) and there's also
> a repository on Github containing the original Realtek driver ported up to
> kernel version 3.11 (https://github.com/pvaret/rtl8192cu-fixes), because the
> kernel driver seemed to be not working flawlessly until then.
>
> So my question is: what else could/should I do to get a stable, working wifi
> connection with that device on my linux box that lasts more than just a few
> minutes?
Looking at your kernel log, the first thing I see is
[ 295.926536] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[ 295.926578] usbcore: registered new interface driver rtl8192cu
[ 295.949364] usb 3-9: Direct firmware load failed with error -2
[ 295.949366] usb 3-9: Falling back to user helper
[ 295.955563] rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
You should try the newest firmware. If you have updated your code base recently,
then your distro apparently does not supply it. You should get the latest copy
of firmware with
git clone git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git
sudo cp linux-firmware/rtlwifi/rtl8192cufw_TMSC.bin /lib/firmware/rtlwifi/.
Yes, there are a number of users that are unhappy with this driver. Realtek
provided it, and then abandoned it. I have no knowledge of its internals and the
only documentation I have is what is in the driver code.
In the past, I have tried to solve problems that users have posted, but all of
those efforts eventually have stalled because those users have failed to answer
NEEDINFO queries, or the equivalent, in a timely fashion. I either have
forgotten what we were trying to do, or I have had to move onto a more pressing
problem. At the moment, I do have some time.
Load the driver with 'modprobe -v rtl8192cu debug=3' and post the from when the
driver is loaded until it fails.
Larry
Am 23.05.2014 16:51, schrieb Larry Finger:
> Looking at your kernel log, the first thing I see is
>
> [ 295.926536] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
> [ 295.926578] usbcore: registered new interface driver rtl8192cu
> [ 295.949364] usb 3-9: Direct firmware load failed with error -2
> [ 295.949366] usb 3-9: Falling back to user helper
> [ 295.955563] rtlwifi: Loading alternative firmware
> rtlwifi/rtl8192cufw.bin
>
> You should try the newest firmware. If you have updated your code base
> recently, then your distro apparently does not supply it. You should get
> the latest copy of firmware with
Thanks for the response and information, I just did that like told.
I'm on Gentoo stable here and used the linux-firmware-ebuild out of
portage, which still had not that BLOB in it. So I just copied it over.
Kernel is:
Linux dreadnought 3.14.4 #6 SMP Fri May 23 17:00:34 CEST 2014 x86_64
Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz GenuineIntel GNU/Linux
/proc/config.gz is: http://pastebin.com/CZ7VmuWt
> Load the driver with 'modprobe -v rtl8192cu debug=3' and post the from
> when the driver is loaded until it fails.
modprobe -v rtl8192cu debug=3
insmod
/lib/modules/3.14.4/kernel/drivers/net/wireless/rtlwifi/rtl8192c/rtl8192c-common.ko
insmod /lib/modules/3.14.4/kernel/drivers/net/wireless/rtlwifi/rtlwifi.ko
insmod /lib/modules/3.14.4/kernel/drivers/net/wireless/rtlwifi/rtl_usb.ko
insmod
/lib/modules/3.14.4/kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko
debug=3
Logfile: http://pastebin.com/1RsGKsZi
After it got stuck I unloaded the driver module and fired up the other
WLAN then, I guess that's where those URB errors originate from.
IMHO the typical loop it has been stuck in goes like this, all after
Line 2107 happened because I unloaded the module:
May 23 17:21:43 dreadnought kernel: [ 1164.047574]
rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=08
May 23 17:21:44 dreadnought kernel: [ 1165.043107]
rtl8192c_common:rtl92c_dm_write_dig():<0-0> dig values 0x1e 0x1e 0x0 0xc
0x3e 0x1e 0x0 0x1e
May 23 17:21:44 dreadnought kernel: [ 1165.284384]
rtl8192cu:_rtl8192cu_mq_to_descq():<600-1> BE queue, set qsel = 0x0
May 23 17:21:45 dreadnought kernel: [ 1165.576186]
rtl8192cu:_rtl8192cu_mq_to_descq():<500-1> BE queue, set qsel = 0x0
May 23 17:21:45 dreadnought kernel: [ 1166.286179]
rtl8192cu:_rtl8192cu_mq_to_descq():<300-1> BE queue, set qsel = 0x0
May 23 17:21:46 dreadnought kernel: [ 1166.599659]
rtl8192cu:_rtl8192cu_mq_to_descq():<500-1> BE queue, set qsel = 0x0
May 23 17:21:46 dreadnought kernel: [ 1167.045766]
rtl8192c_common:rtl92c_dm_write_dig():<0-0> dig values 0x1e 0x1e 0x0 0xc
0x3e 0x1e 0x0 0x1e
May 23 17:21:46 dreadnought kernel: [ 1167.287601]
rtl8192cu:_rtl8192cu_mq_to_descq():<300-1> BE queue, set qsel = 0x0
May 23 17:21:47 dreadnought kernel: [ 1167.622982]
rtl8192cu:_rtl8192cu_mq_to_descq():<500-1> BE queue, set qsel = 0x0
May 23 17:21:48 dreadnought kernel: [ 1169.036675]
rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=08
May 23 17:21:48 dreadnought kernel: [ 1169.048732]
rtl8192c_common:rtl92c_dm_write_dig():<0-0> dig values 0x1f 0x1f 0x0 0xc
0x3e 0x1e 0x0 0x1e
Thanks in advance and please give me a shoot if I can do anything else
to assist you in tracking down this nasty bug once and for all.
Greetings,
Marc