High CPU load on Raspberry Pi when USB wifi dongle attached

[MartynGough]

I made the htc_9271.fw file from a clone of the repo following the build instructions, when I copy the file into /lib/firmware/ and reboot my pi, the wifi USB dongle is found and I can connect to wifi access points. However, when running a moderatly network intensive application I see an extra 25% CPU load compaired to when it's not installed. This extra load is apparent when wifi is connected or not.

lsusb lists the wifi dongle as: 040d:3801 VIA Technologies, Inc.

I have run similar tests with a Ralink Wifi USB dongle and the CPU load is not affected so it's something to do with the Atheros Wifi firmware/hardware.

Are there any settings/flags I need to set to improve the performance?

[olerem]

First thing what i came me in mind is USB EP3/4, Interrupt vs Bulk transfer. Are you able to configure kernel do disable LED blinking?

[erikarn]

.. and which kernel are you using? The USB code for the raspberry pi isn't always very efficient.

-adrian

On 22 October 2014 06:28, Oleksij Rempel notifications@github.com wrote:

First thing what i came me in mind is USB EP3/4, Interrupt vs Bulk transfer. Are you able to configure kernel do disable LED blinking?

— Reply to this email directly or view it on GitHub https://github.com/qca/open-ath9k-htc-firmware/issues/68#issuecomment-60084026 .

[MartynGough]

I'm currently using Wheezy, 3.12.22+ #690. I'm a little short on knowledge on how to configure the kernel to disable LED blinking, I've had a look but not found something I'm confident is right, if you could point me in the right direction that would be great. (Just to note the actual Wifi PCB doesn't have an LED on it, so don't know if it could be trying to flash it constantly and failing? Then again the Ralink doesn't and that's fine)

[MartynGough]

I've just tired it on a later version of Wheezy, 3.12.30+ #717 and still see the 25%+ extra cpu load with either the firmware-atheros package and the htc_9271.fw lib I created installed, (still when no wifi network set up).

[olerem]

If you can at least compile firmware by yourself, then you can try regression test. Use "git bisect" to find which commit introduced this regression. Since no body of us have access to RPi, every thing is in your hands.

Please, google for "git bisect".

[kmai]

I'm having this issue with kernel 3.18.5-2 on architecture armv6l.

