[rtl8xxxu] rtl8192cu (0bda:8176) on linux-4.9.11 (arm) high sirq rate

[rtl8xxxu] rtl8192cu (0bda:8176) on linux-4.9.11 (arm) high sirq rate

[Christian Hilberg]

Hi all,

currently I'm testing rtl8xxxu on an ARM device (i.mx28, armv5te) under
linux-4.9.11 with a RealTek 8192cu (0bda:8176) wifi dongle. Since
I had to set CONFIG_RTL8XXXU_UNTESTED, I'm prepared to see some
rough edges here and there. :-)

The driver actually works and I'm getting a stable connection on
a WPA2 secured wifi network. As a firmware blob, the driver loads
the "rtl8192cufw_TMSC.bin", which I extracted from [0].

However, the sirg rate is rather high (between 20% to 50% in top),
as soon as the device is getting upped, that is, as soon as IFF_UP
gets written to the device via ioctl().

In the same setup, but with the rtlwifi driver, I'm not seeing a high
sirq rate, but that driver drops connection every now and then for me,
so I'd rather resort to rtl8xxxu.

I've prepped a kernel with ftrace functionality and got some logs,
which seem to point to the USB subsystem (many entries about URB
giveback, but I'm not clear whether this is an issue here).

In a private mail, Jes hinted that there might be something going on
with enabling interrupts on the chip or some debugging related
stuff (just I'm not seeing any on the console).

I'm a little lost here, any pointers on the matter are much welcome.
If needed, I can provide ftrace logs, just slip me a note.

Regards,

	Christian

PS.:	I've seen the same sirq rate back to rc-Versions of 4.9 on
	that arm device.


[0] http://ftp.de.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-realtek_20161130-2_all.deb

-- 

Re: [rtl8xxxu] rtl8192cu (0bda:8176) on linux-4.9.11 (arm) high sirq rate

[Christian Hilberg]

[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]

Hi again,

Am Montag, 20. Februar 2017, 14:51:54 CET schrieb Christian Hilberg:
> Hi all,
> 
> currently I'm testing rtl8xxxu on an ARM device (i.mx28, armv5te) under
> linux-4.9.11 with a RealTek 8192cu (0bda:8176) wifi dongle. Since
> I had to set CONFIG_RTL8XXXU_UNTESTED, I'm prepared to see some
> rough edges here and there. :-)

The rtl8xxxu driver identifies the device as "8188CU", and so does lsusb.

> The driver actually works and I'm getting a stable connection on
> a WPA2 secured wifi network. As a firmware blob, the driver loads
> the "rtl8192cufw_TMSC.bin", which I extracted from [0].
> 
> However, the sirg rate is rather high (between 20% to 50% in top),
> as soon as the device is getting upped, that is, as soon as IFF_UP
> gets written to the device via ioctl().

I've dug further into this.

It shows that if in the driver's rtl8xxxu_identify_chip() routine for the 
RTL8188C variant I set priv->usb_interrupts = 0, then the sirq load vanishes
and the driver apparently still works:

---8<---
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/
net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 82d949ede294..2daacfd059b8 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -1687,7 +1687,7 @@ static int rtl8xxxu_identify_chip(struct rtl8xxxu_priv 
*priv)
                priv->rx_paths = 1;
                priv->tx_paths = 1;
                priv->rtl_chip = RTL8188C;
-               priv->usb_interrupts = 1;
+               priv->usb_interrupts = 0;
                priv->has_wifi = 1;
        }
---8<---

Seems to me that rtl8xxxu_int_complete() does nothing with the URB data but to 
re-submit it (just to satisfy hardware which wants its interrupts to be 
handled maybe?).

I'm not at all clear whether the above change would be the Right Thing to do.
Jes, do you have any thoughts on this? Are there 8188CU variants which need
interrupts to be handled?

Regards,

	Christian

> [0]
> http://ftp.de.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-r
> ealtek_20161130-2_all.deb


-- 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]