Bug 42826

Summary: problems with the r8712u staging driver on all 3.2.x (incuding rc's), and all 3.3.0-rc's
Product: Other Reporter: Robert Crawford (wrc1944)
Component: ModulesAssignee: other_modules
Status: RESOLVED CODE_FIX    
Severity: normal CC: aklhfex, alan, albert.chang, Larry.Finger
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: All 3.2.x and 3.3.0-rc's Subsystem:
Regression: Yes Bisected commit-id:

Description Robert Crawford 2012-02-26 22:08:50 UTC
I have had a Link Quality level problems with the r8712u staging driver on all 3.2.x (incuding rc's), and all 3.3.0-rc's, and Larry finger requested that I file a bug report, so here it is. 

This r8712u usb wireless problem has plagued me for weeks on countless 3.2.x and 3.3.0-rc kernels, on several Gentoo systems, and with Arch, Mageia Cauldron, and a few other distros.  It is consistent with Wicd, NetworkManager, or manually configured.

I'm using this hardware: 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

Here are some more relevant comments from a discussion at:      https://bugs.archlinux.org/task/27996  

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 bars.

Then, a few days later after some more struggling around, where Larry had fixed some other issues:

The new r8712u driver works in 3.2.x's, and 3.3-rc's, but the link quality is still 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.
Comment 1 Robert Crawford 2012-02-26 22:14:53 UTC
Sorry- forgot to list this as a regression.
Comment 2 Robert Crawford 2012-02-26 22:56:31 UTC
Sorry- forgot to list this as a regression.
Comment 3 Robert Crawford 2012-03-04 14:59:10 UTC
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 booted, the usb r8712u wireless adapter is again DOA when booting is finished. Seems like things are going backwards- at least the later vanilla 3.2's will bring up the wireless interface albeit with a very crippled signal level (that Larry's patch fixes).

Anyway, I then replaced the 3.3.0-rc6 rtl88712 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.  FWIW, here are the new patches 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
Comment 4 Larry Finger 2012-03-04 16:24:36 UTC
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.