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

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

Hi again,

Am Montag, 20. Februar 2017, 14:51:54 CET schrieb Christian Hilberg:

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

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

net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 82d949ede294..2daacfd059b8 100644

@@ -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