Re: Not work ATH (AR9285) after update

Ok, so.

On 23 July 2013 07:12, Andrey Fesenko <f0andrey_at_gmail.com> wrote:

>>> i'm horrible news, after update my notebook not nave wi-fi :(
>>> full update system, build and install world and kernel.

What did it used to run?


>>> Jul 23 15:34:27 x220 wpa_supplicant[2572]: wlan0: Failed to initiate AP scan
>>> Jul 23 15:34:29 x220 wpa_supplicant[2572]: ioctl[SIOCS80211, op=103,
>>> val=0, arg_len=128]: Operation now in progress
>>> Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: didn't finish
>>> after 10 iterations
>>> Jul 23 15:34:29 x220 kernel: ath0: ath_reset_grablock: warning,
>>> recursive reset path!

Your previous log indicated multiple copies of wpa_supplicant. That
should be investigated.

> Not,
> root_at_x220:~ # ps -A | grep wpa
>  671  -  Ss   0:00.73 /usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_suppl
>
> Start, or restart work standart
> # /etc/rc.d/netif restart
> this scheme work fine ~year or half year.
> Although of course the chip AR9285 is not very stable, especially in
> combination with some AP.

That's why I updated the support. It's much more stable now. Except if
you somehow get >1 wpa_supplicant instances running.

>
> Hm... intresting boot messages
> ...
> Jul 23 17:47:06 x220 kernel: ath0: <Atheros 9285> mem
> 0xf2400000-0xf240ffff irq 17 at device 0.0 on pci3
> Jul 23 17:47:06 x220 kernel: [ath] AR9285 Main LNA config: LNA1
> Jul 23 17:47:06 x220 kernel: [ath] AR9285 Alt LNA config: LNA2
> Jul 23 17:47:06 x220 kernel: [ath] LNA diversity disabled, Diversity disabled
> Jul 23 17:47:06 x220 kernel: ath0: [HT] enabling HT modes
> Jul 23 17:47:06 x220 kernel: ath0: [HT] 1 stream STBC receive enabled
> Jul 23 17:47:06 x220 kernel: ath0: [HT] 1 RX streams; 1 TX streams
> Jul 23 17:47:06 x220 kernel: ath0: AR9285 mac 192.2 RF5133 phy 14.0
> Jul 23 17:47:06 x220 kernel: ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0

x220 - is this a thinkpad? Or what kind of laptop is it?

Have you added this card in yourself? Are both antennas connected?

The EEPROM settings disable diversity. Thus, the transmit path is
always LNA1, the receive path is always LNA1. So, it should at least
have that antenna connected.

> old log
> Jul  2 13:30:02 x220 kernel: ath0: <Atheros 9285> mem
> 0xf2400000-0xf240ffff irq 17 at device 0.0 on pci3
> Jul  2 13:30:02 x220 kernel: ath0: [HT] enabling HT modes
> Jul  2 13:30:02 x220 kernel: ath0: [HT] 1 stream STBC receive enabled
> Jul  2 13:30:02 x220 kernel: ath0: [HT] 1 RX streams; 1 TX streams
> Jul  2 13:30:02 x220 kernel: ath0: AR9285 mac 192.2 RF5133 phy 14.0
> Jul  2 13:30:02 x220 kernel: ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0

What's the svn revision on that?

> and old style reconnect
> Jul  2 14:15:33 x220 wpa_supplicant[516]: CTRL-EVENT-DISCONNECTED
> bssid=58:6d:8f:fa:d9:50 reason=0
> Jul  2 14:15:33 x220 kernel: wlan0: link state changed to DOWN
> Jul  2 14:15:35 x220 wpa_supplicant[516]: Trying to associate with
> 58:6d:8f:fa:d9:50 (SSID='hometest' freq=2472 MHz)
> Jul  2 14:15:35 x220 wpa_supplicant[516]: Associated with 58:6d:8f:fa:d9:50
> Jul  2 14:15:35 x220 kernel: wlan0: link state changed to UP
> Jul  2 14:15:35 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27
> ts_finaltsi=0
> Jul  2 14:15:35 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1
> ts_status 0x0
> Jul  2 14:15:35 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27
> ts_finaltsi=0
> Jul  2 14:15:35 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1
> ts_status 0x0
> Jul  2 14:15:35 x220 wpa_supplicant[516]: WPA: Key negotiation
> completed with 58:6d:8f:fa:d9:50 [PTK=CCMP GTK=CCMP]
> Jul  2 14:15:35 x220 wpa_supplicant[516]: CTRL-EVENT-CONNECTED -
> Connection to 58:6d:8f:fa:d9:50 completed (reauth) [id=0 id_str=]
> Jul  2 14:15:35 x220 dhclient: New IP Address (wlan0): 192.168.1.22
> Jul  2 14:15:35 x220 dhclient: New Subnet Mask (wlan0): 255.255.255.0
> Jul  2 14:15:35 x220 dhclient: New Broadcast Address (wlan0): 192.168.1.255
> Jul  2 14:15:35 x220 dhclient: New Routers (wlan0): 192.168.1.1
> Jul  2 14:19:57 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27
> ts_finaltsi=0
> Jul  2 14:19:57 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1
> ts_status 0x0
> Jul  2 14:20:00 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27
> ts_finaltsi=0
> Jul  2 14:20:00 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1
> ts_status 0x0
> Jul  2 14:22:21 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27
> ts_finaltsi=0
> Jul  2 14:22:21 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1
> ts_status 0x0
> Jul  2 15:10:13 x220 wpa_supplicant[516]: WPA: Group rekeying
> completed with 58:6d:8f:fa:d9:50 [GTK=CCMP]
> Jul  2 15:10:13 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27
> ts_finaltsi=0
> Jul  2 15:10:13 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1
> ts_status 0x0
> Jul  2 15:12:00 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27
> ts_finaltsi=0
> Jul  2 15:12:00 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1
> ts_status 0x0
> Jul  2 15:12:13 x220 kernel: ath0: ath_rate_tx_complete: ts_rate=27
> ts_finaltsi=0
> Jul  2 15:12:13 x220 kernel: ath0: bad series0 hwrate 0x1b, tries 1
> ts_status 0x0

These are likely because your AP disables the low CCK rates, but the
rate control code currently tries to transmit on them. It succeeds in
transmitting, but then it gets angry because that rate isn't in said
rate table negotiated with the AP.

Please try it manually:

# ifconfig wlan0 destroy
# pkill -9 wpa_supplicant
# ifconfig wlan0 create wlandev ath0
# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf &

.. and see what happens.

Thanks,



-adrian