Arch Linux

steve_95

Member

Registered: 2013-05-03

Posts: 8

Can't hard block/unblock Atheros wi-fi card

Hi, since kernel version 3.6 I have a problem regarding my wi fi card: if I deactivate it from another OS I can't re-activate it, and when it is working I can't power it fully off (the led remains lighted).
So, it seems the hard block/unblock is impossible; if I use the key shortcut it's only soft-blocked (or unblocked).
I have a Asus eeepc 1215b, but the problem exists also on two others similar laptops; the involved card are the AR9285 and the AR9485 on mini pci-e.
The last working kernel was 3.5.6-1.

lsmod | grep -i ath9k

ath9k                 100775  0 
ath9k_common            2096  1 ath9k
ath9k_hw              359706  2 ath9k_common,ath9k
ath                    15393  3 ath9k_common,ath9k,ath9k_hw
mac80211              463393  1 ath9k
cfg80211              430289  3 ath,ath9k,mac80211

dmesg | grep -i wlp1s0

[    3.433341] systemd-udevd[122]: renamed network interface wlan0 to wlp1s0
[    4.616939] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
[   13.931956] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
[   14.146404] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
[   17.410188] wlp1s0: authenticate with 00:24:89:1c:3f:93
[   17.422892] wlp1s0: send auth to 00:24:89:1c:3f:93 (try 1/3)
[   17.425189] wlp1s0: authenticated
[   17.425506] wlp1s0: associate with 00:24:89:1c:3f:93 (try 1/3)
[   17.428675] wlp1s0: RX AssocResp from 00:24:89:1c:3f:93 (capab=0x411 status=0 aid=1)
[   17.428851] wlp1s0: associated
[   17.428937] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready

Thansk and sorry for any mistake 

WonderWoofy

Member

From: Los Gatos, CA

Registered: 2012-05-19

Posts: 8,414

Re: Can't hard block/unblock Atheros wi-fi card

You made no mention of actually trying rfkill.  Has that been attempted?

steve_95

Member

Registered: 2013-05-03

Posts: 8

Re: Can't hard block/unblock Atheros wi-fi card

Sorry, yes, I tried with rfkill...
-if the card is locked (from another OS), with "rfkill unblock all" the card remains blocked
-if the card is active, with "rfkill block all" the card doesn't hard block

WonderWoofy

Member

From: Los Gatos, CA

Registered: 2012-05-19

Posts: 8,414

Re: Can't hard block/unblock Atheros wi-fi card

So you are saying that if you boot into the other OS, and reenable the card, then come back to Arch Linux, it will work again?

Also, just for the sake of trying to gather all information, what is the "other OS"?  Is it that super expensive problem laden one from redmond?

steve_95

Member

Registered: 2013-05-03

Posts: 8

Re: Can't hard block/unblock Atheros wi-fi card

So you are saying that if you boot into the other OS, and reenable the card, then come back to Arch Linux, it will work again?

Also, just for the sake of trying to gather all information, what is the "other OS"?  Is it that super expensive problem laden one from redmond?

Respect for you LOL
Yes I mean that, but also Ubuntu with a kernel before 3.6 (12.04 works, 13.04 with linux 3.8.0 doesn't)

steve_95

Member

Registered: 2013-05-03

Posts: 8

Re: Can't hard block/unblock Atheros wi-fi card

I checked on kernel.org changelogs between 3.5.6 and 3.6.11, and I found 4 references for ath9k:

1) The most interesting: https://www.kernel.org/pub/linux/kernel … eLog-3.6.1

ath9k: Disable ASPM only for AR9285
Currently, ASPM is disabled for all WLAN+BT combo chipsets when BTCOEX is enabled. This is incorrect since the workaround is required only for WB195, which is a AR9285+AR3011 combo solution. Fix this by checking for the HW version when enabling the workaround.

From wikipedia: "ASPM is a power management protocol used to manage PCI Express-based serial link devices as links become less active over time. It is normally used on laptops and other mobile Internet devices to extend battery life."
Maybe is this? BTW, the problem exists also with the AR9485...

2) https://www.kernel.org/pub/linux/kernel … eLog-3.6.3

ath9k: use ieee80211_free_txskb
   
    commit 249ee72249140fe5b9adc988f97298f0aa5db2fc upstream.
   
    Using ieee80211_free_txskb for tx frames is required, since mac80211 clones
    skbs for which socket tx status is requested.

3) https://www.kernel.org/pub/linux/kernel … eLog-3.6.5

Revert "ath9k_hw: Updated AR9003 tx gain table for 5GHz"
   
    commit 73b26df5fa1a6245d6fc982362518b620bc7c2fe upstream.
   
    This reverts commit a240dc7b3c7463bd60cf0a9b2a90f52f78aae0fd.
   
    This commit is reducing tx power by at least 10 db on some devices,
    e.g. the Buffalo WZR-HP-G450H.

4) https://www.kernel.org/pub/linux/kernel … eLog-3.6.7

cfg80211: fix antenna gain handling
   
    commit c4a9fafc77a5318f5ed26c509bbcddf03e18c201 upstream.
   
    No driver initializes chan->max_antenna_gain to something sensible, and
    the only place where it is being used right now is inside ath9k. This
    leads to ath9k potentially using less tx power than it can use, which can
    decrease performance/range in some rare cases.
   
    Rather than going through every single driver, this patch initializes
    chan->orig_mag in wiphy_register(), ignoring whatever value the driver
    left in there. If a driver for some reason wishes to limit it independent
    from regulatory rulesets, it can do so internally.

Any idea?