/drivers/net/wireless/rtl8192cu is missing from 3.17 & 3.18

[DougieLawson]

/drivers/net/wireless/rtl8192cu is in 3.16 but missing from 3.17 & 3.18.

With a 3.18 kernel my Edimax RTL8188CUS dongle keeps dropping out and losing the network. Can the 8192cu stuff be added back in to the 3.18 source tree?

[amtssp]

I have a similar problem with 3.18 and rtl8192cu Edimax wifi.

[popcornmix]

It appears some users prefer the upstream rtl8192cu driver and some the out-of-tree driver. E.g.
#369 #566

There were conflicts with the out-of-tree driver when moving to 3.18 so I chose to give the upstream driver a try. Really I would very much prefer to use the upstream driver. If there are bugs with it, then they should be reported upstream, fixed there and I can pull in the fixes.

However I accept that the upstream driver has been broken (at least for some users) for a long time, and it is a very widely used driver on the Pi, so some flexibility is possible.
I'll see if there is a newer version of the out-of-tree driver that works with 3.18.

It would be useful if you could file a upstream bug, as making the upstream driver reliable is the best solution. See https://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html

[DougieLawson]

At the moment this is a 100% show stopper.

If you were to try to push this kernel on the normal branch (not BRANCH=next) then close to half of the WiFi attached Raspberry Pis in the World will stop working (because the Edimax dongle is one of the highly recommended dongles and has been since at least August 2012 when I got my first RPi).

There's probably a larger user base with Raspberry Pis than on any upstream machines. How many folks outside of "Raspberry Pi Land" wouldn't have some other brand of WiFi on-board and be using USB dongles now?

The upstream driver runs for a short time, but then silently fails, it's so flaky that there's now a long cat5 cable running from my switch to the Raspberry Pi that lives in my conservatory to keep it connected. If I could work out what parms to pass to the module then I'm happy to run it with very verbose debugging enabled. I've been unable to find out what parms can be set for power management either (with this "new" driver).

The out-of-tree driver has some well documented parms that are commonly offered on the RPi forum as a solution to the WiFi dongle randomly disconnecting and most "punters" go away happy with those.

I'm running with a self-built (cross compiled) 3.18.1 kernel and not adverse to patching code.

[DougieLawson]

I've sent an email to linux-wireless@vger.kernel.org reporting this bug. If you'd like a copy of what I've sent please ask.

[popcornmix]

@DougieLawson
If you can find source for rtl8192cu that builds for 3.18 that would be useful. I believe I originally got the driver source from here:
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=48&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true#RTL8192CU

but that's over a year old and only claims to support up to kernel 3.9.

I seem to remember finding a github which maintained a newer version of that code.

[MrEngman]

I set up an SD card with 3.18.1 then I copied the rtl8192cu source from 3.12.35+ #730 into a separate directory and cloned linux and firmware from github and checked them out for 3.18.y

/home/pi/src/linux
             firmware
             rtl8192cu

Then setup linux using

cd /home/pi/src/Linux
sudo ln -s /home/pi/src/linux /lib/modules/$(uname -r)/build
sudo ln -s /home/pi/src/linux/arch/arm /home/pi/src/linux/arch/armv6l

make mrproper && zcat /proc/config/gz > .config && make modules_prepare && cp ../firmware/extra/Modules.symvers .

then patched rtl8192cu/Makefile to get it to compile.

--- Makefile.old        2015-01-06 13:03:53.876742260 +0000
+++ Makefile    2015-01-06 02:32:10.181163732 +0000
@@ -70,6 +70,7 @@
 CONFIG_PLATFORM_MSTAR_A3 = n
 CONFIG_PLATFORM_ARM_SUNxI = n
 CONFIG_PLATFORM_ARM_SUN6I = n
+CONFIG_PLATFORM_RPI_BCM2708 = y

 CONFIG_DRVEXT_MODULE = n

@@ -236,6 +237,16 @@
 EXTRA_CFLAGS += -DCONFIG_INTEL_WIDI
 endif

+ifeq ($(CONFIG_PLATFORM_RPI_BCM2708), y)
+EXTRA_CFLAGS += -DCONFIG_LITTLE_ENDIAN
+ARCH := arm
+CROSS_COMPILE ?=
+KVER  := $(shell uname -r)
+KSRC := /lib/modules/$(KVER)/build
+MODDESTDIR := /lib/modules/$(KVER)/kernel/drivers/net/wireless/
+INSTALL_PREFIX :=
+endif
+
 ifeq ($(CONFIG_PLATFORM_I386_PC), y)
 EXTRA_CFLAGS += -DCONFIG_LITTLE_ENDIAN
 SUBARCH := $(shell uname -m | sed -e s/i.86/i386/)

Compiled the driver using

cd /home/pi/src/rtl8192cu
make clean && make && sudo make install

Came up with a single warning but compiled and appears to run without problems as in 3.12.xx.

[popcornmix]

Thanks @MrEngman
I'll add it back in.

Seems the build problem I was hitting was the change in procfs. I had to disable CONFIG_PROC_DEBUG to get it to build.

[MrEngman]

Thanks, that will make a lot of people happy.

re: procfs. I've no idea what that is but glad you've fixed it. Note,I had to compile using gcc 4.7 as gcc 4.8 caused command make modules_prepare to fail with an error. see issue #758

One thing I forgot. To get the 8192cu driver to load in 3.18.1 #731 it's necessary to blacklist the rtl8192cu driver that is currently compiled in the 3.18.1 image.

Add the line

blacklist rtl8192cu

to file /etc/modprobe.d/raspi-blacklist.conf. Note no spaces before blacklist rtl8192cu.

[popcornmix]

I've pushed it. I didn't need the blacklist - I'm getting 8192cu as default.
Not sure what the kernel rules are for when two modules both support a VID/PID, probably undefined.

It may make sense to blacklist the less preferred (rtl8192cu) as a default on raspbian. If someone wants to switch they can swap the blacklisted one.

[MrEngman]

Yes, works just fine, thanks.

[popcornmix]

@DougieLawson okay for you?

[DougieLawson]

I'll trust the excellent work from Mr Engman. He is the "Dongle Driver King".

I got a reply from the upstream maintainer, but it was only suggesting updating the stuff in /lib/firmware. So I won't be pursuing that.

Thanks everyone. This can be closed.