Search Linux Wireless

Re: ath9k and power management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Apr 18, 2009 at 1:27 AM, Davide Pesavento <davidepesa@xxxxxxxxx> wrote:
> On Fri, Mar 27, 2009 at 16:27, Davide Pesavento <davidepesa@xxxxxxxxx> wrote:
>> Hello,
>>
>> I'm running a 2.6.29-wl kernel, using ath9k and wpa_supplicant 0.6.9
>> (with -Dnl80211).
>> Enabling power management when connected (i.e. 'iwconfig wlan0 power
>> on'), causes the currently established connection to break and the
>> machine is no longer able to reconnect to the AP. Right after enabling
>> pm, dmesg says:
>>
>> [ 2625.513233] wlan0: beacon loss from AP 00:1b:2f:35:14:78 - sending
>> probe request
>> [ 2627.513210] wlan0: no probe response from AP 00:1b:2f:35:14:78 -
>> disassociating
>> [ 2627.514430] phy0: Removed STA 00:1b:2f:35:14:78
>> [ 2627.543407] phy0: Destroyed STA 00:1b:2f:35:14:78
>> [ 2776.444279] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [ 2776.659861] wlan0: deauthenticating by local choice (reason=3)
>> [ 2776.831004] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>>
>> When I turn power management off again, wpa_supplicant is able to
>> reconnect just fine.
>> Is this a known bug? If ath9k doesn't support power management
>> properly, wouldn't it be better to reject the userspace request right
>> away?
>>
>
> This is still unfixed on latest git (2.6.30-rc2-wl). The symptoms are
> exactly the same as reported above.

This is the power save mechanism used in ath9k:
An interrupt is triggered just 4ms before the target beacon time
so that the chip can wake up and receive the beacons. In all the
latest chipsets like AR92XX, this is working fine.I wonder why
AR54XX has some problems related to that.
A quick look into the debug logs shows me that this wake up interrupt
(TIM_TIMER) stops triggering after some time which leads to beacon
loss and disconnection.
Although there is an option of autosleep(in latest versions) where hw can
wakeup automatically and receive beacon instead of a sw trigger call,
the hw may sleep for a longer duration(sometimes)  and we may need to
have some timer mechanism to verify if the hw is hung or not.
I did not have much time to look into this somewhat older chipsets and
I will try to debug more if I manage to get some free time.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux