Ubuntu

ath5k should be loaded with nohwcrypt parameter

Reported by Lucious Daniels Jr on 2010-04-21
78
This bug affects 14 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned

Bug Description

After a lengthy thread, I was able to get to the bottom of my poor web browsing performance in Lucid Beta 2. Basically I kept gettng the "Waiting for <insert site here>..." status on whatever browser I used. Pages would load after a really long time, or sometimes not at all. My laptop uses the AR2413 chipset, which utilizes the ath5k wireless module. We were able to find that loading the module with the nohwcrypt parameter fixed my problem:

sudo modprobe ath5k nohwcrypt

psyke83 from the forums showed me how to automatically load the ath5k module with the said parameter on reboot.

sudo sh -c "echo 'options ath5k nohwcrypt' >/etc/modprobe.d/custom-wireless.conf"

Hopefully this information can help others with similar hardware. Whether this should be a default for Lucid, I am not sure because I don't know if it affects everyone the same. The thread is pasted below for full details of everything I tried to find the solution.

http://ubuntuforums.org/showthread.php?t=1441818

affects: ubuntu → linux (Ubuntu)
summary: - Slow browsing. "Waiting for <site>" Ath5k parameter
+ ath5k should be loaded with nohwcrypt parameter
tags: added: lucid
Jeremy Foshee (jeremyfoshee) wrote :

Hi Lucious,

Please be sure to confirm this issue exists with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/releases/ . If the issue remains, please run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 568090

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-kernel-logs
tags: added: needs-upstream-testing
tags: added: kj-triage
Changed in linux (Ubuntu):
status: New → Incomplete
Lucious Daniels Jr (ladmatic) wrote :

I can confirm this issue exists in the latest development release, release candidate fully updated. I also updated to kernel 2.6.34 rc5 and the problem is still present. I am attempting to attach the debug info from the command you gave me, but unfortunately with the problem re-enabled I cannot connect to launchpad. I will keep trying though.

Changed in linux (Ubuntu):
status: Incomplete → Triaged
importance: Undecided → Medium
Download full text (22.2 KiB)

I also had this problem
and even with this fix listed here i'm stillsuffering slow network traffic

lspci
06:03.0 Ethernet controller: Atheros Communications Inc. AR2413 802.11bg NIC (rev 01)

PING google.com (209.85.229.99) 56(84) bytes of data.
64 bytes from ww-in-f99.1e100.net (209.85.229.99): icmp_seq=1 ttl=53 time=1346 ms
64 bytes from ww-in-f99.1e100.net (209.85.229.99): icmp_seq=2 ttl=53 time=993 ms
64 bytes from ww-in-f99.1e100.net (209.85.229.99): icmp_seq=3 ttl=53 time=1260 ms
64 bytes from ww-in-f99.1e100.net (209.85.229.99): icmp_seq=4 ttl=53 time=2434 ms
64 bytes from ww-in-f99.1e100.net (209.85.229.99): icmp_seq=5 ttl=53 time=2167 ms

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 8355ms
rtt min/avg/max/mdev = 993.965/1640.458/2434.358/558.028 ms, pipe 2

xpd259@Sputnik:~$ sudo iwlist scanning
lo Interface doesn't support scanning.

eth1 Interface doesn't support scanning.

wlan0 Scan completed :
          Cell 01 - Address: 00:18:4D:64:52:1C
                    Channel:6
                    Frequency:2.437 GHz (Channel 6)
                    Quality=50/70 Signal level=-60 dBm
                    Encryption key:on
                    ESSID:"dick n lyds"
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s
                    Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
                    Mode:Master
                    Extra:tsf=0000000f22667d81
                    Extra: Last beacon: 204ms ago
                    IE: Unknown: 000B6469636B206E206C796473
                    IE: Unknown: 010882848B0C12961824
                    IE: Unknown: 030106
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : TKIP
                        Authentication Suites (1) : PSK
                    IE: Unknown: 2A0100
                    IE: Unknown: 32043048606C
                    IE: Unknown: DD180050F2020101050003A4000027A4000042435E0062322F00
                    IE: Unknown: DD0900037F01010024FF7F
          Cell 02 - Address: 00:1C:DF:85:BF:DB
                    Channel:6
                    Frequency:2.437 GHz (Channel 6)
                    Quality=33/70 Signal level=-77 dBm
                    Encryption key:on
                    ESSID:"aaaaaaaaa"
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
                    Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
                              36 Mb/s; 48 Mb/s; 54 Mb/s
                    Mode:Master
                    Extra:tsf=0000004132c8a1f2
                    Extra: Last beacon: 648ms ago
                    IE: Unknown: 0009616161616161616161
                    IE: Unknown: 010482848B96
                    IE: Unknown: 030106
                    IE: Unknown: 070A474220010D14010D1400
                    IE: Unknown: 2A0100
                    IE: Unknown: 32080C1218243048606C
                    IE: Unknown: DD070050F202000100
                    IE: Unknown: 050400010000
          Cell 03 - Address: 00:18:F6:93:5C:13
                    Channel:7
...

Nigel Pugh (nigel-pugh) wrote :

I had the same issue right through lucid development. Adding the nohwcrypt option fixed it for me too.
Thanks for getting to the bottom of this Lucious and psyke83... it destroyed my wifi on lucid for a long time!

Toshiba A100-259

uname -a
Linux nigel-laptop 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 22:02:19 UTC 2010 i686 GNU/Linux

lspci
00:00.0 Host bridge: ATI Technologies Inc Device 5a31 (rev 01)
00:01.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge
00:12.0 IDE interface: ATI Technologies Inc IXP SB400 Serial ATA Controller (rev 80)
00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (rev 80)
00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (rev 80)
00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller (rev 80)
00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 82)
00:14.1 IDE interface: ATI Technologies Inc IXP SB400 IDE Controller (rev 80)
00:14.2 Audio device: ATI Technologies Inc IXP SB4x0 High Definition Audio Controller (rev 01)
00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80)
00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge (rev 80)
01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200M]
02:04.0 Ethernet controller: Atheros Communications Inc. AR2413 802.11bg NIC (rev 01)
02:06.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller (rev 01)
02:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
02:0a.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)

Peter Ford (peter.ford) wrote :

A couple more threads of people affected:
My own post - http://ubuntuforums.org/showthread.php?p=9604832&posted=1#post9604832
Another one - http://www.uluga.ubuntuforums.org/showthread.php?p=8384942#post8384942

Thanks for the workaround Lucious :-)

Jan-Olof Lindqvist (jan-olof) wrote :

Looks like this solved the slow wireless problem for my father on his Toshiba Satellite L30 - 105. Usually he was not able to access webpages with Chrome/Firefox but somehow it worked fine in simpler browsers like Links/Lynx.

09:04.0 Ethernet controller: Atheros Communications Inc. AR2413 802.11bg NIC (rev 01)
 Subsystem: Askey Computer Corp. Device 7094
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 22
 Region 0: Memory at c0110000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: <access denied>
 Kernel driver in use: ath5k
 Kernel modules: ath5k

Neldon A (iamthened) wrote :

Installed Lucid a week ago. Got all the updates I know of and the issue still remains.

Thanks Lucious!

Musaraigne (musaraigne) wrote :

I still have the same problem on a fully updated Maverick (installed from scratch from the 10.10 CD).

Before learning about this nohwcrypt workaround I did a bit of investigation and found the following: The cause of the high and unpredictable latencies is that packets are dropped depending on their size. According to my tests, packet sizes of the form
  size = 128*k + 81 + m
or
  size = 128*k + 105 + m
for any k>=2 and 0<=m<=7

are dropped randomly in 90-95% of the cases. Conversely, all other packet sizes work fine.

You can see for yourself if this is true on your system:
  ping -M do -s 596 www.google.com
should result in 90% packet loss (because 624 = 128*4 + 105 + 7; the 28 byte difference comes from network headers added by ping)
while
  ping -M do -s 597 www.google.com
should result in negligible packet loss.

Hopefully this makes the problem easier to reproduce and analyze!

There are three different workarounds that can solve the problem on my system:
- use the nohwcrypt parameter
- limit the MTU to a value low enough to avoid problematic packet sizes (such as 330 bytes), with "sudo ifconfig wlan0 mtu 330"
- use the madwifi drivers instead of ath5k

tifff (horst-fiedler) wrote :

Installed Maverick a week ago on Siemens Amilo pa 1510 using Atheros AR2413, had same problem: ssh completly unuseable due to packet losses. Thanks Lucious and Musaraigne for very detailed reproducable identification.

Musaraigne (musaraigne) wrote :

What exactly is holding this bug back?

The bug is 1 year old, has a low-impact temporary fix, has been reproduced many times (including duplicates like bug 565892), and makes wifi almost entirely unusable to anyone unaware of the workaround.

Musaraigne (musaraigne) wrote :

Kernel developers are looking into it and may need some testing or feedback:
https://bugzilla.kernel.org/show_bug.cgi?id=30342

I can't do testing myself as the computer on which I encountered the bug was not mine.

sml (sml) wrote :

The bug I reported, while similar, is not the same as this bug. That one (#565892) is fixed by 2.6.33, as noted in my report.

I tried the ping tests you described in the kernel bug and wasn't able to reproduce your issues. If you have any other tests which can show this bug, please let me know.

Also note that I don't have mount with any special parameters like nohwcrypt. It just works out of the box on my WPA2 (CCMP-
PSK) 802.11G network.

sml (sml) wrote :

Not mount - modprobe.

Musaraigne (musaraigne) wrote :

Oh yes, my bad, it wasn't a duplicate. However I think that most of the respondents probably suffered from this bug and not the one you described. If you think your bug still needs to be fixed on 2.6.32 feel free to unmark it as a duplicate.

It's very interesting that you don't have the problem with an AR2413, though. I don't have other tests aside from trying other packet sizes, but if you use this computer daily you would quickly notice sluggish performance if you were affected by the problem.

Perhaps the "Subsystem:" line of lspci -vnn could be an indicator:

(scottl, unaffected by the bug)
06:01.0 Ethernet controller [0200]: Atheros Communications Inc. AR2413 802.11bg NIC [168c:001a] (rev 01)
 Subsystem: Atheros Communications Inc. Device [168c:2052]

(Jan-Olof Lindqvist and exogenetic, likely affected by the bug)
09:04.0 Ethernet controller [0200]: Atheros Communications Inc. AR2413 802.11bg NIC [168c:001a] (rev 01)
 Subsystem: Askey Computer Corp. Device [144f:7094]

That's a small sample size, it would be nice to see if other AR2413 users have the same pattern.

Danny Wood (danwood76) wrote :

I can confirm this is still a bug for the latest maverick.
The nohwcrypt option solves it for me.

lspci -vnn
09:04.0 Ethernet controller [0200]: Atheros Communications Inc. AR2413 802.11bg NIC [168c:001a] (rev 01)
 Subsystem: Askey Computer Corp. Device [144f:7094]
 Flags: bus master, medium devsel, latency 168, IRQ 22
 Memory at c0110000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: [44] Power Management version 2
 Kernel driver in use: ath5k
 Kernel modules: ath5k

I am affected and have the Askey subsystem, maybe that is an indicator?

Danny Wood (danwood76) wrote :

I meant confirmed in Natty (11.04) not maverick!

Same problem with a Toshiba L30-105 (AR2413) since karmic.
same in Natty (11.04)
loading the module with the nohwcrypt parameter fixed the problem
THANKS!

Nick Kossifidis (mickflemm) wrote :

Hello all, I'm one of ath5k's maintainers and would like to thank you for your reports, especially Musaraigne for finding the problematic length range. Sorry for the delay on this bug but we still can't reproduce it on our own AR2413 cards, based also on reports from other users I think we can safely narrow it down to cards made by Askey.

So can you please all verify that this bug is only present on cards made by Askey ? Check out your lspci -v output and let me know.

Again thanks a lot for your reports

It apparently does NOT affect the system I used when I ticked the "This bug affects me too" and I cannot reproduce it (anymore).

The Acer Aspire 5100-3949 uses an AR2413 manufactured by AMBIT:
"Subsystem: AMBIT Microsystem Corp. Device [1468:0418]" IS NOT AFFECTED BY THIS BUG.

I may have subscribed here before I realized I was seeing Bug #767192 which has been fixed now.

Lucious Daniels Jr (ladmatic) wrote :

My card is indeed an Askey.

02:04.0 Ethernet controller: Atheros Communications Inc. AR2413 802.11bg NIC (rev 01)
 Subsystem: Askey Computer Corp. Device 7094
 Flags: bus master, medium devsel, latency 168, IRQ 20
 Memory at c0200000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: <access denied>
 Kernel driver in use: ath5k

Erik (lnchpd-elaan) wrote :

My card is an Askey too:

02:04.0 Ethernet controller [0200]: Atheros Communications Inc. AR2413 802.11bg NIC [168c:001a] (rev 01)
 Subsystem: Askey Computer Corp. Device [144f:7094]
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 17
 Region 0: Memory at c0200000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: <access denied>
 Kernel driver in use: ath5k
 Kernel modules: ath5k

In a Toshiba Sattellite M40-277.

Adam Lyall (magicmyth) wrote :

I've just installed Ubuntu on a old Toshiba Satellite Pro M50 with a ath5k and its exhibiting this problem as well. The workaround with nohwcrypt solves the problem. I won't be able to test this laptop much longer but thought it worth mentioning it too is an Askey built card:

04:02.0 Ethernet controller: Atheros Communications Inc. AR2413/AR2414 Wireless Network Adapter [AR5005G(S) 802.11bg] (rev 01)
 Subsystem: Askey Computer Corp. Device 7094
 Flags: bus master, medium devsel, latency 168, IRQ 9
 Memory at c0200000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: [44] Power Management version 2
 Kernel driver in use: ath5k
 Kernel modules: ath5k

brott (gatorstudent20) wrote :

This still seems to be an issue in Precise. At least as of Beta 1. How do we get this option enabled by default?

Erik (lnchpd-elaan) wrote :

I guess we don't get it to be hardware encryption disabled by default, as the nohwcrypt parameter is only needed on Askey devices using the ath5k driver, and not on other devices that use the ath5k driver.

Maybe the driver could be made to detect the manufacturer and disable hardware encryption if it is Askey? I don't know enough about the driver to know whether that is possible. Who does?

Gustavo Azambuja (gazambuja) wrote :

Excelent, in my Ubuntu 12.04 beta work like charm!

lspci:
06:01.0 Ethernet controller: Atheros Communications Inc. AR2413/AR2414 Wireless Network Adapter [AR5005G(S) 802.11bg] (rev 01)

Lucious Daniels Jr, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Changed in linux (Ubuntu):
status: Triaged → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.