PROBLEMA Wi-fi Atheros non si blocca/sblocca

[steve_95]

Ciao, in conseguenza a quanto detto qui apro questa discussione...
in pratica, a partire dalla versione 3.6 del kernel, la scheda wifi non è accessibile a livello hardware: se è stata spenta da un altro OS non si riaccende (rfkill la dà come hard blocked), mentre se è attiva non si spegne (rimane bloccata solo via sw, ma non è effettivamente spenta, come testimonia anche il led).
Il pc è il mio EEEpc 1215B, ma anche altri due modelli simili di due miei amici hanno lo stesso identico problema.
Le schede coinvolte sono due: AR9285 e AR9485, entrambe su mini pci-e.

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

Grazie ;)

EDIT: ho trovato qualche discussione di problemi simili riscontrati usando la nuova Ubuntu 13.04 (che usa il kernel 3.8)...ma per ora nessuna soluzione

 

[davethecipo]

Ripeto ciò che ho detto nell'altra discussione, se nessuno è in grado di darti una mano...ti devi divertire con il kernel bisecting

 

[steve_95]

Ripeto ciò che ho detto nell'altra discussione, se nessuno è in grado di darti una mano...ti devi divertire con il kernel bisecting

Riguardo alle versioni stabili usate da Arch, so che l'ultima ok era la 3.5.6-1, mentre quella immediatamente successiva (che era già una 3.6.xx) presentava il problema...bisogna vedere cosa c'è stato di mezzo, ora dò un occhio ;)
Intanto ho postato anche sul forum di Arch...vediamo che mi dicono là :)

 

[davethecipo]

Buona fortuna...anche io ho il tuo stesso problema, su scheda diversa. Nel mio caso però penso che il problema sia del modulo dell_wmi o dell_laptop

 

[steve_95]

Ho controllato direttamente su kernel.org i changelog fra la 3.5.6 e la 3.6.11 (l'ultima 3.6, con cui sicuramente c'era già il problema), e ho trovato 4 cose riguardanti ath9k:

1) Il più interessante: https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-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.

Da 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."
:sisi:...che siamo sulla buona strada? Però, si riferisce alla sola AR9285, mentre i problemi ci sono anche sulla AR9485 :boh:

2) https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-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/v3.x/ChangeLog-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/v3.x/ChangeLog-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.

:sisi:

- - - Updated - - -

Nessuno sa dirmi nulla? @wine non dovevi passare di qua? :lol:
:ok:

 

[wine]

O si scusami, sono impegnato anche con altro e mi era passato di mente.

Innanzitutto, l'ultima del ramo 3.5 è la 3.5.7, prova a vedere se anche con quella funzionava il tutto (solitamente al kernel fanno anche modifiche di questo tipo se ritenute bug).

E proverei anche il 3.9, dato che ormai dovrebbe arrivare in [core] praticamente a ore.

Nel caso, visto che a quanto pare la cosa è non facilmente risolvibile senza toccare i sorgenti, farei una segnalazione sia al team di Arch che ai dev del kernel (ovviamente controlla se non ce ne è già una).