Arch Linux

I encounter the same problem with a similar chipset Realtek Semiconductor Corp. RTL8191SU 802.11n WLAN Adapter.

"[ 7.153202] r8712u: module is from the staging directory, the quality is unknown, you have been warned."

It is expected that this module might have quality issues and varying success over different versions. Find out if you can get a more recent snapshot of the code from compat-wireless or try getting in touch with the actual driver developers.

I have the same device and I can confirm the issue.
One posible workaround is to install the linux-lts kernel and your device will work again.

If this helps anyhow, this is what I see in /var/log/messages.log
Jan 21 18:37:49 localhost kernel: [ 240.996701] wpa_supplicant D 00000000fffef134 0 1167 1 0x00000000
Jan 21 18:37:49 localhost kernel: [ 240.996704] ffff8802128c5c68 0000000000000086 ffffffff00000000 dead000000100100
Jan 21 18:37:49 localhost kernel: [ 240.996708] ffff880222b2a3a0 ffff8802128c5fd8 ffff8802128c5fd8 ffff8802128c5fd8
Jan 21 18:37:49 localhost kernel: [ 240.996710] ffff8802238d7200 ffff880222b2a3a0 ffffffff8117a210 dead000000100100
Jan 21 18:37:49 localhost kernel: [ 240.996712] Call Trace:
Jan 21 18:37:49 localhost kernel: [ 240.996719] [<ffffffff8117a210>] ? __pollwait+0xf0/0xf0
Jan 21 18:37:49 localhost kernel: [ 240.996722] [<ffffffff814258bf>] schedule+0x3f/0x60
Jan 21 18:37:49 localhost kernel: [ 240.996724] [<ffffffff81426fa4>] __mutex_lock_slowpath+0x154/0x370
Jan 21 18:37:49 localhost kernel: [ 240.996727] [<ffffffff813fa360>] ? iw_handler_get_private+0x60/0x60
Jan 21 18:37:49 localhost kernel: [ 240.996729] [<ffffffff814271d6>] mutex_lock+0x16/0x30
Jan 21 18:37:49 localhost kernel: [ 240.996732] [<ffffffff81371d15>] rtnl_lock+0x15/0x20
Jan 21 18:37:49 localhost kernel: [ 240.996734] [<ffffffff813f9475>] wext_ioctl_dispatch+0x65/0x240
Jan 21 18:37:49 localhost kernel: [ 240.996736] [<ffffffff813f9770>] ? call_commit_handler+0x40/0x40
Jan 21 18:37:49 localhost kernel: [ 240.996738] [<ffffffff813f9926>] wext_handle_ioctl+0x46/0x90
Jan 21 18:37:49 localhost kernel: [ 240.996741] [<ffffffff81365870>] dev_ioctl+0xe0/0x610
Jan 21 18:37:49 localhost kernel: [ 240.996743] [<ffffffff81128c6c>] ? tlb_flush_mmu+0x6c/0x90
Jan 21 18:37:49 localhost kernel: [ 240.996745] [<ffffffff8113018d>] ? unmap_region+0x10d/0x130
Jan 21 18:37:49 localhost kernel: [ 240.996748] [<ffffffff8134a5da>] sock_ioctl+0xfa/0x2c0
Jan 21 18:37:49 localhost kernel: [ 240.996750] [<ffffffff811793af>] do_vfs_ioctl+0x8f/0x500
Jan 21 18:37:49 localhost kernel: [ 240.996752] [<ffffffff811798b1>] sys_ioctl+0x91/0xa0
Jan 21 18:37:49 localhost kernel: [ 240.996755] [<ffffffff814290c2>] system_call_fastpath+0x16/0x1b

My RTL8191SU also stopped working with kernel 3.2.1 x86_64 (worked in 3.1.9, works in 3.0.17).

Similar dmesg messages:

[ 16.240983] r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
[ 16.890571] r8712u: 1 RCR=0x153f00e
[ 16.891427] r8712u: 2 RCR=0x553f00e
[ 17.172690] r8169 0000:03:00.0: eth0: link down
[ 17.440436] r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
[ 18.086805] r8712u: 1 RCR=0x153f00e
[ 18.087554] r8712u: 2 RCR=0x553f00e
[ 61.003359] r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
[ 239.934619] INFO: task xfce4-netload-p:766 blocked for more than 120 seconds.
[ 239.934623] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 239.934627] xfce4-netload-p D 00000000fffee866 0 766 729 0x00000000
[ 239.934633] ffff88007fec7cd8 0000000000000086 ffffffff00000000 ffffea000437fd80
[ 239.934639] ffff8801081bf200 ffff88007fec7fd8 ffff88007fec7fd8 ffff88007fec7fd8
[ 239.934644] ffff880110ca4e60 ffff8801081bf200 ffff88007ff193b8 ffff880104cf4d00
[ 239.934649] Call Trace:
[ 239.934660] [<ffffffff8110ec10>] ? __pagevec_free+0x60/0x100
[ 239.934667] [<ffffffff814258bf>] schedule+0x3f/0x60
[ 239.934671] [<ffffffff81426fa4>] __mutex_lock_slowpath+0x154/0x370
[ 239.934675] [<ffffffff814271d6>] mutex_lock+0x16/0x30
[ 239.934681] [<ffffffff81371d15>] rtnl_lock+0x15/0x20
[ 239.934685] [<ffffffff813c5db7>] devinet_ioctl+0xd7/0x730
[ 239.934689] [<ffffffff813c6f05>] inet_ioctl+0x75/0x90
[ 239.934694] [<ffffffff8134a260>] sock_do_ioctl+0x30/0x70
[ 239.934698] [<ffffffff8134a54d>] sock_ioctl+0x6d/0x2c0
[ 239.934706] [<ffffffff8116879b>] ? alloc_file+0x2b/0xd0
[ 239.934711] [<ffffffff811793af>] do_vfs_ioctl+0x8f/0x500
[ 239.934715] [<ffffffff8134bf64>] ? sock_alloc_file+0xa4/0x120
[ 239.934719] [<ffffffff811655b2>] ? fd_install+0x62/0x80
[ 239.934724] [<ffffffff811798b1>] sys_ioctl+0x91/0xa0
[ 239.934727] [<ffffffff8134d460>] ? sys_socket+0x40/0x70
[ 239.934733] [<ffffffff814290c2>] system_call_fastpath+0x16/0x1b

I've searched for bug reports upstream but didn't find any clearly relevant one. There was one related to udev 177 and firmware loading, but my wifi stick works with udev 177 and kernel 3.0.17, so I guess it's something else (different symptoms too).

I went to the #linux-wireless freenode IRC channel were I was told that staging drivers weren't supposed to be used except as reference, and that if I could fix the bug myself they'd accept a patch. Then I saw this page: http://wireless.kernel.org/en/users/Drivers/rtl819x which suggests a mailing list and people to contact for bug reports.

Edit: I also downloaded a couple compat-wireless archives (one from 21 jan., and also the 3.1.1 one), but none contained the r8712u driver.

My Realtek Semiconductor Corp. RTL8191SU 802.11n WLAN Adapter also stopped working after upgrading to linux 3.2.1. I didn't spot anything in dmesg. I could bring the interface up but not get through a WPA connection.

I can confirm this as well. Module r8712u does not work with linux 3.2.x. I wasn't able to find a solution so I probably have to install linux-lts.

Actually i was able to get my rtl8188SU usb dongle working with 3.2.x by using wpa_supplicant manualy

wpa_passphrase ESSID "password" >> /etc/wpa_supplicant.conf #also edited this file, commented all examples and changed ctrl_interface to /run

repluged wifi dongle and issued:

wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf
dhcpcd wlan0

Same problem here with my RTL8191S. Manual isn't working for me.

Here is Larry Finger's answer to the mail I sent him today:

I think the problem is that Arch Linux has switched to a new version of udev,
which is causing all sorts of problems for drivers that use synchronous loading
of firmware. Several drivers, including r8712u, need to be converted to an
asynchronous load mechanism. Until that happens, you should be able to work
around it by using a "modprobe -r/modprobe" sequence. Once the user-space code
is fully up and running, the synchronous loading will be OK.

Replying to stqn:
No, "modprobe -r/modprobe" sequence or downgrading to previous udev versions do not effect. Only, 3.1.9 kernels and previous versions works here. Didn't try Cookie Monster's method.

This r8712u usb wireless problem has plagued me for weeks on countless 3.2.x kernels, on several Gentoo systems, and with Arch, Mageia Cauldron, and a few other distros.
I'm using this: Bus 001 Device 002: ID 0bda:8172 Realtek Semiconductor Corp. RTL8191SU 802.11n WLAN Adapter (Rosewill RNX-N180UBE b/g/n 300mps wireless adapter)