The CPU load in my RPi is increased due to a lot of messages being written to journald (check pastebin http://paste.osmc.io/xacamihigi )

I managed to join a wireless network, get an ip address, but the system becomes really unstable.

How can I debug the problem?

[olerem]

your kernel don't have "ath9k_htc: do not use bulk on EP3 and EP4" patch.

[kmai]

Where can I find this patch? I know how to compile code but I'm not really familiar with git. Do I need to patch my kernel or patch the firmware?

This is what I found of your authory regarding EP3/4 http://lists.infradead.org/pipermail/ath9k_htc_fw/2013-August/000336.html

[olerem]

It is kernel patch, it is included in all recent kernels. Or you can try wireless backports.

[olerem]

See https://www.kernel.org/

[kmai]

I'm running 3.18, patch is already applied and experiencing the same issue

[olerem]

Hm.. you are right. This string from your dmesg means that driver is trying to use transfer type != 3 (interrupt): usb 1-1.2.2: BOGUS urb xfer, pipe 1 != type 3

If this patches are included, then this error should not happen. If this patch is really included, then some thing strange is happening here. According to the dmesg, there are more devices attached to this usb port. Do your wifi adapter get enough power? According to my tests, after firmware load power consumptions jumps from ~30mA to ~190mA. Usual usb port is limited to 500mA.

[kmai]

I built a powered hub using a standard usb hub with +5v and GND connected to a 1800mA supply and data lines going to usb. no more devices connected and device has it's own power supply. gnd is also connected to usb

[olerem]

If you have source code of you kernel, can you check if content of this patchs is really included? http://lists.infradead.org/pipermail/ath9k_htc_fw/2013-August/000336.html

[olerem]

Here is updated list with usb related issues: https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues

feedbacks are welcome! :D

[cjensenius]

If you have source code of you kernel, can you check if content of this patchs is really included? http://lists.infradead.org/pipermail/ath9k_htc_fw/2013-August/000336.html

I have checked the latest rPi kernel sources (4.1.21) and the patch is included (https://github.com/raspberrypi/linux/commit/2b721118b7821107757eb1d37af4b60e877b27e7) I've built the latest firmware from master on the rPi 1, and can confirm the issue is still present.

root@raspberrypi ~/open-ath9k-htc-firmware # uname -r
4.1.21+

root@raspberrypi ~ # ls -lt /lib/firmware
total 1044
-rw-r--r-- 1 root root  51008 Apr 10 16:36 htc_9271.fw
-rw-r--r-- 1 root root  72812 Apr 10 16:36 htc_7010.fw
drwxr-xr-x 2 root root   4096 Apr  8 17:16 RTL8192SU

root@raspberrypi ~/open-ath9k-htc-firmware # git status
On branch master
Your branch is up-to-date with 'origin/master'.

[  154.111354] ------------[ cut here ]------------
[  154.111420] WARNING: CPU: 0 PID: 6 at drivers/usb/core/urb.c:450 usb_submit_urb+0x1d8/0x4dc()
[  154.111436] usb 1-1.2.2: BOGUS urb xfer, pipe 1 != type 3
[  154.111446] Modules linked in: arc4 ath9k_htc ath9k_common ath9k_hw ath mac80211 cfg80211 rfkill xt_conntrack iptable_filter ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat xt_tcpudp iptable_nat nf_nat_ipv4 nf_nat ip_tables x_tables 8192cu snd_soc_bcm2708_i2s regmap_mmio snd_soc_core snd_compress snd_pcm_dmaengine nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack snd_bcm2835 snd_pcm snd_timer snd fuse ipv6
[  154.111576] CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G        W       4.1.21+ #872
[  154.111588] Hardware name: BCM2708
[  154.111678] Workqueue: phy1 ath9k_led_work [ath9k_htc]
[  154.111737] [<c0016cb8>] (unwind_backtrace) from [<c0013b80>] (show_stack+0x20/0x24)
[  154.111771] [<c0013b80>] (show_stack) from [<c053409c>] (dump_stack+0x20/0x28)
[  154.111807] [<c053409c>] (dump_stack) from [<c0023af0>] (warn_slowpath_common+0x8c/0xc4)
[  154.111833] [<c0023af0>] (warn_slowpath_common) from [<c0023b68>] (warn_slowpath_fmt+0x40/0x48)
[  154.111861] [<c0023b68>] (warn_slowpath_fmt) from [<c03abb10>] (usb_submit_urb+0x1d8/0x4dc)
[  154.111909] [<c03abb10>] (usb_submit_urb) from [<bf4501fc>] (hif_usb_send+0xc4/0x3dc [ath9k_htc])
[  154.111961] [<bf4501fc>] (hif_usb_send [ath9k_htc]) from [<bf44e070>] (htc_issue_send.constprop.0+0x70/0x74 [ath9k_htc])
[  154.112004] [<bf44e070>] (htc_issue_send.constprop.0 [ath9k_htc]) from [<bf44e43c>] (htc_send_epid+0x20/0x24 [ath9k_htc])
[  154.112052] [<bf44e43c>] (htc_send_epid [ath9k_htc]) from [<bf450c10>] (ath9k_wmi_cmd+0x130/0x1c8 [ath9k_htc])
[  154.112124] [<bf450c10>] (ath9k_wmi_cmd [ath9k_htc]) from [<bf4569fc>] (ath9k_reg_rmw+0x80/0x16c [ath9k_htc])
[  154.112450] [<bf4569fc>] (ath9k_reg_rmw [ath9k_htc]) from [<bf3c3ca4>] (ath9k_hw_set_gpio+0x80/0xdc [ath9k_hw])
[  154.112625] [<bf3c3ca4>] (ath9k_hw_set_gpio [ath9k_hw]) from [<bf45775c>] (ath9k_led_work+0x34/0x38 [ath9k_htc])
[  154.112693] [<bf45775c>] (ath9k_led_work [ath9k_htc]) from [<c0038e5c>] (process_one_work+0x11c/0x394)
[  154.112720] [<c0038e5c>] (process_one_work) from [<c0039114>] (worker_thread+0x40/0x4d4)
[  154.112749] [<c0039114>] (worker_thread) from [<c003e5bc>] (kthread+0xdc/0xf8)
[  154.112782] [<c003e5bc>] (kthread) from [<c000f858>] (ret_from_fork+0x14/0x3c)
[  154.112797] ---[ end trace ef86924b5ba2492a ]---

[ralferoo]

I also seem to be having the same issue on a Pi Zero with the latest Raspbian image:

[ 1878.259617] ------------[ cut here ]------------
[ 1878.259675] WARNING: CPU: 0 PID: 739 at drivers/usb/core/urb.c:449 usb_submit_urb+0x1d8/0x4d8()
[ 1878.259688] usb 1-1.2: BOGUS urb xfer, pipe 1 != type 3
[ 1878.259697] Modules linked in: arc4 ath9k_htc ath9k_common ath9k_hw ath mac80211 cfg80211 rfkill cdc_ether r8152 snd_bcm2835 snd_pcm snd_timer snd bcm2835_gpiomem bcm2835_wdt uio_pdrv_genirq uio ipv6
[ 1878.259769] CPU: 0 PID: 739 Comm: kworker/u2:1 Tainted: G        W       4.4.11+ #888
[ 1878.259779] Hardware name: BCM2708
[ 1878.259870] Workqueue: phy0 ath9k_led_work [ath9k_htc]
[ 1878.259919] [<c0016c9c>] (unwind_backtrace) from [<c0013c20>] (show_stack+0x20/0x24)
[ 1878.259945] [<c0013c20>] (show_stack) from [<c02e32dc>] (dump_stack+0x20/0x28)
[ 1878.259972] [<c02e32dc>] (dump_stack) from [<c0021e54>] (warn_slowpath_common+0x8c/0xc4)
[ 1878.259995] [<c0021e54>] (warn_slowpath_common) from [<c0021ecc>] (warn_slowpath_fmt+0x40/0x48)
[ 1878.260020] [<c0021ecc>] (warn_slowpath_fmt) from [<c03d4314>] (usb_submit_urb+0x1d8/0x4d8)
[ 1878.260085] [<c03d4314>] (usb_submit_urb) from [<bf313568>] (hif_usb_send+0xc4/0x3e4 [ath9k_htc])
[ 1878.260172] [<bf313568>] (hif_usb_send [ath9k_htc]) from [<bf311070>] (htc_issue_send.constprop.0+0x70/0x74 [ath9k_htc])
[ 1878.260252] [<bf311070>] (htc_issue_send.constprop.0 [ath9k_htc]) from [<bf311444>] (htc_send_epid+0x20/0x24 [ath9k_htc])
[ 1878.260331] [<bf311444>] (htc_send_epid [ath9k_htc]) from [<bf313f84>] (ath9k_wmi_cmd+0x130/0x1cc [ath9k_htc])
[ 1878.260650] [<bf313f84>] (ath9k_wmi_cmd [ath9k_htc]) from [<bf319cb8>] (ath9k_regwrite+0x70/0xe8 [ath9k_htc])
[ 1878.260741] [<bf319cb8>] (ath9k_regwrite [ath9k_htc]) from [<bf319edc>] (ath9k_reg_rmw+0x130/0x16c [ath9k_htc])
[ 1878.261130] [<bf319edc>] (ath9k_reg_rmw [ath9k_htc]) from [<bf285cb8>] (ath9k_hw_set_gpio+0x80/0xdc [ath9k_hw])
[ 1878.261394] [<bf285cb8>] (ath9k_hw_set_gpio [ath9k_hw]) from [<bf31aba8>] (ath9k_led_work+0x34/0x38 [ath9k_htc])
[ 1878.261469] [<bf31aba8>] (ath9k_led_work [ath9k_htc]) from [<c00374d0>] (process_one_work+0x11c/0x39c)
[ 1878.261547] [<c00374d0>] (process_one_work) from [<c0037790>] (worker_thread+0x40/0x4d0)
[ 1878.261575] [<c0037790>] (worker_thread) from [<c003d114>] (kthread+0xdc/0xf8)
[ 1878.261602] [<c003d114>] (kthread) from [<c000f8a8>] (ret_from_fork+0x14/0x2c)
[ 1878.261615] ---[ end trace 4ceb90b571acf05e ]---
root@raspberrypi:/home/pi# uname -a
Linux raspberrypi 4.4.11+ #888 Mon May 23 20:02:58 BST 2016 armv6l GNU/Linux
root@raspberrypi:/home/pi# ls -lt /lib/firmware/htc_*
-rw-r--r-- 1 root root 72992 Feb 25 05:46 /lib/firmware/htc_7010.fw
-rw-r--r-- 1 root root 51272 Feb 25 05:46 /lib/firmware/htc_9271.fw
root@raspberrypi:/home/pi#

[olerem]

On discussion with one embedded developer i noticed that with current FW and Kernel this issue can happen only if usb device was inited in Full Speed USB1 mode. Not in the High Speed USB2 mode.

Now i need help to understand. Why is it in USB 1 mode?!

[olerem]

https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md http://www.laptop-junction.com/toast/content/usb-20-high-speed-hell-device-can-perform-faster https://ludovicrousseau.blogspot.de/2014/04/usb-issues-with-raspberry-pi.html http://discuss.outernet.is/t/raspberry-pi-usb-unstable-issue-with-external-usb-devices/1743

From what i see, looks like lots of embedded device indeed will forced ath9k_htc to start in FullSpeed mode. This means, we need to add FullSpeed support to:

• firmware: patch usb descriptor. May be more work is needed
• Linux kernel: add usb reset sequence, rework device initialisation
• do lots of HW testing.

This is a lot of work. Every one is welcome if you haw time to start working on this.