The only work around I've found so far that works is this:

If I simply replace any linux-3.2.x/drivers/staging/rtl8712/ directory in the kernel source
with ANY 3.1 staging/rtl8712 version, and then recompile any 3.2.x kernel, all is
instantly well on reboot, with the normal rock solid 98% link/signal 3.1 levels of wifi performance. Wicd then scans and functions normally, and doesn't hang on system shutdown like to does with all 3.2 kernels, so far. This also worked on 3.3.0-rc1, which apparently has the same problems.

EDIT: Forgot to mention, I've tried two firmware versions in /lib/firmware/rtlwifi/, one is the 119.5 Kib (122,328) version (the default in Arch, Gentoo, Pclos, Mint), and the other is 129,304 (in Ububtu, Mageia Cauldron). Both versions work in all 3.1.x kernels, and even 2.6.38's, but not in any 3.2.x kernel using the 3.2.x r8712u driver in various distros. Both firmware versions do work in all 3.2.x and 3.3-rc1 kernels, but ONLY when I replace the 3.2 source r8712u with a 3.1 source r8712u.

My Gentoo testing udev is currently udev-171-r5, which seems odd since 177 is mentioned above. Gentoo testing is usually using the latest versions (haven't checked udev versions on other distros yet).

I temporarily just automatically replace this source directory in all new kernels I build, until I read somewhere it's fixed, or the 3.1 version no longer works. This little Rosewill usb "n" adapter gives such superior wireless performance that not being able to use it with 3.2 kernels is not an option. For my setup, nothing else even comes close, so using r8712u is a must. Hope it's fixed soon, but I'll keep using my work-around as long as I need to. We do know that Larry Finger and Dan carpenter are aware of this problem, as they have kindly responded to my emails. Larry even aquired the same Rosewill RNX-N180UBE I have, and mentioned he is installing Gentoo in a VM to work on the problem. Can't ask for more than that!

I have not yet tested with Gentoo in a VM; however, I do have a patch that changes r8712u from synchronous to asynchronous firmware loading. As the patch just started working about 30 minutes ago, I will not post it now, but I will as soon as it gets more testing.

Thanks much, Larry!
I'll be eagerly awaiting your patch. This is really good news. Hope I can understand what's involved. Is it turning out to be a udev conflict of some kind?

FWIW, I just tried the new 3.3.0-rc2, and still had to use the work-around with copying the 3.1 staging/rtlwifi/rtl8712/ to the 3.3.0-rc2 source before compiling the kernel modules.

Robert,

Could you please generate a diff file of the differences between the 3.1 and 3.3 kernels and mail it to me?

Thanks,

Larry

Larry,
I'd be happy to, and I'll try (haven't done this much), but I'm not sure exactly which items you mean.

The kernel .config text files, or the actual final module r8712u.ko object code files for both kernels? I opened an r88712u.ko in Kate, but I don't see how I can diff that stuff. Do I need a hex editor?

Sorry to be so limited, but if it's not a basic text file such as the .configs, I'll need some basic instructions on how to do this.

If I understand correctly, you want for example from say 3.1.9 with the default working /staging/rtlwifi/rtl8712u/, compared to a vanilla 3.3-rc2 /staging/rtlwifi/rtl8712u/ that doesn't work?

Yes. From your default directory, the command would be

diff -upwr <path_to_3.1.9_source>/drivers/staging/rtl8712/ <path_to_3.3-rc2_source>/drivers/staging/rtl8712/ > diff_31_33

The file diff_31_32 is the one I want.

This is the command I used- seemed to work.

diff -upwr /home/wrc/kern/linux-3.1.9/drivers/staging/rtl8712/ /home/wrc/kern/linux-3.3-rc2//drivers/staging/rtl8712/ > diff_31_33

and got the attached file in my home directory. I first extracted a fresh 3.3-rc2 source directory. I'll also email diff_31_33 directly to you if you wish.

Larry- Sorry. I just noticed a typo in my command: an extra "/" at linux-3.3-rc2//drivers/staging.

I did it again ,corrected, and the file is now 203.5 (208.429) instead of 203.7 (208,613), so I'm resending.

I've recompiled the module of the 3.1 kernel against 3.2.2-1-ARCH (x86_64) and it works :) If you have the same kernel and architecture and don't want to compile the module yourself, you can download it here:

http://dl.dropbox.com/u/4966186/r8712u.ko

I finally know what is going on. My attempt to run wireless in my VM failed when wicd kept bombing with D-bus timeouts. Even a known good wireless adapter failed. As a workaround, I copied the Gentoo-3.2.1-r2 source tree back to my host machine and built that kernel. In my first try, r8712u did not work. I then compared the Gentoo source with the current version from the wireless-testing git tree. Except for one inconsequential change merged later, they are identical.

I then built the Gentoo version without setting CONFIG_R8712_AP. That one worked. Thus the fix for most people in this thread is to change that configuration variable. Now that I know what causes the problem, I should be able to sort it out. When a patch is available, I will post it here.

For those that are getting messages like "INFO: task xfce4-netload-p:766 blocked for more than 120 seconds.", that is a separate issue. A patch is mostly working, and only needs a little more testing. The fix is to load the firmware asynchronously. Again, the patch will be posted here when ready.

I can confirm on Gentoo with a vanilla 3.3.0-rc2, not setting CONFIG_R8712_AP=y works, at least partially. Unfortunately, the link/signal level is never higher than 44%, but at least it now functions.

With 3.3.0-rc2 and 3.2.x kernels using the linux-3.1.9/drivers/staging/rtl8712/ directory (replacing the 3.2/3.3 versions), levels are immediately on reboot my normal 98-100%.

So it appears that while just not setting CONFIG_R8712_AP=y does enable a connection and scanning, there is still something different in the 3.2/3.3 versions that limits connection quality and speed.

EDIT: FWIW, a minute or so after I posted the above, wicd reported the connection fluctuating briefly up to 57% for a few seconds at a time, and a brief green bar instead of yellow.
With 3.1.x kernels, and even with CONFIG_R8712_AP=y set, this never happens- the connection is ALWAYS a constant rock solid 98-100%, with solid green bar.

The patch I just posted fixes the CONFIG_R8712_AP problem.

As to the performance problem, I made tests using the Gentoo-3.2.1-r2 kernel. Communication speeds were tested using netperf with a local server connected to the router by a 100 Mbs wired connection. Each sample was 10 sec.

With my D-Link device, I got the following results:

TCP_RX Test: 68.40 72.47 68.72 66.90 65.86 68.03 73.65 72.62 72.81 72.00
Results: max 73.65, min 65.86. Mean 70.15(2.70)

TCP_TX Test: 81.45 82.45 82.03 73.54 65.30 82.50 80.31 82.16 82.46 83.97
Results: max 83.97, min 65.30. Mean 79.62(5.49)

With the Rosewill RNX-N180UBE with a higher-gain antenna, I got

TCP_RX Test: 73.31 73.57 73.65 74.31 74.74 73.26 72.21 71.83 71.83 72.09
Results: max 74.74, min 71.83. Mean 73.08(0.99)

TCP_TX Test: 81.31 85.22 85.02 86.02 85.90 87.17 86.41 85.34 83.70 84.43
Results: max 87.17, min 81.31. Mean 85.05(1.56)

With the Rosewill device, and the 20100831 version of the vendor driver, I got

TCP_RX Test: 53.95 62.24 68.89 67.89 66.49 66.33 69.19 64.97 64.75 66.93
Results: max 69.19, min 53.95. Mean 65.16(4.22)

TCP_TX Test: 81.48 81.26 81.50 82.99 82.81 82.22 81.47 80.36 84.39 82.81
Results: max 84.39, min 80.36. Mean 82.13(1.09)

Given these results, the in-kernel version of the driver is doing as well as the vendor driver from which it was derived.

To complete the study, I tested using the driver that was the basis for the version in 3.1 and earlier kernels. Using the Rosewill device, I got the following:

TCP_RX Test: 67.48 68.77 66.64 66.42 64.56 66.23 68.95 67.98 69.85 70.56
Results: max 70.56, min 64.56. Mean 67.74(1.74)

TCP_TX Test: 82.00 83.83 85.41 85.49 82.80 83.82 83.96 84.92 83.65 82.75
Results: max 85.49, min 82.00. Mean 83.86(1.10)

Within the standard deviations, the results are the same.

Larry,
Thanks much for the patch! I'll give it a try. Can we use this patch on Gentoo and other distros on linux-3.2.3, just released, and 3.3.0-rc2 and future kernels (unless of course this patch goes into mainline kernels)?

BTW- When I disabled CONFIG_R8712_AP=y on 3.3.0-rc2, on system shutdown wicd hung for 40 seconds, and wouldn't stop, but then it continued on and hung solid at removing addresses.
Had to do a cold shutdown.

Also, just before I read your patch post, I had compiled 3.2.3 with not setting CONFIG_R8712_AP=y, and it performs exactly like 3.3.0-rc2. With the shutdown problem, I still would use the 3.1 r8712u version in 3.2/3.3 kernels, but I'm hoping your patch solves both r8712u connection and shutdown problems.

You can apply that patch to any kernel to which it will apply. That means 3.2 or later. I will be sending it to Greg Kroah-Hartmann for inclusion in the staging tree. As it is marked with a Cc for Stable, it will be backported to all stable kernels once it is in mainline. I would suspect that will happen with 3.4-rc1. We work a long way ahead.

I am also getting the 20110401 version of the vendor driver to compile and run. They have not yet fixed the driver for 64-bit systems, nor has it been modified for kernel changes. The 64-bit stuff was my main problem when the original driver was first entered in 2.6.37. Any advantageous changes will also be pushed into 3.4.

I have not seen the shutdown problem using any of my kernels. Perhaps it is due to my use of NetworkManager, not wicd.

My experiences so far:
3.2.2, 3.2.3, and 3.3.0-rc2 with CONFIG_R8712_AP=y not set work with wicd, but at much reduced signal/link levels, as mentioned above. However, Wicd seems to break the system shutdown routine, requiring hard shutdown and reboot.

3.2.3 manually patched (from Larry's patch) with the missing _r8712_init_sta_xmit_priv(&psta->sta_xmitpriv); line in /drivers/staging/rtl8712/rtl871x_sta_mgt.c boots and runs fine, but breaks wicd completely. System shutdown routine, requiring hard shutdown and reboot is still there, but even worse. Kde shutdown goes to black screen, and I had to enter a terminal and issue as root the halt command. star-shutdown daemon has problems kdm and xdm fail to stop. wicd hangs again, then proceeds and hard hangs at removing addresses, like before.


Back to my work-around. A fresh source of Linux3.2.3 with the 3.1.9 /staging/rtl8712u directory replacing the default 3.2.3 version. compiles, boots, and works perfectly. Wicd and connections work perfectly, with full 98-100% solid connection. Shutdown problems are also completely gone.

Bottom line: If I want to use wicd with a device requiring r8712u, no 3.2.x or 3.3.x kernel with it's own rtl8712 directory will not work normally yet. Not setting CONFIG_R8712_AP=y allows wicd with a crippled connection, but unacceptable shutdown problems, even if you can live with the slow unreliable connections. The only real thing that works for me so far is using 3.1.9 /staging/rtl8712u directory. Maybe wicd is the actual problem, but I'm not giving up that without a fight. Later today I'll try Larry-s patch on the linux-3.2.1-gentoo-r2 kernel, as he has. Maybe I'll get different results.

Robert,

Are you sure you got the patch right? The line to be added is the one with the +, i.e.

_init_listhead(&psta->asoc_list);

That line should be between the #ifdef CONFIG_R8712_AP and the #endif. The _r8712_init_sta_xmit_priv(&psta->sta_xmitpriv); line is not missing, and would cause the kinds of problems that you are seeing.

The safest way to do these is to 'emerge patch', cd to the source directory, and 'patch -p1 < <patch_file_name>.

Larry,
I'm pretty sure I did the manual patch correct exactly as you describe- I've done stuff like that many times before. Either I made a mistake in my post above when I c/p'd it, or I did indeed add the wrong line in the patch itself, but I remember carefully making sure it was _init_listhead(&psta->asoc_list);

I edited my 3.2.3 rtl871x_sta_mgt.c file to appear exactly as defined in your patch:

#ifdef CONFIG_R8712_AP
_init_listhead(&psta->asoc_list);
_init_listhead(&psta->auth_list);
#endif


Can't check now, as I removed the source and extracted a fresh 3.2.3 copy. I'll try it again on 3.2.1, just to be sure.

In any case, am I correct in that the patch only deals with the AP thing, and wouldn't address the wicd shutdown/low signal/connection problems?

Yes. If CONFIG_R8712_AP is not st, then the patch dos nothing.

OK- applied your patch to a fresh vanilla 3.2.1, it did exactly the same thing as when I manually edited it, and it compiled normally. On reboot, Kde comes up normally out of kdm.
Lsmod says module r8712u is loaded, but the usb wireless adapter is not flashing, and the Wicd tray icon doesn't appear with connection up, as normally it does.

When I try and start Wicd from the kmenu, the scanning screen appears, but is frozen up. After 4-5 tries to stop it with the mouse, a dialog finally appears saying wicd-client.py is not responding, and at that point I can terminate the wicd-client.py application from a button.

System shutdown problems posted above are still there. Maybe, as you've inferred, my basic problem is wicd related. On Gentoo, I do know last week I had to mask >=net-misc/wicd-1.7.1_pre20120127 as it broke my wireless, and drop back to wicd-1.7.1_pre20111210-r1. However, I was having these problems long before that, and still do, so it's a mystery that at least in my case it has to be something different in the 3.1 vs.3.2 and later staging/rtl8712/ directory. Using the 3.1 version in 3.2/3.3's has always resolved all issues. That, or a kernel config problem I'm missing.

Booting back to 3.2.3 using the 3.1.9 rtl87812 directory instead of its own, all is perfect.

I built the Arch 3.2.2 kernel from ABS with the one-line patch above, then copied the new r8712u.ko.gz on top of the original one in /lib/etc., rebooted, and it doesn't seem to change anything for me. When Wicd is run I still get the three or four "loading firmware" lines in dmesg, Wicd doesn't find any network, and sudo gets stuck (I forgot to mention that previously...)

I can confirm that Arch's .config sets CONFIG_R8712_AP=y, BTW.

Haven't tried anything else yet (disabling CONFIG_R8712_AP or using wpa_supplicant manually).

Is it confirmed that wpa_gui works or not? I'd like to avoid trying it manually- I guess wicd has spoiled me with it's ease of operation after years of manually configuring linux wireless connections.

I've never used wpa_supplicant directly, but just looking at the wpa_gui it looks decent enough, if it works without any problems (like wicd used to).

After reading this, and seeing the screenshots, http://blog.zx2c4.com/248 it's looking like a decent alternative. It's from Jan 25, 2010 so it must be further developed at this point.

Or, would using the full-blown wpa_gui version present problems similar to wicd?

I don't know whether wicd is the problem. All I know is that your kernel works fine with my user space. Wicd has never worked for me. I either use NetworkManager or manual configuration. In openSUSE, the latter is quite easy. I have not tried the wpa_supplicant GUI, but it should be free of any problems that affect wicd.

I just posted a patch to convert r8712u to use asynchronous firmware loading. This patch was sent upstream a few minutes ago. That will fix firmware load timeouts that will happen with an updated udev. The timeout reported by stgn in the second posting seems to be different.

After noticing that this patch was included in the 3.2.6 kernel, I decided to give it a try and get it from the Testing repository. Unfortunately, I still can't get wireless to work. I'm using netcfg and my wireless device is a RTL8188SU.

I found two lines in dmesg both saying "r8172u: Badfw->size of 303585696".

I had seen this error in testing, and had fixed it. After the finished patch was merged with staging, I started seeing the problem again. Unfortunately, when I add debugging statements in that region to see why it happens, it stops. I suspect some kind of race condition, but I do not understand it yet.

This patch should fix the Badfw size problem. I have given it only limited testing here, but so far it works.

Thank you very much, I'll try it now.

EDIT: Nevermind, I'll just wait for a while. I don't really know how to apply this patch, and the kernel source package I get from ABS is outdated, anyway.

OK, I have downloaded the 3.2.6 kernel sources for arch, applied the patch and compiled it. But after booting, when starting up my main network configuration with netcfg, I got these lines, followed by a [FAIL]

Could not set interface wlan0 flags: Operation not permitted
Failed to initialize driver interface
> wpa_supplicant did not start, possible configuration error

What is in dmesg? The messages you post say that the driver did not start, but not why.

Sorry, here's the dmesg output for each kernel version

http://pastebin.com/aXVPbrKT 3.1.9
http://pastebin.com/WzZDQaEG 3.2.6 (patched)

Private pastebin... Could you upload it to a public one?

Oops, I thought I had set them to be unlisted. It's ok now.

I did not see the line about a bad firmware size in the patched kernel. If you back out the second patch, what happens?

This is the output now: http://pastebin.com/zEuunBPX

To satisfy myself it wasn't wicd, I went to NetworkManager on several Gentoo systems, and had the same problems as when using wicd.

The new r8712u driver works in 3.2.x's, and 3.3-rc's, but the link quality is never better than 44%, and usually around 26-42%, with disconnects common. On the latest Arch Linux (testing 3.2.2 kernel, with NM freshly configured), r8712u loads, but neither NM or for that matter wicd is functional. On arch, I had to go back to a TP-Link WN722N USB adapter (ath9k chip), where Arch auto-detects and brings up wireless, but at only the 40% signal quality. (This might be just the TP-Link adapter, and not kernel related)

Went back to Gentoo, and compiled the freshest new 3.3.0-rc4, and 3.2.6 kernels just downloaded from kernel.org. Same low signal quality as before. I was hoping the new patches from Larry had done the trick, but apparently not, at least on my systems with the Rosewill usb r8712u adapter.

Once again, I copied over the 3.1.9 /staging/rtl8712 directory to the new kernels, and rebuilt the r8712u module in both 3.2.6 and 3.3.0-rc4.
Again, same great result. NM wireless immediately comes up normally showing 9 AP's, with a rock solid 98-99% link quality to my wpa-psk G router, no disconnects.

It seems apparent something regarding r8712u link/signal quality has gone amiss as of 3.2-rc kernels, and so far remains unresolved notwithstanding the other problems that were addressed.
BTW, I don't recall ever having that bad firmware size problem

Robert,

I cannot duplicate your result. I pulled a clean copy of the 3.1.10 source and built it. I then compared the results of 'iwlist scan' output between that kernel and my usual 3.3-rc3. All tests were done with the Rosewill adapter. I also generated copies of the 24 patches of r8712u that occurred between 3.1 and 3.2. I applied 11 of them to 3.1.10 and redid the scan. I then applied all 24 patches and redid the scan twice. My results are as follows:

kernel version with number of patches after +
ESSID 3.3-rc3 3.1.10 3.1.10+11 3.1.10+24 3.1.10+24

"radius" 100/100 100/100 100/100 100/100 100/100
"lwfdjf-n" 100/100 100/100 100/100 100/100 100/100
"STONE" 42/100 44/100 23/100 10/100 23/100
"2WIRE205" 42/100 42/100 42/100 26/100 42/100
"J-V Network" 46/100 43/100 48/100 45/100 47/100
"linksys" 43/100 44/100 26/100 44/100 42/100
"Hoover" 26/100 42/100 42/100 42/100 43/100
"hpsetup" 26/100 42/100 42/100 28/100 42/100
"KCCoyote,180th,E-SE" 26/100 Not found 28/100 28/100 28/100
"Larry_wpa1" 47/100 100/100 71/100 73/100 69/100
"<hidden>" 26/100 42/100 25/100 23/100 42/100
"BUCKEYES" Not found 7/100 26/100 Not Found Not Found
"KCCoyote,180th,W-SW" Not found 7/100 Not Found 7/100 7/100
"VINTAGE TOYS & JEWELRY" Not Found Not Found 7/100 Not Found Not Found
"linksys" #2 Not Found Not Found 7/100 7/100 Not Found
"2WIRE796" Not Found Not Found Not Found 7/100 Not Found
"Snead WiFi" Not Found Not Found Not Found Not Found 7/100

As you can see, there is as much variability between trials with exactly the same driver as there is between 3.1.10 and 3.3-rc3.

If you want to repeat this test, I can post the 24 patches.

Larry

Sayachan,

I found a problem with the patch for asynchronous firmware loading that causes it to be racy. Obviously, the Arch Linux user space is more susceptible that my openSUSE system, thus you have a much greater problem - it rarely happens for me.

There are two patches. The first is needed only with 3.2.6 and it reverts the patch that is causing the problem. The second patch does the firmware loading in a much better way that should avoid the problem; however, I would appreciate testing.

Larry,Thanks for looking into this- it's very much appreciated.
No need to post the patches unless someone else needs them. You results are similar to my own iwlist scan results, in that there's much variability between different routers that are seen. I assume iwlist is what NM and wicd reads to produce the graphical results.

I might have been a bit misleading in my above statement "NM wireless immediately comes up normally showing 9 AP's, with a rock solid 98-99% link quality to my wpa-psk G router, no disconnects."

This could imply I meant "all" 9 seen AP's were 98-99%, when I actually was referring only to my own router, and how with 3.1.x r8712u it's always 98-99%, and with all 3.2/3.3 r8712u it's always much less, as reported. This is always consistent the difference in levels using my own router/AP- it never has varied. Since I never use or have access to the other AP's, I never gave those much thought, as the drastic difference in my own wireless signal with 3.1.x and 3.2/3.3 kernels was my main cocern.

Something I noticed while trying to compare the file versions in both rtl8712 directories was the presence of the hal related files. Some do indeed have different sizes, due to past patches.

Since Gentoo has deprecated hal and adopted udev and friends (I manually removed it some time ago), and Arch more recently, I'm wondering if on distros that don't require hal if any of this hal stuff is even needed in the rtl8712 directory? Could that, or hal related patches applied as of 3.2rc's somehow be limiting link/signal levels, but only on USB adapter hardware?

In that you can't duplicate my problem even using the same adapter, I'm wondering if it has to be my personal system configs. Or, more likely, since it's seems to hold true for all the binary distros I've tried with their own generic 3.2 kernels, it would indicate it's the kernel itself. The common factor on my router/adapter with different distros is that all 3.1 kernels have 98-99% wireless levels and virtually no connection losses, and all 3.2/3.3 kernels drop to 26-42% with many connection losses.

The only bright side of all this for me is that at 67 years old, it's keeping my brain actively functioning.

The signal strength reported by NM is similar to that reported by the scan. I have no idea what wicd does, but it should be similar. BTW, these numbers are much like sausage - you don't really want to know the details of how they are produced.

I have no idea what the hal files are in your directory. The driver has never used the hal utility. In this case, it means the hardware abstraction layer. I recall that some files were copied over that were not needed, and were later deleted, but I thought that was long before 3.1 - the driver has been in the kernel since 2.6.37.

As far as I know, none of the differences between kernel 3.1 and 3.2 touch any of the parts that calculate signal strength, or even touch the receiver parameters. If you are really seeing a decrease in the strength, you will need to tell me which patch is causing the problem.

You are still young. I'll be 72 on my next birthday.

For example, in linux-3.2.5/drivers/staging/rtl8712/ (and 3.3.0-rc3), there are:

.hal_init.o.cmd 42 Kib
hal_init.c 12.0 Kib
hal_ini.o 6.0 Kib
.usb_halinit.o.cmd 42 Kib
rtl8712_hal.h 5 Kib
usb_halinit.c 12 Kib
usb_halinit.o 7 Kib

I'd certainly like to be able to tell you which patch might be a problem, but I'm not exactly sure what I'm looking for.

I thought since the problem seems related to the r8712u driver with usb hardware adapters, and Gentoo and Arch deprecating hal, then noticing hal files being in rtl8712, that this might be suspect. Probably a wrong conclusion, due to my very limited knowledge/insight on these subjects.

Those files have nothing to do with the user-space component hal. The *.cmd files are part of the build process, the *.o files are the output of the compiler, and the others are source files. All the .h and .c files are in the 3.2 source.

What you would do is start with the 3.1 source and add 12 of the 24 patches. If the test of that configuration shows the change in strength, then you remove 6 of the patches. If no change, then add 6 more, and keep cutting the number of patches in half until you determine which patch, if any, causes the problem. Just in case, I am posting the patches.

I see what you mean about how to apply the patches (cutting them in half progressively) to check things.

However, all my 3.1 kernels never have the link/signal quality issue. Did you mean patch the 3.2 and/or 3.3's? If not, I don't see the point in patching 3.1's, as they don't have the problem.

EDIT:
Unless, conversly, you mean these 20 patches are all the ones that have already been applied to stable 3.2 and 3.3-rc's, and the objective is to find which one (if any) is the one that causes the issue on my systems in 3.2?

Is that correct? I'll work on this tomorrow, as it's getting late.

Thanks very much for the help, and the info about the files I listed. I'm learning a lot.

OK- apparently my link quality issue is directly caused by r8712u_018.patch.

When modules are built after patching a fresh vanilla 3.1.10 with all the other r87812u patches listed above, the link level is my normal high 98%, as with all other 3.1.x kernels.

When I add 018 and rebuild modules, after reboot signal has immediately reverted back to 44/100 or less, as it has been with all vanilla 3.2 and 3.3 kernels on my systems.
It does work with 018, but the performance level is basically unacceptable.

When 018 is removed and I rebuild modules, on reboot signal strength is back to normal 98%, and all is well. In my case, 018 is definitely problematic.

I carefully looked at the 018 patch (various Realtek "fixes"), but am not sure where the problem might be. Does this mean this 018 patch was included (and still is) in 3.2 and 3.3?

BTW, 012 and 019 failed to apply with minor rejects, which I manually was able to fix.

Uh, wow. I feel a bit uncomfortable knowing I'm just a little kid (19) talking with experienced men here.

Anyway, lwfinger, after applying the two patches you provided, it still keeps failing. Here I provide, as usual, the dmesg output: http://pastebin.com/7v7W7DMX

I don't really know much about this, but what I can understand is that the problem is related to timing.

Robert,

Those 24 patches are the difference between 3.1 and 3.2 for this driver. The patch above will change the level setting in kernel 3.2 back to what was found in 3.1. For my openSUSE system, it makes absolutely no difference. The signal level from scans is unchanged as we saw yesterday, and the KDE applet for NetworkManager shows the same signal strength. Please apply this to any kernel that shows the problem and tell me what happens. I'm quite certain that the signal strength will be "restored" to 98%, but I don't know if that will change the performance.

Tried 8712u_change_level on a fresh 3.2.7, but unfortunately it didn't work. I even checked the file manually to be sure the patch applied.

Lsmod shows r8712u loaded, but the Rosewill adapter led isn't active at all- appears dead, not receiving any power. This is on my main Gentoo install, with wicd instead of NM. If you wish, I'll try it on one of my other Gentoos using NM, but I would expect the same results.

Wicd tray icon appears, and will open up, but can't scan- says no wireless networks available.

Ifconfig -a can see wlan0, and the Rosewill hardware address, but that's all.

Had to boot back to 3.2.6 with the 3.1.9 rtl88712 directory as the source to post this, which of course works perfectly.

Sorry, forgot to mention: I have not applied these two patches to any kernel, as I don't think I've ever seen these problems. Should I have done so anyway?
revert_8c213fa (8.7 KiB)
r8712u_firmware_load_fix (5.1 KiB)

I'm installing a copy of Arch Linux in a VM here. The base system is running; however, I cannot get wicd-CLI to run. It keeps throwing DBus errors. Once that is functional, I will be able to test.

That patch won't fix the problem of the adapter not starting. There is something fundamentally different about the Arch user space that calls the firmware loading twice. With the asynchronous firmware loading patch installed, you get a bad firmware size. With it reverted and the load fix, it loads the fw twice and makes the system hang. Until I get a copy here, I'm likely not to get it working.

@Larry: Maybe it's this error https://wiki.archlinux.org/index.php/Wicd#Dbus_connection_error_message?

You could also try and use netcfg or wifi-select.

Same thing happens with 3.3.0-rc4 and the 8712u_change_level patch as with 3.2.7 (on Gentoo x86 & amd64).

This r8712u adapter also will not work with any Arch Linux stock 3.2 kernel. Same problem as with my manually compiled Gentoo 3.2's and 3.3's.

FWIW, on Gentoo, recently I found wicd had to be loaded at the boot run level. I'm assuming Arch users will have dbus first in /etc/rc.conf, but maybe not have wicd directly after dbus, but after other items loading right after dbus? Just a thought, due to my problems with wicd on Gentoo before I placed it on the boot run level. http://en.gentoo-wiki.com/wiki/Wicd.

However, later on it turns out I actually have dbus loading at default run level, wicd at boot, and that does work. So it seems contradictory, as some Gentoo docs say dbus first. All I can say for sure is wicd at boot run level solved my wicd/dbus problem.

I have some more info. On my Arch Linux VM, I cloned the wireless-testing git tree. With it, I can generate any kernel I want. with it, I generated a 3.1.0 kernel and figured out how to connect to my wireless. The procedure I am using is to manually start wpa_supplicant, and then use iwconfig to set the ESSID. Next I issue a "ip link wlan0 up", followed by a "dhpcpd wlan0". After this, I have a WPA2 connection.

I then tested 3.2.0, 3.2.6-2-ARCH, and 3.3-rc4. The only difference that I see is that on kernel 3.1.0 the Link Quality is 0/100. After the r8712u patches (#18 in particular), the Link Quality is 100/100.

What exactly do you see that says the link level is lower. Next, I will get X running on this machine. I got wicd-curses running, but it could not connect. Neither would wifi-select work.

I've been getting my link-level/signal-level info from iwconfig wlan0, iwlist scan also shows signal level for each cell that it finds, wicd gui, which shows link-level in numerical percentages, beside each AP's name, and NM applet gui shows a horizontal bar with 7-8 gradations.

When iwconfig wlan0 shows 98-100/100, the bars are always full in the gui's, and when <44/100 the gui bars are proportionally full, and apparently pretty accurate in reporting what command line says.

I'm perplexed- are you saying applying patch #18 on 3.1 kernels actually boosts the LQ up to 100/100?
In all my tests with 3.1's, that was the one and only patch that brought my LQ down from 98/100 to always under 44/100.

Since you haven't mention it, if you want a wicd gui, IIRC with Arch you also need to install wicd-gtk and some "notify" package (and possibly 1-2 others), which are separate packages. In gentoo, the wicd ebuild pulls in every dependency. Both distros require you comment out/disable all other networking configs/settings and services in order to use wicd or NM.

Sayachan,

Please try this patch. I was finally able to get Arch Linux running on a real machine. Once I reached that point, I could reproduce your failure reliably. From there, the problem was easy to find and fix.

One other question. If the patch fixes your machine, is it OK for me to list you in a "Tested-by" line in the patch that is submitted? If so, I will need your real name and an E-mail address that will be published. I know some people want to avoid that to minimize spam.

Larry

Just to check, I applied the r8712u_startup patch, on a new 3.2.7. On reboot, terminal output proceeded normally, to where it reached loading wicd, kdm, and emerges into kdm. Right as wicd loaded, the Rosewill adapter's LED lights up, flashes normally through the kdm user login and into the kde desktop partially loading, but at the point where the wicd tray icon should appear the Rosewill led turns off, and then the normal desktop finishes loading, but of course no running wicd and wireless. And, the shutdown hang problem is back.

Rebooted, then once again I replaced the 3.2.7 /staging/rtl8712/ directory with the 3.1.9 version, and rebuild modules, then rebooted back to 3.2.7. Predictably, all was perfect again. Wicd comes up normally, with full link-quality of 100/100, no shutdown problem.

Here's the r8712u portions of dmesg when I was using the 3.2.7 verion of /staging/rtl8712. Maybe it will offer a clue.

ehci_hcd 0000:00:12.2: port 4 high speed
ehci_hcd 0000:00:12.2: GetStatus port:4 status 001005 0 ACK POWER sig=se0 PE CONNECT
usb 1-4: default language 0x0409
usb 1-4: udev 2, busnum 1, minor = 1
usb 1-4: New USB device found, idVendor=0bda, idProduct=8172
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: RNX-180UBE
usb 1-4: Manufacturer: Manufacturer Realtek
usb 1-4: SerialNumber: 00e04c000001
usb 1-4: usb_probe_device
usb 1-4: configuration #1 chosen from 1 choice
usb 1-4: adding 1-4:1.0 (config #1, interface 0)
hub 4-0:1.0: state 7 ports 3 chg 0000 evt 0000
hub 5-0:1.0: state 7 ports 3 chg 0000 evt 0000
hub 6-0:1.0: state 7 ports 3 chg 0000 evt 0000
hub 7-0:1.0: state 7 ports 2 chg 0000 evt 0000


r8712u: module is from the staging directory, the quality is unknown, you have been warned.
r8712u 1-4:1.0: usb_probe_interface
r8712u 1-4:1.0: usb_probe_interface - got id
r8712u: DriverVersion: v7_0.20100831
r8712u: register rtl8712_netdev_ops to netdev_ops
r8712u: USB_SPEED_HIGH with 4 endpoints
r8712u: Boot from EFUSE: Autoload OK


udevd[1487]: renamed network interface eth0 to eth1
r8712u: CustomerID = 0x0000
r8712u: MAC Address from efuse = 00:1a:ef:1a:23:ca
r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
usbcore: registered new interface driver r8712u

and finally, the last dmesg output:

Adding 4883756k swap on /dev/sda2. Priority:-1 extents:1 across:4883756k
r8712u: 1 RCR=0x153f00e
r8712u: 2 RCR=0x553f00e
r8712u: 1 RCR=0x153f00e
r8712u: 2 RCR=0x553f00e
r8712u: 1 RCR=0x153f00e
r8712u: 2 RCR=0x553f00e
ata1: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x7
ata1: SError: { HostInt }
ata1: hard resetting link
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete

This is interesting. With the 3.1.9 rtl8712 version in 3.2.7, and working full strength wireless, this is the entire dmesg r8712u sections:

r8712u: module is from the staging directory, the quality is unknown, you have been warned.
r8712u 1-4:1.0: usb_probe_interface
r8712u 1-4:1.0: usb_probe_interface - got id
r8712u: DriverVersion: v7_0.20100831
r8712u: register rtl8712_netdev_ops to netdev_ops
r8712u: USB_SPEED_HIGH with 4 endpoints
r8712u: Boot from EFUSE: Autoload OK


r8712u: CustomerID = 0x0000
r8712u: MAC Address from efuse = 00:1a:ef:1a:23:ca
usbcore: registered new interface driver r8712u


Adding 4883756k swap on /dev/sda2. Priority:-1 extents:1 across:4883756k
r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
r8712u: 1 RCR=0x153f00e
r8712u: 2 RCR=0x553f00e
wrc@localhost ~ $

UPDATE: I think I need to retry this- I didn't apply your newest firmware load patch, and my dmesg outputs seem to differ in where firmware is loading, and the r8712u: 1 RCR=0x153f00e/r8712u: and 2 RCR=0x553f00e lines seem to be loading 3 times when it doesn't work.

The latest patch will work only with a kernel that has the asynchronous firmware load patch installed. That means Arch 3.2.6, mainline 3.3-rc4, or later.

I gave up on getting Arch to work with X in my VM, and installed it in a spare partition on my sandbox/test machine. The air was full of language unsuitable for my grandchildren when I discovered that the installation process had corrupted the system partition for openSUSE, and I had to reinstall it as well. With an nVidia graphics adapter that works with nouveau, it was easy to get the KDE desktop working on Arch. With that setup, and wicd, I found the problem that caused the "firmware too big" message; however, after I got it fixed, wicd NEVER managed to make a connection, and it hung the system 4 or 5 times. When I removed it and installed NetworkManager and the plasmoid applet, I got a connection immediately, and was able to connect to WEP, WPA, and WPA2 networks. That was with the latest 3.3-rc4 kernel from the wireless-testing git tree.

I don't know what causes your problem, but I am dubious of wicd. To me, that is just too buggy. NM may have its problems from time-to-time, but I have never had it freeze the system the way wicd repeatedly did.

From my experience, wicd hasn't been very reliable. Much prefer netcfg2 over wicd. Haven't tried NM. In that manner, I wouldn't worry too much if it worked with NM and manually getting it up and running, but not with wicd.

I always test these things with iwconfig, dhcpd and wpa_supplicant. If that doesn't work, you'll know for sure the problem is in the driver. Larry, you've tested it like this, right? Does that work?

I'm completely convinced my problems are in the post 3.1.x r8712u driver, since all 3.2-rc's forward through 3.3.0-rc4 have the issue.
This is on Arch, 5 different Gentoo installs, and all live cd's and hard drive installs of 10 various other distros that have moved to 3.2 kernels.

This is across all distros whether I use wicd, NM, or manually set up all the config files.

In every case, for months and without fail, simply replacing the staging/rtl8712 directory in the 3.2/3.3 source with any 3.1.x version and then rebuilding the r8712u module and rebooting immediately resolves all wireless issues perfectly.

I hate even contemplating this, but has anyone tried ndiswrapper with the windows driver cd that came with the adapter? Years ago, that was the only decent solution I found with the mad-wifi atheros stuff when it first came out.

Apparently, it's either that, or keep using the 3.1.x version in 3.2/3.3 and beyond kernels until it no longer works, or forget about any r8712u dependent usb adapter ever working satisfactorily and getting a more expensive amped usb adapter using a different chipset. I doubt if realtek is paying much attention to this, and probably has no plans for further developing this driver, and in that case it's a dead end if you need a 3.2 kernel.

Robert, I am convinced Larry will find the solution. In the meantime, you can just compile the 3.1 module r8712u module once and put this in a daemon script:

modprobe -r r8712u
insmod /media/Data/rtl8712/r8712u.ko

This will make sure that my 3.1 module is loaded. There's no need to recompile anything and I can seamlessly update the Arch kernel. It's probably much less cumbersome than to recompile a kernel and reboot every time.

Ben,
Thanks- that's a great idea and will simplify things. I'll use it on Arch for sure.

So if I understand correctly, that trick will work for all future 3.2 and 3.3 Arch kernels? Likewise, I'm also confident Larry will track down the cause, if it's possible, regardless of any future help from Realtek.

I'm mainly a Gentoo user, but I always keep an Arch Linux partition on all my boxes for at least 5-6 years so I can keep up with it.

If there are no big changes in the module system, it will work I guess. I have the source of the module in my /media/Data/rtl8712/ folder, just in case. So if the module doesn't work in a future version, I'll just recompile against the current Arch kernel.

I did find a bug in commit a5ee652. For me, only wicd is affected by it - NM and manual setup are OK.

A workaround is extremely simple. In drivers/staging/rtl8712/os_intfs.c, find the lines that say

/* The interface is no longer Up: */
padapter->bup = false;

and remove them. That will restore the previous behavior. That change and the r8712u_startup patch above should allow the driver to work with kernel 3.2.6 and later. Note, the change that was made there is not wrong. What id did is expose a bug in some other location that was previously dormant. I have some ideas and I am testing them. When a final patch is ready, i will post it here.

It is unlikely that Realtek will provide any help on this driver. They already told me that they will not help with the conversion to mac80211.

Everything works fine now after I applied the patch and then commented out that line of code.

Just so I will never run into a problem like this ever again, I'm thinking on either getting a different wireless USB adapter or just try to find a way to connect my computer directly to the router.

Connecting directly or getting a different adapter will not prevent things like this from happening. What you need to do is always keep a kernel that works available. Keep in mind that the device never failed for me on my openSUSE system - neither bug hurt me, which is why it was not found earlier.

Is it OK if I list you in the patch in a "Tested-by" line? If so, I will need your name and e-mail address.

I can confirm this works for me on 3.2.7 (will try 3.3.0-rc4 later today), but the link-level is down to 44/100 fromm 100/100. I didn't apply the r87812u_change_level patch this time, so maybe that will fix it right up. If I recall correctly, that one caused 3.2.7 to not boot at all (maybe just a coincidence?). I'll give it another try. We all owe Larry many thanks- all his work on this is much appreciated!

Anyway, after I removed the two lines as instructed, I patched with r8712u_startup, but got a little reject:

wrc@localhost ~/kern/linux-3.2.7 $ patch -p1 < r8712u_startup
patching file drivers/staging/rtl8712/os_intfs.c
Hunk #1 FAILED at 477.
1 out of 1 hunk FAILED -- saving rejects to file drivers/staging/rtl8712/os_intfs.c.rej
patching file drivers/staging/rtl8712/usb_intf.c
Hunk #2 succeeded at 622 (offset 1 line).

The reject says this, and I manually fixed it:

--- drivers/staging/rtl8712/os_intfs.c
+++ drivers/staging/rtl8712/os_intfs.c
@@ -477,9 +477,6 @@
r8712_free_network_queue(padapter);
/* The interface is no longer Up: */
padapter->bup = false;
- release_firmware(padapter->fw);
- /* never exit with a firmware callback pending */
- wait_for_completion(&padapter->rtl8712_fw_ready);
return 0;
}

Looks like this is headed to a solution! Ironically (in desperation), I just ordered one of those supposedly "worlds best long-range" Alfa AWUS036NH 2000mw amplified wireless usb adapters with the Ralink rt3070 chip. Figured it was worth trying something without the r8712u dependent chips.

Yes, I will send you an e-mail with all the information.

I can happily confirm that on 3.2.7 removing the two lines as instructed above, and applying Larry's r8712u_startup and r8712u_change_level patches has resolved all my issues.

Kernel 3.2.7 has now got the levels and performance characteristics of all the 3.1 series kernels, and wireless now functions perfectly, even with wicd!

Curiously, for some reason I never seemed to need the r8712u_firmware_load_fix patch.

Larry, I can't thank you enough! These wireless issues have been driving me crazy ever since the 3.2-rc's came out.

Robert: The bup=false problem (the 2-line patch) aggravated the firmware loading one. That is the main reason that I found the fw problem first. In addition, it caused an occasional problem on my openSUSE system using NM.

Those two patches have been submitted to the staging tree as regression fixes. Both should be in 3.3-rc5 or -rc6. The 2-line one will also be backported to 3.2.X.

Curiously, I still have never seen any change in wifi levels in any tool. Could you open a new bug, and post screen shots, or text output showing what and how you see with/without the change level patch. At the moment, I do not plan to push that one.

Do we agree that these 2 bugs can be closed?

I have also noticed a slight signal level decrease (from 100% to 64%), but that's another story. (It might just be because the door to my room is closed and the router is just a bit far away, in the living room)

Right now I think these bugs should indeed be closed.

This is with the change_level patch (shown below).

Without it, Link Quality=44/100 (or less), and Signal level=44/100 )(or less), with connection losses common.

With the patch, wicd-client & NM always say connected to linked-WRC at 100% and show full bars when Link Quality=100/100, and are proportionally filled when without the patch, when Link Quality=44/100 or less.

IMO and experience, the change_level patch has major effects, and hopefully will be included in the kernel. My results have been totally consistent over countless trials with many kernels and distros. In any case, I'll definitely be using it here, as for me it's indispensable, making wireless now possible with 3.2.x and 3.3-rc's.

I concur with Sayachan, as rarely I will see slight and very temporary LQ variations (5-15%), as my router and computer are at opposite corners of the house with walls, doors, and kitchen appliances partially in the line-of-sight. I've also noticed temperature/humidity and/or day and night variations will slightly affect wireless strengths.
------------------------------------------------------------------------------------------------------------------------------------------------------

localhost wrc # iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:"linked-WRC" Nickname:"rtl_wifi"
Mode:Managed Frequency:2.442 GHz Access Point: F8:D1:11:4C:2F:78
Bit Rate:150 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:****-****-****-****-****-****-****-**** Security mode:open
Power Management:off
Link Quality=100/100 Signal level=45/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
-------------------------------------------------------------------------------------
localhost wrc # iwlist scan
lo Interface doesn't support scanning.

eth1 Interface doesn't support scanning.
wlan0 Scan completed :
Cell 01 - Address: F8:D1:11:4C:2F:78
ESSID:"linked-WRC"
Protocol:IEEE 802.11bgn
Mode:Master
Frequency:2.442 GHz (Channel 7)
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
48 Mb/s; 54 Mb/s
Extra:rsn_ie=30140100000fac040100000fac040100000fac020000
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
Signal level=100/100
-------------------------------------------------------------------------------------------------------------------------------------------------

UPDATE:
FWIW, I just booted to a Ubuntu installation I have on this same box (different partition). I'm using the 3.2.0-17-generic-pae kernel, and it boots with wireless working, but the level is the same lower 44/100 as I've previously had without the r8712u_change_level patch. I looked at the ubuntu 3.2.0 source, and indeed the rtl871x_ioctl_linux.c file has not been modified with the new "piwstats->qual.qual = tmp_qual;" line edit.

I guess that explains the 44/100 LQ level I'm getting on Ubuntu (also on Kubuntu), thus IMO pointing out the merit of this patch across all distros, i.e. putting it in the mainline kernel. Apparently, Ubuntu has addressed the other issues in 3.2 kernels that at least in my case have disallowed connecting with wireless.

Just hit a snag with 3.3.0rc5, during make modules. Maybe I made a patch error. Will redo.
CC [M] drivers/staging/rtl8712/xmit_linux.o
CC [M] drivers/staging/rtl8712/usb_intf.o
drivers/staging/rtl8712/usb_intf.c: In function ‘r871xu_dev_remove’:
drivers/staging/rtl8712/usb_intf.c:623:9: error: implicit declaration of function ‘release_firmware’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

make[3]: *** [drivers/staging/rtl8712/usb_intf.o] Error 1
make[2]: *** [drivers/staging/rtl8712] Error 2
make[1]: *** [drivers/staging] Error 2
make: *** [drivers] Error 2
wrc@gentoo-amd64 ~/kern/linux-3.3-rc5 $


UPDATE: OK, was an error on my part- 2nd try compiled fine.

File drivers/staging/rtl8712/usb_intf.c needs the following line:

#include <linux/firmware.h>

It should be placed with the other includes near the beginning of the file. That line is part of the patch I pushed upstream.

I was finally able to duplicate your signal problems with a weakened signal. As my test box is a desktop machine, I couldn't more around the house, but I reduced the signal by removing the antenna from the Rosewill unit. I got the following:

w/o signal quality patch:
NetworkManager: 6 of 10 bars
wicd: status line 60%, ESSID Line 61%, 3 of 4 bars
iwconfig: Link 56/100, Signal 56/100

with patch:
NetworkManager: 9 of 10 bars
wicd: status line 100%, ESSID Line 61%, 3 of 4 bars
iwconfig: Link 92/100, Signal 61/100

Obviously, wicd gets the info for the status line at the bottom of its screen from the Link Quality. Similarly, NM sets its number of bars from the same value. I will push a patch; however, I want you to go to bugzilla.kernel.org and fill out a bug report for this problem and list it as a regression. After you do that, please post the Bugzilla number here.

Just finished a 3.3.0-rc5, with the startup patch, removing the 2 os_intfs.c lines as mentioned above, and the signal quality patch. Wireless works perfectly as with 3.2.7, with wicd.
(As of today, Gentoo is having trouble with the newest wicd and openrc-9.9 and dhcpcd, so I had to use stactic addresses, and downgrade wicd a notch).

About the bug report, you are talking about only the signal level issue and the patch, correct? I've never reported a bug to kernel.org- hope I get it right.

BTW, I'm using a stationary wireless desktop also for all this, but I've never removed the antenna, or moved it. All readings have been done under the exact same conditions.

You don't need to post the patch in the bug report. Just state the changes that you see between 3.1 and 3.2 or later. It won't hurt if you get it wrong. I just want a Bug report to reference in the patch.

My desktop is only 2m from the AP, which is why I had to knock the signal down by removing the antenna. With either of my devices that use r8712u, I got 100% with or without the patch, and the problem is only visible with medium or weak signals.

Larry,
Bug 42826 Submitted. https://bugzilla.kernel.org/show_bug.cgi?id=42826

However, I just realized I forgot to list it as a regression. Will see if I can edit that in. Hope this is what you needed.

OK- listed as regression now.

FWIW. I just tried the new 3.3.0rc6 on Gentoo, as I saw these 7 r8712u patches were included, thinking that was including Larry's three patches which had fixed all r8712u issues when applied to any 3.2 or 3.3-rc kernel. A day before, I had looked in the linux-next: next-20120302 gitweb souce and saw Larry's three patches, then rc6 was released so I assumed "next" from a few days ago was now "rc6." Guess I was wrong. In any case, the 7 new r8712u patches did nothing I could discern, and in fact after a 2 second LED blinking while booting, the usb r8712u wireless adapter is again DOA when booting is finished.

I then replaced the 3.3.0-rc6 rtl8712 directory with a 3.2.9 version I had patched with Larry's three patches, rebuilt the modules, rebooted to 3.3.0-rc6, and all wireless was well, with full strength 100/100 connection. Here are the new patches included for rc6:

drivers/staging/rtl8712/drv_types.h 7 + 0 - 0 !
drivers/staging/rtl8712/hal_init.c 43 + 19 - 0 !
drivers/staging/rtl8712/os_intfs.c 11 + 3 - 0 !
drivers/staging/rtl8712/rtl8712_hal.h 1 + 0 - 0 !
drivers/staging/rtl8712/rtl871x_mlme.c 1 + 1 - 0 !
drivers/staging/rtl8712/rtl871x_sta_mgt.c 1 + 0 - 0 !
drivers/staging/rtl8712/usb_intf.c 7 + 3 - 0 !

BTW, Mageia Linux did have Larry's signal level patch in its new 3.2.9. r8712u loaded, but the wlan0 interface isn't recognized, wireless is still DOA. Had to use an ath9k adapter.

Larry- I left a comment at Bug 42826 on bugzilla.kernel.org

I am still having this bug with 3.2.11-1. When will the fix be backported?

@revelation60,
If you're referring to the little signal level patch, apparently it's not going to be included in 3.3 mainline, although I can't understand why. For me, on various distros and all 3.2 and 3.3 kernels so far just that one little edit on line number 2389 of the /drivers/staging/rtl8712/rtl8781x_ioctl_linux.c file (changing "piwstats->qual.qual = tmp_level" to "piwstats->qual.qual = tmp_qual") improves my levels to 98-100/100 with complete stability from =<42/100 and regular connection loses every time.

I don't compile my own kernels on Arch, but do on Gentoo, so I've just been going into the file and making the edit every time I do a new kernel, as for me it's necessary as I can only get a "medium" quality connection due to the router location in my house. Apparently, unless your router and adapter are very close you're likely to run into this problem, unless your distro makes the edit in it's kernels, or you compile your own (IMO a big pita with a binary distro).

Larry's comment from the kernel.org bugzilla:


Comment #4 From Larry Finger 2012-03-04 16:24:36 (-) [reply]

The signal level change is commit da3e6ec2f443ac00aa623c5921e3521f5f38efe4
"staging: r8712u: Fix regression in signal level after commit c6dc001" in
staging-next. This "problem" is cosmetic, and is not of high-enough priority to
push it through to the 3.3 mainline.

The fixes in staging-next that allow the driver to function, are as follows:

1. commit 2080913e017ab9f88379d93fd09546ad95faf87b "staging: r8712u: Fix
regression caused by commit 8c213fa"

2. commit 9f4bc8cf3fe750ed093856a5f5d41c11cc12ad22 "staging: r8712u: Fix
regression introduced by commit a5ee652"

Both of these fix real problems and should be pushed to the 3.3 mainline.

Apparently, they aren't in 3.3.0 by default as it has the same problems, but I just tried linux-next-20120320 and r8712u works normally with no patching required, and full 100/100.

I guess this means we'll see this in the 3.4-rc's, and/or maybe it will be back-ported to 3.3.x's? Please correct me if that's wrong.

I have this device:
Bus 001 Device 011: ID 050d:945a Belkin Components F7D1101 Basic Wireless USB Adapter v1000 [Realtek RTL8188SU]

my dmesg is:
[47991.888889] r8712u: DriverVersion: v7_0.20100831
[47991.888916] r8712u: register rtl8712_netdev_ops to netdev_ops
[47991.888919] r8712u: USB_SPEED_HIGH with 4 endpoints
[47991.889727] r8712u: Boot from EFUSE: Autoload OK
[47992.614740] r8712u: CustomerID = 0x0000
[47992.614747] r8712u: MAC Address from efuse = 94:44:52:ac:99:a3
[47992.614752] r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
[47992.615312] usbcore: registered new interface driver r8712u
[47993.618987] r8712u: 1 RCR=0x153f00e
[47993.619732] r8712u: 2 RCR=0x553f00e
[47993.725762] ADDRCONF(NETDEV_UP): wlan1: link is not ready
[47994.050740] r8172u: Badfw->size of -213214464
[47994.107488] r8172u: Badfw->size of -213214464
[47994.177364] r8172u: Badfw->size of -213214464

with kernel: 3.2.13-1-ARCH which patch should I apply?

narco,
Applying Larry's r8712u_startup and r8712u_change_level patches has resolved all my issues on Gentoo. However, since you have Badfw->size of -213214464 you might try this firmware (attached). It works on all my systems, and is 129,304 kb in size. Rename your existing lib/firmware/rtlwifi/rtl8712u.bin, and then copy the attached .bin file to lib/firmware/rtlwifi/, and see if that works.

Since your Arch kernel seems to be registering the interface and driver, I guess the Arch devs have already patched the kernel (think I read that somewhere recently). Does ifconfig -a report wlan1 as your interface?

IIRC, some of Larry's r8712u patches didn't apply cleanly, and I had to manually fix the files. I found it simpler to just replace the entire linux-3.2.x/drivers/staging/rtl8712 directory with one from a 3.1 kernel BEFORE compiling my new 3.2 kernels. Worked every time. I guess you could get the source for the Arch kernel, and do the same thing, as I'm sure Arch custom patches their kernels from the generic vanilla kernel.org versions. You would think 3.2.13 would have these patches included by now, but I don't think they do. I've moved on to 3.3.0, and still had to patch it on Gentoo. I expect 3.4-rc's to have them, so after that this should no longer be an issue for r8712u dependent hardware users.

The "Badfw size" message is NOT due to having the wrong firmware image. Marco needs to apply the startup patch from my 23-Feb-2012 comment.

Thanks... I patched the kernel with Larry's patch: r8712u_startup, now i have this:

[ 1592.523536] usb 1-1.3: new high-speed USB device number 20 using ehci_hcd
[ 1592.615816] r8712u: module is from the staging directory, the quality is unknown, you have been warned.
[ 1592.618880] r8712u: DriverVersion: v7_0.20100831
[ 1592.618906] r8712u: register rtl8712_netdev_ops to netdev_ops
[ 1592.618910] r8712u: USB_SPEED_HIGH with 4 endpoints
[ 1592.619510] r8712u: Boot from EFUSE: Autoload OK
[ 1593.331771] r8712u: CustomerID = 0x0000
[ 1593.331779] r8712u: MAC Address from efuse = 94:44:52:ac:99:a3
[ 1593.331784] r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
[ 1593.332142] usbcore: registered new interface driver r8712u
[ 1594.047016] r8712u: 1 RCR=0x153f00e
[ 1594.047762] r8712u: 2 RCR=0x553f00e
[ 1594.153804] ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 1595.067015] r8712u: 1 RCR=0x153f00e
[ 1595.067763] r8712u: 2 RCR=0x553f00e
[ 1595.173755] ADDRCONF(NETDEV_UP): wlan1: link is not ready

the led on the adapter is on now, but I still can not connect to my network...


narco@narch86 Desktop]$ iwconfig
lo no wireless extensions.

wlan1 unassociated Nickname:"rtl_wifi"
Mode:Managed Access Point: Not-Associated Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management: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

eth0 no wireless extensions.


and:

[narco@narch86 Desktop]$ iwlist wlan1 scan
wlan1 No scan results

anyway thanks for the answers!

Are you using a manual configuration file, or using wicd or NetworkManager? Any dbus problem message? Larry also had a firmware_load_fix patch, but I think all this stuff has been through several revisions, so I'm not sure at this point what's been dropped or combined, or what would still apply to kernel 3.2.13. I do know that as of the linux-next-20120320 source everything worked normally with no patching.

What does your Arch /etc/rc.conf file's daemons line look like? If things load in the wrong order, it will have problems.

I'm wondering if we can assume you have the kernel patched correctly, or not, and if it's now actually just a config problem.

I use NetworkManager, but i haven't any kind of problems with my other adapter that use rt2800usb module.
My rc.conf is:
DAEMONS=(syslog-ng dbus sensors slim networkmanager crond). The strange thing is that I can connect if I use "ndiswrapper" with the windows driver installed, obviously I hate this solution...
Now I'm using other adapter and everything goes ok, thanks for your time...

Yeah- I too used another adapter with the same ralink rt2800usb chip/driver and yet another adapter using atheros athk9_htc on Arch and a few other binary distros where I didn't want to spend time building custom kernels.

The main problem with these adapters was iwconfig wlan0 never reported over 45/100 levels, whereas with the r8712u usb Rosewill adapter with Larry's signal_level patch always gets 98-100/100. Without the signal_level patch the r8712u device would match the ralink's 45/100 levels, so I really wanted the r8712u device fully functioning.

If anyone is interested, I just tried the new 3.4.0-rc1 vanilla kernel on my Gentoo partitions, and my r8712u usb wireless device is now working normally, with 99/100 level.

Guess this confirms the r8712u problems are now fixed. Many thanks to Larry- all us r8712u users really appreciate your great and persistent help on this!

I second that. I'm really glad this is now fixed, and happy to have been of help in the testing process. :)

I suppose this bug shall be marked as closed once the latest stable kernel version that arrived this night is pushed into the core repository.

Larry's r8712u fixes are now in the new stable 3.2.14 AND 3.3.1 staging directories! Wonderful! Our prayers have been answered!
I'd say at the very least this means it should be in all distros moving to post 3.2.13 default kernels.

http://lwn.net/Articles/490270
http://lwn.net/Articles/490271

Larry Finger (6):
staging: r8712u: Fix regression introduced by commit a5ee652
staging: r8712u: Fix regression in signal level after commit c6dc001
rtlwifi: rtl8192c_common: rtl8192de: Check for allocation failures
rtlwifi: rtl8192c: Prevent sleeping from invalid context in rtl8192cu
rtlwifi: Convert to asynchronous firmware load
staging: r8712u: Add missing initialization and remove configuration parameter CONFIG_R8712_AP