Hi,
I have built today a linux-next (next-20101201) kernel which includes
wireless-next-2.6 up to master-2010-11-30.
>From tig utility:
2010-11-30 15:33 Stanislaw Gruszka [wireless-next-2.6] iwlagn: fix
microcode error on 4965
[main] 61790c5f3c5f158821821a00797d94504531839f - commit 1929 of 226338 (0%)
Unfortunately, my wlan network connection is totally unstable.
$ dmesg | grep "RX AssocResp" | wc -l
216
The block looks like this:
[ 4436.504059] ieee80211 phy0: wlan0: No probe response from AP
00:04:0e:e4:00:3d after 500ms, disconnecting.
[ 4436.504490] cfg80211: Calling CRDA to update world regulatory domain
[ 4440.677020] wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
[ 4440.679096] wlan0: authenticated
[ 4440.679158] wlan0: associate with 00:04:0e:e4:00:3d (try 1)
[ 4440.684667] wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411
status=0 aid=1)
[ 4440.684673] wlan0: associated
My wlan device is an ath5k:
$ lspci -nnvv | grep "Ethernet controller" | grep -i ath
02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
802.11abg NIC [168c:1014] (rev 01)
Any idea what's wrong? (Just speculating on the last patch-set from Nick...)
How can I help to dig into this problem?
Debug-session with wpasupplicant? Which kernel-parameters (debug) to
be considered/set?
Kind Regards,
- Sedat -
On Wed, Dec 1, 2010 at 11:05 PM, Nick Kossifidis <[email protected]> wrote:
> 2010/12/1 Sedat Dilek <[email protected]>:
>> Hi,
>>
>> I have built today a linux-next (next-20101201) kernel which includes
>> wireless-next-2.6 up to master-2010-11-30.
>>
>> From tig utility:
>> 2010-11-30 15:33 Stanislaw Gruszka [wireless-next-2.6] iwlagn: fix
>> microcode error on 4965
>> [main] 61790c5f3c5f158821821a00797d94504531839f - commit 1929 of 226338 (0%)
>>
>> Unfortunately, my wlan network connection is totally unstable.
>>
>> $ dmesg | grep "RX AssocResp" | wc -l
>> 216
>>
>> The block looks like this:
>> [ 4436.504059] ieee80211 phy0: wlan0: No probe response from AP
>> 00:04:0e:e4:00:3d after 500ms, disconnecting.
>> [ 4436.504490] cfg80211: Calling CRDA to update world regulatory domain
>> [ 4440.677020] wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
>> [ 4440.679096] wlan0: authenticated
>> [ 4440.679158] wlan0: associate with 00:04:0e:e4:00:3d (try 1)
>> [ 4440.684667] wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411
>> status=0 aid=1)
>> [ 4440.684673] wlan0: associated
>>
>> My wlan device is an ath5k:
>>
>> $ lspci -nnvv | grep "Ethernet controller" | grep -i ath
>> 02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
>> 802.11abg NIC [168c:1014] (rev 01)
>>
>> Any idea what's wrong? (Just speculating on the last patch-set from Nick...)
>> How can I help to dig into this problem?
>> Debug-session with wpasupplicant? Which kernel-parameters (debug) to
>> be considered/set?
>>
>> Kind Regards,
>> - Sedat -
>>
>
> That's weird I tested all patches for connectivity + iperf, maybe
> something else also went on the tree that results such behavior...
>
> 1) Are you using NetworkManager ? If so disable it and connect manually.
> 2) Can you disable encryption on your AP and see if it works without it ?
> 3) Try and enable/disable hw encryption with nohwcrypt module parameter.
> 4) What's your signal strength/rate when you connect to the AP ?
>
> --
> GPG ID: 0xD21DB2DB
> As you read this post global entropy rises. Have Fun ;-)
> Nick
>
Tested my usual ath5k setup also with a self-debianized wpasupplicant
0.7.3 (build against libnl-2.0):
# dpkg -l | grep wpa | cut -c-80
ii wpagui 0.7.3-1~dileks.1
ii wpasupplicant 0.7.3-1~dileks.1
Same error-messages:
Dec 2 00:24:53 tbox kernel: [10319.504083] ieee80211 phy0: wlan0: No
probe response from AP 00:04:0e:e4:00:3d after 500ms, disconnecting.
Dec 2 00:24:53 tbox kernel: [10319.504946] cfg80211: Calling CRDA to
update world regulatory domain
Dec 2 00:24:58 tbox wpa_supplicant[6955]: Trying to associate with
00:04:0e:e4:00:3d (SSID='myCastle-WLAN WPA (Wireless LAN)' freq=2442
MHz)
Dec 2 00:24:58 tbox kernel: [10323.677183] wlan0: authenticate with
00:04:0e:e4:00:3d (try 1)
Dec 2 00:24:58 tbox kernel: [10323.680850] wlan0: authenticated
Dec 2 00:24:58 tbox kernel: [10323.680907] wlan0: associate with
00:04:0e:e4:00:3d (try 1)
Dec 2 00:24:58 tbox kernel: [10323.687204] wlan0: RX AssocResp from
00:04:0e:e4:00:3d (capab=0x411 status=0 aid=1)
Dec 2 00:24:58 tbox kernel: [10323.687215] wlan0: associated
Dec 2 00:24:58 tbox wpa_supplicant[6955]: Associated with 00:04:0e:e4:00:3d
Dec 2 00:24:58 tbox wpa_supplicant[6955]: WPA: Key negotiation
completed with 00:04:0e:e4:00:3d [PTK=CCMP GTK=TKIP]
Dec 2 00:24:58 tbox wpa_supplicant[6955]: CTRL-EVENT-CONNECTED -
Connection to 00:04:0e:e4:00:3d completed (reauth) [id=0 id_str=]
- Sedat -
On Thu, Dec 2, 2010 at 1:17 PM, Sedat Dilek <[email protected]> wrote:
> On Wed, Dec 1, 2010 at 11:09 AM, Sedat Dilek <[email protected]> wrote:
>> Hi,
>>
>> I have built today a linux-next (next-20101201) kernel which includes
>> wireless-next-2.6 up to master-2010-11-30.
>>
> [...]
>> Unfortunately, my wlan network connection is totally unstable.
> [...]
>> My wlan device is an ath5k:
>>
>> $ lspci -nnvv | grep "Ethernet controller" | grep -i ath
>> 02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
>> 802.11abg NIC [168c:1014] (rev 01)
>>
>> Any idea what's wrong? (Just speculating on the last patch-set from Nick...)
>
> So it is definitely not Nick's patchset causing the troubles here.
> I have built compat-wireless-2010-11-30 which does not contain this
> ath5 patchset.
>
> $ grep ath5k compat-wireless-2010-11-29_compat-wireless-2010-11-30.diff
>
> $ grep ath5k compat-wireless-2010-11-30_compat-wireless-2010-12-01.diff | wc -l
> 1229
>
> # modinfo ath5k | grep filename
> filename:
> /lib/modules/2.6.37-rc4-686/updates/drivers/net/wireless/ath/ath5k/ath5k.ko
>
> So I try backwards the c-w-2.6 tarballs and report again.
>
I am very very sorry to say this was a false "positive" (or negative?).
After 1st reboot and trying to restart networking, things look
different with c-w (2010-11-30):
# /etc/init.d/networking start
Configuring network interfaces...ioctl[SIOCGIFFLAGS]: No such device
Could not get interface 'wlan0' flags
ioctl[SIOCSIWPMKSA]: No such device
ioctl[SIOCSIWMODE]: No such device
Could not configure driver to use managed mode
ioctl[SIOCGIWRANGE]: No such device
ioctl[SIOCGIWMODE]: No such device
ioctl[SIOCSIWAP]: No such device
ioctl[SIOCSIWESSID]: No such device
ioctl[SIOCGIFINDEX]: No such device
ioctl[SIOCSIWENCODEEXT]: No such device
ioctl[SIOCSIWENCODE]: No such device
ioctl[SIOCSIWENCODEEXT]: No such device
ioctl[SIOCSIWENCODE]: No such device
ioctl[SIOCSIWENCODEEXT]: No such device
ioctl[SIOCSIWENCODE]: No such device
ioctl[SIOCSIWENCODEEXT]: No such device
ioctl[SIOCSIWENCODE]: No such device
ioctl[SIOCGIWMODE]: No such device
ioctl[SIOCSIWAP]: No such device
ioctl[SIOCSIWESSID]: No such device
ioctl[SIOCGIFFLAGS]: No such device
wpa_supplicant: /sbin/wpa_supplicant daemon failed to start
run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return code 1
SIOCSIFADDR: No such device
wlan0: ERROR while getting interface flags: No such device
SIOCSIFNETMASK: No such device
SIOCSIFBRDADDR: No such device
wlan0: ERROR while getting interface flags: No such device
wlan0: ERROR while getting interface flags: No such device
Failed to bring up wlan0.
done.
What is really working stable is compat-wireless-2.6.37-rc3-1
(confirmed after several reboots). I will stay on this as I need a
reliable network connection.
- Sedat -
On Fri, Dec 3, 2010 at 7:31 AM, Nick Kossifidis <[email protected]> wrote:
> 2010/12/3 Sedat Dilek <[email protected]>:
>> On Fri, Dec 3, 2010 at 5:16 AM, Nick Kossifidis <[email protected]> wrote:
>>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>>>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>>>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>>>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>>>>>> 2010/12/2 Sedat Dilek <[email protected]>:
>>>>>>>>> On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
>>>>>>>>>> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I have built today a linux-next (next-20101201) kernel which includes
>>>>>>>>>>> wireless-next-2.6 up to master-2010-11-30.
>>>>>>>>> [...]
>>>>>>>>>>> Unfortunately, my wlan network connection is totally unstable.
>>>>>>>>> [...]
>>>>>>>>>> 1.) For identification of the chipset, please:
>>>>>>>>>> dmesg |grep "ath5.*chip"
>>>>>>>>>>
>>>>>>>>>> 2.) Is there a problem when you don't use encryption?
>>>>>>>>>>
>>>>>>>>>> 3.) git bisect might help track it down.
>>>>>>>>>>
>>>>>>>>>> bruno
>>>>>>>>>
>>>>>>>>> OK, I did not a "classic" git-bisect, I created from linux-next
>>>>>>>>> (next-20101202) GIT tree a revert-ath5k patchset (30 in total).
>>>>>>>>>
>>>>>>>>> [1] VERY GOOD: Revertiing all 30 patches
>>>>>>>>>
>>>>>>>>> ...leads to a stable system.
>>>>>>>>>
>>>>>>>>> [2] REDUCED DISCONNECTIONS DROPS: Reverting 0001..0008
>>>>>>>>>
>>>>>>>>> This stabilizes the system, but... listening to a radio
>>>>>>>>> broadcast-stream with VLC is a pain in the ass... permanent audio
>>>>>>>>> dropouts. I had only 2 disconnections in the first 10mins when system
>>>>>>>>> was up (normally I can see disconnects after loggin into my KDE
>>>>>>>>> desktop).
>>>>>>>>>
>>>>>>>>> [3] GOOD AUDIO STREAMING: Reverting 0001..0014
>>>>>>>>>
>>>>>>>>> This is just fine, system like I am used to.
>>>>>>>>>
>>>>>>>>> [4] CONCLUSION
>>>>>>>>>
>>>>>>>>> So I played a bit with my revert-patchset.
>>>>>>>>>
>>>>>>>>> Reverting 0001..0008 + a refreshed v2 of
>>>>>>>>> 0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch (patch attached) is
>>>>>>>>> doing the job here.
>>>>>>>>>
>>>>>>>>> Having a closer look into 0008 (parts of
>>>>>>>>> drivers/net/wireless/ath/ath5k/reset.c):
>>>>>>>>>
>>>>>>>>> $ grep AR5212 patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>>>>>> - if (ah->ah_version == AR5K_AR5212)
>>>>>>>>> + * On AR5212 TSF is almost preserved across a
>>>>>>>>> - * On AR5212 TSF is almost preserved across a
>>>>>>>>> + if (ah->ah_version == AR5K_AR5212) {
>>>>>>>>> - if (ah->ah_version == AR5K_AR5212 &&
>>>>>>>>>
>>>>>>>>> As I mentionned I have a AR5212 wlan device!
>>>>>>>>> What to do with that parts?
>>>>>>>>> Any idea?
>>>>>>>>>
>>>>>>>>> Kind Regards,
>>>>>>>>> - Sedat -
>>>>>>>>>
>>>>>>>>> P.S.: I have added a list containing all commit-ids (chronological)
>>>>>>>>> and a script how I reverted (documenting for myself).
>>>>>>>>>
>>>>>>>>> $ ls patches/revert-wireless-patches/00*.patch
>>>>>>>>> patches/revert-wireless-patches/0001-Revert-ath5k-Set-turbo-bit-on-rf-bank-2.patch
>>>>>>>>> patches/revert-wireless-patches/0002-Revert-ath5k-Clean-up-turbo-mode-initvals-rfregs.patch
>>>>>>>>> patches/revert-wireless-patches/0003-Revert-ath5k-Cleanup-turbo-channel-flags.patch
>>>>>>>>> patches/revert-wireless-patches/0004-Revert-ath5k-Use-correct-clock-when-setting-ofdm-tim.patch
>>>>>>>>> patches/revert-wireless-patches/0005-Revert-ath5k-Skip-tx-power-setting-on-AR5210-for-now.patch
>>>>>>>>> patches/revert-wireless-patches/0006-Revert-ath5k-Tweak-phy-activate-to-rx-start-delay-ba.patch
>>>>>>>>> patches/revert-wireless-patches/0007-Revert-ath5k-No-need-to-save-restore-staid-flags-on-.patch
>>>>>>>>> patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>>>>>> patches/revert-wireless-patches/0009-Revert-ath5k-Skip-powertable-setting-when-we-are-on-.patch
>>>>>>>>> patches/revert-wireless-patches/0010-Revert-ath5k-Update-PLL-programming-for-turbo-half-q.patch
>>>>>>>>> patches/revert-wireless-patches/0011-Revert-ath5k-Update-spur-mitigation-filter-for-turbo.patch
>>>>>>>>> patches/revert-wireless-patches/0012-Revert-ath5k-Tweak-power-detector-delays-on-RF5111-R.patch
>>>>>>>>> patches/revert-wireless-patches/0013-Revert-ath5k-Always-set-IFS-intervals-on-reset.patch
>>>>>>>>> patches/revert-wireless-patches/0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch
>>>>>>>>> patches/revert-wireless-patches/0015-Revert-ath5k-Set-all-IFS-intervals-not-just-slot-tim.patch
>>>>>>>>> patches/revert-wireless-patches/0016-Revert-ath5k-Extend-rate_duration.patch
>>>>>>>>> patches/revert-wireless-patches/0017-Revert-ath5k-Extend-get_default_sifs-slot_time.patch
>>>>>>>>> patches/revert-wireless-patches/0018-Revert-ath5k-Move-tx-retries-setting-outside-reset_t.patch
>>>>>>>>> patches/revert-wireless-patches/0019-Revert-ath5k-Increase-PHY-settling-parameters-for-tu.patch
>>>>>>>>> patches/revert-wireless-patches/0020-Revert-ath5k-Small-cleanup-on-tweak_initvals.patch
>>>>>>>>> patches/revert-wireless-patches/0021-Revert-ath5k-Put-core-clock-initialization-on-a-new-.patch
>>>>>>>>> patches/revert-wireless-patches/0022-Revert-ath5k-Add-new-field-on-ath5k_hw-to-track-band.patch
>>>>>>>>> patches/revert-wireless-patches/0023-Revert-ath5k-Use-new-function-to-stop-beacon-queue.patch
>>>>>>>>> patches/revert-wireless-patches/0024-Revert-ath5k-Check-RXE-when-setting-RXDP.patch
>>>>>>>>> patches/revert-wireless-patches/0025-Revert-ath5k-Use-DCU-early-termination-correctly.patch
>>>>>>>>> patches/revert-wireless-patches/0026-Revert-ath5k-Debug-DMA-timeouts.patch
>>>>>>>>> patches/revert-wireless-patches/0027-Revert-ath5k-Use-new-dma_stop-function-on-base.c.patch
>>>>>>>>> patches/revert-wireless-patches/0028-Revert-ath5k-Stop-PCU-on-reset.patch
>>>>>>>>> patches/revert-wireless-patches/0029-Revert-ath5k-Add-new-function-to-stop-rx-tx-DMA.patch
>>>>>>>>> patches/revert-wireless-patches/0030-Revert-ath5k-Reset-cleanup-and-generic-cleanup.patch
>>>>>>>>>
>>>>>>>>
>>>>>>>> OK this doesn't make any sense, based on your logs you have an
>>>>>>>> AR5212+RF5111+RF2111 combination, synth-only channel change (0008) is
>>>>>>>> only executed on AR2413 and AR5413 so you don't even run that code,
>>>>>>>> setting turbo flag on DCU (0014) is also unrelated since we never
>>>>>>>> enable turbo mode and if we did you wouldn't be able to receive
>>>>>>>> anything non-turbo.
>>>>>>>>
>>>>>>>> I am going to test 2 cards like yours a CM6 and an older one from
>>>>>>>> Atheros and come back to you ASAP...
>>>>>>>>
>>>>>>>
>>>>>>> I just reproduced it on a CM6 and a CM9 (AR5212 + RF5112), problem
>>>>>>> occurs when card is idle (no traffic) that's why my automated test
>>>>>>> didn't catch it I can still run iperf after connecting and leave it
>>>>>>> running without problems, when traffic stops it soon gets
>>>>>>> disconnected. I suspect it's something related to IFS timings/ACK
>>>>>>> timeout (0013 on your reverted series), maybe Jonathan Guerin was
>>>>>>> correct about ACK timeout...
>>>>>>>
>>>>>>> I'll try something and come back to you with code ;-)
>>>>>>>
>>>>>>> Thanks for reporting !
>>>>>>>
>>>>>>
>>>>>> Nope, it's PHY related and only affects RF5111/RF5112, AR2413 and
>>>>>> above work fine...
>>>>>>
>>>>>
>>>>> Got it, patch on the way...
>>>>>
>>>>
>>>> First the problem is with patch 22 (0009), we still need to write the
>>>> power table on hw, that fixes transmission and my CM9 works just fine
>>>> after that. Now my 2 RF5111 based cards seem to also have some problem
>>>> with stuck tx queues, after some time of fine operation (nearly
>>>> 28Mbits with iperf). It might be a hw failure or something but i want
>>>> to try and debug this further in case there is something i can do to
>>>> fix it. I also found some other things, eg. i report RX dma stop
>>>> failure when i shouldn't etc. Anyway back to debuging ;-)
>>>>
>>>>
>>>> --
>>>> GPG ID: 0xD21DB2DB
>>>> As you read this post global entropy rises. Have Fun ;-)
>>>> Nick
>>>>
>>>
>>> Done, works fine for me now, check it out ;-)
>>>
>>> --
>>> GPG ID: 0xD21DB2DB
>>> As you read this post global entropy rises. Have Fun ;-)
>>> Nick
>>>
>>
>> Hi Nick,
>>
>> I have applied the 6 patches you sent to linux-wireless list.
>>
>> $ cd $HOME/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none
>>
>> $ cat .pc/applied-patches
>> from_nkossifidis/1-6-ath5k-Always-write-tx-powertable-on-hw.patch
>> from_nkossifidis/2-6-ath5k-Always-free-tx-buffers-before-reset.patch
>> from_nkossifidis/3-6-ath5k-Disable-ANI-during-reset.patch
>> from_nkossifidis/4-6-ath5k-Fix-reporting-of-RX-dma-stop-failure.patch
>> from_nkossifidis/5-6-ath5k-Update-version-string.patch
>> from_nkossifidis/6-6-ath5k-Include-tx-ack-reporting-on-hw-flags.patch
>>
>> No more disconnects and no more audio-dropouts when listening to live-radio.
>> A big big big thank you!
>>
>> Shall I add to each of your patches a "Tested-by: Sedat Dilek
>> <[email protected]>?
>>
>> Kind Regards,
>> - Sedat -
>>
>
> Sure, again thanks a lot for reporting this and testing ;-)
>
> --
> GPG ID: 0xD21DB2DB
> As you read this post global entropy rises. Have Fun ;-)
> Nick
>
Hi Nick,
any idea why I lost my pci aliases when doing a modinfo ath5k?
# modinfo ath5k
filename:
/lib/modules/2.6.37-rc4-686/kernel/drivers/net/wireless/ath/ath5k/ath5k.ko
version: 0.7.0
license: Dual BSD/GPL
description: Support for 5xxx series of Atheros 802.11 wireless LAN cards.
author: Nick Kossifidis
author: Jiri Slaby
srcversion: FB060B275A94A4A185E9AC7
depends: mac80211,cfg80211,ath
vermagic: 2.6.37-rc4-686 SMP mod_unload modversions 686
parm: debug:uint
parm: nohwcrypt:Disable hardware encryption. (bool)
parm: all_channels:Expose all channels the device can use. (bool)
Versus (paste provided by someone from IRC)
filename:
/lib/modules/2.6.32-5-openvz-amd64/kernel/drivers/net/wireless/ath/ath5k/ath5k.ko
version: 0.6.0 (EXPERIMENTAL)
license: Dual BSD/GPL
description: Support for 5xxx series of Atheros 802.11 wireless LAN cards.
author: Nick Kossifidis
author: Jiri Slaby
srcversion: 5A81CAB958F60B02DE47E18
alias: pci:v0000168Cd0000001Dsv*sd*bc*sc*i*
alias: pci:v0000168Cd0000001Csv*sd*bc*sc*i*
alias: pci:v0000168Cd0000001Bsv*sd*bc*sc*i*
alias: pci:v0000168Cd0000001Asv*sd*bc*sc*i*
alias: pci:v0000168Cd00000019sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000018sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000017sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000016sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000015sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000014sv*sd*bc*sc*i*
alias: pci:v0000168Cd00001014sv*sd*bc*sc*i*
alias: pci:v000010B7d00000013sv*sd*bc*sc*i*
alias: pci:v0000A727d00000013sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000013sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000012sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000011sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000007sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000207sv*sd*bc*sc*i*
depends: mac80211,led-class,cfg80211,ath
vermagic: 2.6.32-5-openvz-amd64 SMP mod_unload modversions
parm: nohwcrypt:Disable hardware encryption. (bool)
parm: all_channels:Expose all channels the device can use. (bool)
How do I re-create the aliases? depmod -a (did not help)?
Problem is on startup I have no wlan, I unload/reload ath5k
kernel-module and then start networking.
Uncool :-)
- Sedat -
On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
> Hi,
>
> I have built today a linux-next (next-20101201) kernel which includes
> wireless-next-2.6 up to master-2010-11-30.
>
> >From tig utility:
> 2010-11-30 15:33 Stanislaw Gruszka [wireless-next-2.6] iwlagn: fix
> microcode error on 4965
> [main] 61790c5f3c5f158821821a00797d94504531839f - commit 1929 of 226338
> (0%)
>
> Unfortunately, my wlan network connection is totally unstable.
>
> $ dmesg | grep "RX AssocResp" | wc -l
> 216
>
> The block looks like this:
> [ 4436.504059] ieee80211 phy0: wlan0: No probe response from AP
> 00:04:0e:e4:00:3d after 500ms, disconnecting.
> [ 4436.504490] cfg80211: Calling CRDA to update world regulatory domain
> [ 4440.677020] wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
> [ 4440.679096] wlan0: authenticated
> [ 4440.679158] wlan0: associate with 00:04:0e:e4:00:3d (try 1)
> [ 4440.684667] wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411
> status=0 aid=1)
> [ 4440.684673] wlan0: associated
>
> My wlan device is an ath5k:
>
> $ lspci -nnvv | grep "Ethernet controller" | grep -i ath
> 02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
> 802.11abg NIC [168c:1014] (rev 01)
>
> Any idea what's wrong? (Just speculating on the last patch-set from
> Nick...) How can I help to dig into this problem?
> Debug-session with wpasupplicant? Which kernel-parameters (debug) to
> be considered/set?
1.) For identification of the chipset, please:
dmesg |grep "ath5.*chip"
2.) Is there a problem when you don't use encryption?
3.) git bisect might help track it down.
bruno
2010/12/2 Sedat Dilek <[email protected]>:
> On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
>> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>>> Hi,
>>>
>>> I have built today a linux-next (next-20101201) kernel which includes
>>> wireless-next-2.6 up to master-2010-11-30.
> [...]
>>> Unfortunately, my wlan network connection is totally unstable.
> [...]
>> 1.) For identification of the chipset, please:
>> dmesg |grep "ath5.*chip"
>>
>> 2.) Is there a problem when you don't use encryption?
>>
>> 3.) git bisect might help track it down.
>>
>> bruno
>
> OK, I did not a "classic" git-bisect, I created from linux-next
> (next-20101202) GIT tree a revert-ath5k patchset (30 in total).
>
> [1] VERY GOOD: Revertiing all 30 patches
>
> ...leads to a stable system.
>
> [2] REDUCED DISCONNECTIONS DROPS: Reverting 0001..0008
>
> This stabilizes the system, but... listening to a radio
> broadcast-stream with VLC is a pain in the ass... permanent audio
> dropouts. I had only 2 disconnections in the first 10mins when system
> was up (normally I can see disconnects after loggin into my KDE
> desktop).
>
> [3] GOOD AUDIO STREAMING: Reverting 0001..0014
>
> This is just fine, system like I am used to.
>
> [4] CONCLUSION
>
> So I played a bit with my revert-patchset.
>
> Reverting 0001..0008 + a refreshed v2 of
> 0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch (patch attached) is
> doing the job here.
>
> Having a closer look into 0008 (parts of
> drivers/net/wireless/ath/ath5k/reset.c):
>
> $ grep AR5212 patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
> - if (ah->ah_version == AR5K_AR5212)
> + * On AR5212 TSF is almost preserved across a
> - * On AR5212 TSF is almost preserved across a
> + if (ah->ah_version == AR5K_AR5212) {
> - if (ah->ah_version == AR5K_AR5212 &&
>
> As I mentionned I have a AR5212 wlan device!
> What to do with that parts?
> Any idea?
>
> Kind Regards,
> - Sedat -
>
> P.S.: I have added a list containing all commit-ids (chronological)
> and a script how I reverted (documenting for myself).
>
> $ ls patches/revert-wireless-patches/00*.patch
> patches/revert-wireless-patches/0001-Revert-ath5k-Set-turbo-bit-on-rf-bank-2.patch
> patches/revert-wireless-patches/0002-Revert-ath5k-Clean-up-turbo-mode-initvals-rfregs.patch
> patches/revert-wireless-patches/0003-Revert-ath5k-Cleanup-turbo-channel-flags.patch
> patches/revert-wireless-patches/0004-Revert-ath5k-Use-correct-clock-when-setting-ofdm-tim.patch
> patches/revert-wireless-patches/0005-Revert-ath5k-Skip-tx-power-setting-on-AR5210-for-now.patch
> patches/revert-wireless-patches/0006-Revert-ath5k-Tweak-phy-activate-to-rx-start-delay-ba.patch
> patches/revert-wireless-patches/0007-Revert-ath5k-No-need-to-save-restore-staid-flags-on-.patch
> patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
> patches/revert-wireless-patches/0009-Revert-ath5k-Skip-powertable-setting-when-we-are-on-.patch
> patches/revert-wireless-patches/0010-Revert-ath5k-Update-PLL-programming-for-turbo-half-q.patch
> patches/revert-wireless-patches/0011-Revert-ath5k-Update-spur-mitigation-filter-for-turbo.patch
> patches/revert-wireless-patches/0012-Revert-ath5k-Tweak-power-detector-delays-on-RF5111-R.patch
> patches/revert-wireless-patches/0013-Revert-ath5k-Always-set-IFS-intervals-on-reset.patch
> patches/revert-wireless-patches/0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch
> patches/revert-wireless-patches/0015-Revert-ath5k-Set-all-IFS-intervals-not-just-slot-tim.patch
> patches/revert-wireless-patches/0016-Revert-ath5k-Extend-rate_duration.patch
> patches/revert-wireless-patches/0017-Revert-ath5k-Extend-get_default_sifs-slot_time.patch
> patches/revert-wireless-patches/0018-Revert-ath5k-Move-tx-retries-setting-outside-reset_t.patch
> patches/revert-wireless-patches/0019-Revert-ath5k-Increase-PHY-settling-parameters-for-tu.patch
> patches/revert-wireless-patches/0020-Revert-ath5k-Small-cleanup-on-tweak_initvals.patch
> patches/revert-wireless-patches/0021-Revert-ath5k-Put-core-clock-initialization-on-a-new-.patch
> patches/revert-wireless-patches/0022-Revert-ath5k-Add-new-field-on-ath5k_hw-to-track-band.patch
> patches/revert-wireless-patches/0023-Revert-ath5k-Use-new-function-to-stop-beacon-queue.patch
> patches/revert-wireless-patches/0024-Revert-ath5k-Check-RXE-when-setting-RXDP.patch
> patches/revert-wireless-patches/0025-Revert-ath5k-Use-DCU-early-termination-correctly.patch
> patches/revert-wireless-patches/0026-Revert-ath5k-Debug-DMA-timeouts.patch
> patches/revert-wireless-patches/0027-Revert-ath5k-Use-new-dma_stop-function-on-base.c.patch
> patches/revert-wireless-patches/0028-Revert-ath5k-Stop-PCU-on-reset.patch
> patches/revert-wireless-patches/0029-Revert-ath5k-Add-new-function-to-stop-rx-tx-DMA.patch
> patches/revert-wireless-patches/0030-Revert-ath5k-Reset-cleanup-and-generic-cleanup.patch
>
OK this doesn't make any sense, based on your logs you have an
AR5212+RF5111+RF2111 combination, synth-only channel change (0008) is
only executed on AR2413 and AR5413 so you don't even run that code,
setting turbo flag on DCU (0014) is also unrelated since we never
enable turbo mode and if we did you wouldn't be able to receive
anything non-turbo.
I am going to test 2 cards like yours a CM6 and an older one from
Atheros and come back to you ASAP...
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Wed, Dec 1, 2010 at 11:09 AM, Sedat Dilek <[email protected]> wrote:
> Hi,
>
> I have built today a linux-next (next-20101201) kernel which includes
> wireless-next-2.6 up to master-2010-11-30.
>
[...]
> Unfortunately, my wlan network connection is totally unstable.
[...]
> My wlan device is an ath5k:
>
> $ lspci -nnvv | grep "Ethernet controller" | grep -i ath
> 02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
> 802.11abg NIC [168c:1014] (rev 01)
>
> Any idea what's wrong? (Just speculating on the last patch-set from Nick...)
So it is definitely not Nick's patchset causing the troubles here.
I have built compat-wireless-2010-11-30 which does not contain this
ath5 patchset.
$ grep ath5k compat-wireless-2010-11-29_compat-wireless-2010-11-30.diff
$ grep ath5k compat-wireless-2010-11-30_compat-wireless-2010-12-01.diff | wc -l
1229
# modinfo ath5k | grep filename
filename:
/lib/modules/2.6.37-rc4-686/updates/drivers/net/wireless/ath/ath5k/ath5k.ko
So I try backwards the c-w-2.6 tarballs and report again.
- Sedat -
2010/12/3 Nick Kossifidis <[email protected]>:
> 2010/12/3 Nick Kossifidis <[email protected]>:
>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>> 2010/12/2 Sedat Dilek <[email protected]>:
>>>>> On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
>>>>>> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have built today a linux-next (next-20101201) kernel which includes
>>>>>>> wireless-next-2.6 up to master-2010-11-30.
>>>>> [...]
>>>>>>> Unfortunately, my wlan network connection is totally unstable.
>>>>> [...]
>>>>>> 1.) For identification of the chipset, please:
>>>>>> dmesg |grep "ath5.*chip"
>>>>>>
>>>>>> 2.) Is there a problem when you don't use encryption?
>>>>>>
>>>>>> 3.) git bisect might help track it down.
>>>>>>
>>>>>> bruno
>>>>>
>>>>> OK, I did not a "classic" git-bisect, I created from linux-next
>>>>> (next-20101202) GIT tree a revert-ath5k patchset (30 in total).
>>>>>
>>>>> [1] VERY GOOD: Revertiing all 30 patches
>>>>>
>>>>> ...leads to a stable system.
>>>>>
>>>>> [2] REDUCED DISCONNECTIONS DROPS: Reverting 0001..0008
>>>>>
>>>>> This stabilizes the system, but... listening to a radio
>>>>> broadcast-stream with VLC is a pain in the ass... permanent audio
>>>>> dropouts. I had only 2 disconnections in the first 10mins when system
>>>>> was up (normally I can see disconnects after loggin into my KDE
>>>>> desktop).
>>>>>
>>>>> [3] GOOD AUDIO STREAMING: Reverting 0001..0014
>>>>>
>>>>> This is just fine, system like I am used to.
>>>>>
>>>>> [4] CONCLUSION
>>>>>
>>>>> So I played a bit with my revert-patchset.
>>>>>
>>>>> Reverting 0001..0008 + a refreshed v2 of
>>>>> 0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch (patch attached) is
>>>>> doing the job here.
>>>>>
>>>>> Having a closer look into 0008 (parts of
>>>>> drivers/net/wireless/ath/ath5k/reset.c):
>>>>>
>>>>> $ grep AR5212 patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>> - if (ah->ah_version == AR5K_AR5212)
>>>>> + * On AR5212 TSF is almost preserved across a
>>>>> - * On AR5212 TSF is almost preserved across a
>>>>> + if (ah->ah_version == AR5K_AR5212) {
>>>>> - if (ah->ah_version == AR5K_AR5212 &&
>>>>>
>>>>> As I mentionned I have a AR5212 wlan device!
>>>>> What to do with that parts?
>>>>> Any idea?
>>>>>
>>>>> Kind Regards,
>>>>> - Sedat -
>>>>>
>>>>> P.S.: I have added a list containing all commit-ids (chronological)
>>>>> and a script how I reverted (documenting for myself).
>>>>>
>>>>> $ ls patches/revert-wireless-patches/00*.patch
>>>>> patches/revert-wireless-patches/0001-Revert-ath5k-Set-turbo-bit-on-rf-bank-2.patch
>>>>> patches/revert-wireless-patches/0002-Revert-ath5k-Clean-up-turbo-mode-initvals-rfregs.patch
>>>>> patches/revert-wireless-patches/0003-Revert-ath5k-Cleanup-turbo-channel-flags.patch
>>>>> patches/revert-wireless-patches/0004-Revert-ath5k-Use-correct-clock-when-setting-ofdm-tim.patch
>>>>> patches/revert-wireless-patches/0005-Revert-ath5k-Skip-tx-power-setting-on-AR5210-for-now.patch
>>>>> patches/revert-wireless-patches/0006-Revert-ath5k-Tweak-phy-activate-to-rx-start-delay-ba.patch
>>>>> patches/revert-wireless-patches/0007-Revert-ath5k-No-need-to-save-restore-staid-flags-on-.patch
>>>>> patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>> patches/revert-wireless-patches/0009-Revert-ath5k-Skip-powertable-setting-when-we-are-on-.patch
>>>>> patches/revert-wireless-patches/0010-Revert-ath5k-Update-PLL-programming-for-turbo-half-q.patch
>>>>> patches/revert-wireless-patches/0011-Revert-ath5k-Update-spur-mitigation-filter-for-turbo.patch
>>>>> patches/revert-wireless-patches/0012-Revert-ath5k-Tweak-power-detector-delays-on-RF5111-R.patch
>>>>> patches/revert-wireless-patches/0013-Revert-ath5k-Always-set-IFS-intervals-on-reset.patch
>>>>> patches/revert-wireless-patches/0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch
>>>>> patches/revert-wireless-patches/0015-Revert-ath5k-Set-all-IFS-intervals-not-just-slot-tim.patch
>>>>> patches/revert-wireless-patches/0016-Revert-ath5k-Extend-rate_duration.patch
>>>>> patches/revert-wireless-patches/0017-Revert-ath5k-Extend-get_default_sifs-slot_time.patch
>>>>> patches/revert-wireless-patches/0018-Revert-ath5k-Move-tx-retries-setting-outside-reset_t.patch
>>>>> patches/revert-wireless-patches/0019-Revert-ath5k-Increase-PHY-settling-parameters-for-tu.patch
>>>>> patches/revert-wireless-patches/0020-Revert-ath5k-Small-cleanup-on-tweak_initvals.patch
>>>>> patches/revert-wireless-patches/0021-Revert-ath5k-Put-core-clock-initialization-on-a-new-.patch
>>>>> patches/revert-wireless-patches/0022-Revert-ath5k-Add-new-field-on-ath5k_hw-to-track-band.patch
>>>>> patches/revert-wireless-patches/0023-Revert-ath5k-Use-new-function-to-stop-beacon-queue.patch
>>>>> patches/revert-wireless-patches/0024-Revert-ath5k-Check-RXE-when-setting-RXDP.patch
>>>>> patches/revert-wireless-patches/0025-Revert-ath5k-Use-DCU-early-termination-correctly.patch
>>>>> patches/revert-wireless-patches/0026-Revert-ath5k-Debug-DMA-timeouts.patch
>>>>> patches/revert-wireless-patches/0027-Revert-ath5k-Use-new-dma_stop-function-on-base.c.patch
>>>>> patches/revert-wireless-patches/0028-Revert-ath5k-Stop-PCU-on-reset.patch
>>>>> patches/revert-wireless-patches/0029-Revert-ath5k-Add-new-function-to-stop-rx-tx-DMA.patch
>>>>> patches/revert-wireless-patches/0030-Revert-ath5k-Reset-cleanup-and-generic-cleanup.patch
>>>>>
>>>>
>>>> OK this doesn't make any sense, based on your logs you have an
>>>> AR5212+RF5111+RF2111 combination, synth-only channel change (0008) is
>>>> only executed on AR2413 and AR5413 so you don't even run that code,
>>>> setting turbo flag on DCU (0014) is also unrelated since we never
>>>> enable turbo mode and if we did you wouldn't be able to receive
>>>> anything non-turbo.
>>>>
>>>> I am going to test 2 cards like yours a CM6 and an older one from
>>>> Atheros and come back to you ASAP...
>>>>
>>>
>>> I just reproduced it on a CM6 and a CM9 (AR5212 + RF5112), problem
>>> occurs when card is idle (no traffic) that's why my automated test
>>> didn't catch it I can still run iperf after connecting and leave it
>>> running without problems, when traffic stops it soon gets
>>> disconnected. I suspect it's something related to IFS timings/ACK
>>> timeout (0013 on your reverted series), maybe Jonathan Guerin was
>>> correct about ACK timeout...
>>>
>>> I'll try something and come back to you with code ;-)
>>>
>>> Thanks for reporting !
>>>
>>
>> Nope, it's PHY related and only affects RF5111/RF5112, AR2413 and
>> above work fine...
>>
>
> Got it, patch on the way...
>
First the problem is with patch 22 (0009), we still need to write the
power table on hw, that fixes transmission and my CM9 works just fine
after that. Now my 2 RF5111 based cards seem to also have some problem
with stuck tx queues, after some time of fine operation (nearly
28Mbits with iperf). It might be a hw failure or something but i want
to try and debug this further in case there is something i can do to
fix it. I also found some other things, eg. i report RX dma stop
failure when i shouldn't etc. Anyway back to debuging ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>> Hi,
>>
>> I have built today a linux-next (next-20101201) kernel which includes
>> wireless-next-2.6 up to master-2010-11-30.
>>
>> >From tig utility:
>> 2010-11-30 15:33 Stanislaw Gruszka [wireless-next-2.6] iwlagn: fix
>> microcode error on 4965
>> [main] 61790c5f3c5f158821821a00797d94504531839f - commit 1929 of 226338
>> (0%)
>>
>> Unfortunately, my wlan network connection is totally unstable.
>>
>> $ dmesg | grep "RX AssocResp" | wc -l
>> 216
>>
>> The block looks like this:
>> [ 4436.504059] ieee80211 phy0: wlan0: No probe response from AP
>> 00:04:0e:e4:00:3d after 500ms, disconnecting.
>> [ 4436.504490] cfg80211: Calling CRDA to update world regulatory domain
>> [ 4440.677020] wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
>> [ 4440.679096] wlan0: authenticated
>> [ 4440.679158] wlan0: associate with 00:04:0e:e4:00:3d (try 1)
>> [ 4440.684667] wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411
>> status=0 aid=1)
>> [ 4440.684673] wlan0: associated
>>
>> My wlan device is an ath5k:
>>
>> $ lspci -nnvv | grep "Ethernet controller" | grep -i ath
>> 02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
>> 802.11abg NIC [168c:1014] (rev 01)
>>
>> Any idea what's wrong? (Just speculating on the last patch-set from
>> Nick...) How can I help to dig into this problem?
>> Debug-session with wpasupplicant? Which kernel-parameters (debug) to
>> be considered/set?
>
> 1.) For identification of the chipset, please:
> dmesg |grep "ath5.*chip"
>
> 2.) Is there a problem when you don't use encryption?
>
> 3.) git bisect might help track it down.
>
> bruno
>
When does it happen?
Normal daily usage of Internet-ing... + kernel build with -j5
(Pentium-M, 1G RAM)...
I have set now as extra (just rebuilding):
CONFIG_ATH_DEBUG=y
CONFIG_ATH5K_DEBUG=y
# egrep 'Dec 1 09:38' /var/log/syslog | egrep -i 'ath|80211|wlan'
Dec 1 09:38:40 tbox kernel: [ 6.919633] cfg80211: Calling CRDA to
update world regulatory domain
Dec 1 09:38:40 tbox kernel: [ 7.401522] ath5k 0000:02:02.0: PCI
INT A -> Link[LNKC] -> GSI 11 (level, low) -> IRQ 11
Dec 1 09:38:40 tbox kernel: [ 7.401677] ath5k 0000:02:02.0:
registered as 'phy0'
Dec 1 09:38:40 tbox kernel: [ 7.689793] ath: EEPROM regdomain: 0x61
Dec 1 09:38:40 tbox kernel: [ 7.689797] ath: EEPROM indicates we
should expect a direct regpair map
Dec 1 09:38:40 tbox kernel: [ 7.689803] ath: Country alpha2 being used: 00
Dec 1 09:38:40 tbox kernel: [ 7.689805] ath: Regpair used: 0x61
Dec 1 09:38:40 tbox kernel: [ 8.232093] ieee80211 phy0: Selected
rate control algorithm 'minstrel_ht'
Dec 1 09:38:40 tbox kernel: [ 8.233067] Registered led device:
ath5k-phy0::rx
Dec 1 09:38:40 tbox kernel: [ 8.233106] Registered led device:
ath5k-phy0::tx
Dec 1 09:38:40 tbox kernel: [ 8.233119] ath5k phy0: Atheros AR5212
chip found (MAC: 0x56, PHY: 0x41)
Dec 1 09:38:40 tbox kernel: [ 8.233165] ath5k phy0: RF5111 5GHz
radio found (0x17)
Dec 1 09:38:40 tbox kernel: [ 8.233202] ath5k phy0: RF2111 2GHz
radio found (0x23)
Dec 1 09:38:41 tbox kernel: [ 16.753896] ADDRCONF(NETDEV_UP):
wlan0: link is not ready
Dec 1 09:38:42 tbox wpa_supplicant[972]: Trying to associate with
00:04:0e:e4:00:3d (SSID='myCastle-WLAN WPA (Wireless LAN)' freq=2442
MHz)
Dec 1 09:38:42 tbox kernel: [ 21.967986] wlan0: authenticate with
00:04:0e:e4:00:3d (try 1)
Dec 1 09:38:42 tbox kernel: [ 21.970076] wlan0: authenticated
Dec 1 09:38:42 tbox kernel: [ 21.970094] wlan0: associate with
00:04:0e:e4:00:3d (try 1)
Dec 1 09:38:42 tbox kernel: [ 21.975454] wlan0: RX AssocResp from
00:04:0e:e4:00:3d (capab=0x411 status=0 aid=1)
Dec 1 09:38:42 tbox kernel: [ 21.975458] wlan0: associated
Dec 1 09:38:42 tbox kernel: [ 21.976415] ADDRCONF(NETDEV_CHANGE):
wlan0: link becomes ready
Dec 1 09:38:53 tbox kernel: [ 32.848041] wlan0: no IPv6 routers present
Dec 1 09:38:56 tbox kernel: [ 36.320070] ieee80211 phy0: wlan0: No
probe response from AP 00:04:0e:e4:00:3d after 500ms, disconnecting.
Dec 1 09:38:56 tbox kernel: [ 36.320961] cfg80211: Calling CRDA to
update world regulatory domain
Full syslog attached.
- Sedat -
On Wed, Dec 1, 2010 at 11:56 AM, Sedat Dilek <[email protected]> wrote:
> On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
>> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>>> Hi,
>>>
>>> I have built today a linux-next (next-20101201) kernel which includes
>>> wireless-next-2.6 up to master-2010-11-30.
[ ... ]
>>> Unfortunately, my wlan network connection is totally unstable.
[ ... ]
>>> The block looks like this:
>>> [ 4436.504059] ieee80211 phy0: wlan0: No probe response from AP
>>> 00:04:0e:e4:00:3d after 500ms, disconnecting.
>>> [ 4436.504490] cfg80211: Calling CRDA to update world regulatory domain
>>> [ 4440.677020] wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
>>> [ 4440.679096] wlan0: authenticated
>>> [ 4440.679158] wlan0: associate with 00:04:0e:e4:00:3d (try 1)
>>> [ 4440.684667] wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411
>>> status=0 aid=1)
>>> [ 4440.684673] wlan0: associated
>>>
>>> My wlan device is an ath5k:
>>>
>>> $ lspci -nnvv | grep "Ethernet controller" | grep -i ath
>>> 02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
>>> 802.11abg NIC [168c:1014] (rev 01)
[ ...]
>> 1.) For identification of the chipset, please:
>> dmesg |grep "ath5.*chip"
# grep "Dec 1 09:38" /var/log/syslog | grep "ath5.*chip"
Dec 1 09:38:40 tbox kernel: [ 8.233119] ath5k phy0: Atheros AR5212
chip found (MAC: 0x56, PHY: 0x41)
>> 2.) Is there a problem when you don't use encryption?
How do I setup "dont-use-encryption"? Hardware-/Software-encyrption?
For ath5k? Change WLAN setup (in router-config)?
>> 3.) git bisect might help track it down.
Hunting another bug ATM...
Rebuilding right now with ath* debug options (might take a while).
- Sedat -
>
> When does it happen?
> Normal daily usage of Internet-ing... + kernel build with -j5
> (Pentium-M, 1G RAM)...
>
> I have set now as extra (just rebuilding):
> CONFIG_ATH_DEBUG=y
> CONFIG_ATH5K_DEBUG=y
>
> # egrep 'Dec 1 09:38' /var/log/syslog | egrep -i 'ath|80211|wlan'
> Dec 1 09:38:40 tbox kernel: [ 6.919633] cfg80211: Calling CRDA to
> update world regulatory domain
> Dec 1 09:38:40 tbox kernel: [ 7.401522] ath5k 0000:02:02.0: PCI
> INT A -> Link[LNKC] -> GSI 11 (level, low) -> IRQ 11
> Dec 1 09:38:40 tbox kernel: [ 7.401677] ath5k 0000:02:02.0:
> registered as 'phy0'
> Dec 1 09:38:40 tbox kernel: [ 7.689793] ath: EEPROM regdomain: 0x61
> Dec 1 09:38:40 tbox kernel: [ 7.689797] ath: EEPROM indicates we
> should expect a direct regpair map
> Dec 1 09:38:40 tbox kernel: [ 7.689803] ath: Country alpha2 being used: 00
> Dec 1 09:38:40 tbox kernel: [ 7.689805] ath: Regpair used: 0x61
> Dec 1 09:38:40 tbox kernel: [ 8.232093] ieee80211 phy0: Selected
> rate control algorithm 'minstrel_ht'
> Dec 1 09:38:40 tbox kernel: [ 8.233067] Registered led device:
> ath5k-phy0::rx
> Dec 1 09:38:40 tbox kernel: [ 8.233106] Registered led device:
> ath5k-phy0::tx
> Dec 1 09:38:40 tbox kernel: [ 8.233119] ath5k phy0: Atheros AR5212
> chip found (MAC: 0x56, PHY: 0x41)
> Dec 1 09:38:40 tbox kernel: [ 8.233165] ath5k phy0: RF5111 5GHz
> radio found (0x17)
> Dec 1 09:38:40 tbox kernel: [ 8.233202] ath5k phy0: RF2111 2GHz
> radio found (0x23)
> Dec 1 09:38:41 tbox kernel: [ 16.753896] ADDRCONF(NETDEV_UP):
> wlan0: link is not ready
> Dec 1 09:38:42 tbox wpa_supplicant[972]: Trying to associate with
> 00:04:0e:e4:00:3d (SSID='myCastle-WLAN WPA (Wireless LAN)' freq=2442
> MHz)
> Dec 1 09:38:42 tbox kernel: [ 21.967986] wlan0: authenticate with
> 00:04:0e:e4:00:3d (try 1)
> Dec 1 09:38:42 tbox kernel: [ 21.970076] wlan0: authenticated
> Dec 1 09:38:42 tbox kernel: [ 21.970094] wlan0: associate with
> 00:04:0e:e4:00:3d (try 1)
> Dec 1 09:38:42 tbox kernel: [ 21.975454] wlan0: RX AssocResp from
> 00:04:0e:e4:00:3d (capab=0x411 status=0 aid=1)
> Dec 1 09:38:42 tbox kernel: [ 21.975458] wlan0: associated
> Dec 1 09:38:42 tbox kernel: [ 21.976415] ADDRCONF(NETDEV_CHANGE):
> wlan0: link becomes ready
> Dec 1 09:38:53 tbox kernel: [ 32.848041] wlan0: no IPv6 routers present
> Dec 1 09:38:56 tbox kernel: [ 36.320070] ieee80211 phy0: wlan0: No
> probe response from AP 00:04:0e:e4:00:3d after 500ms, disconnecting.
> Dec 1 09:38:56 tbox kernel: [ 36.320961] cfg80211: Calling CRDA to
> update world regulatory domain
>
> Full syslog attached.
>
> - Sedat -
>
2010/12/2 Nick Kossifidis <[email protected]>:
> 2010/12/2 Sedat Dilek <[email protected]>:
>> On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
>>> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>>>> Hi,
>>>>
>>>> I have built today a linux-next (next-20101201) kernel which includes
>>>> wireless-next-2.6 up to master-2010-11-30.
>> [...]
>>>> Unfortunately, my wlan network connection is totally unstable.
>> [...]
>>> 1.) For identification of the chipset, please:
>>> dmesg |grep "ath5.*chip"
>>>
>>> 2.) Is there a problem when you don't use encryption?
>>>
>>> 3.) git bisect might help track it down.
>>>
>>> bruno
>>
>> OK, I did not a "classic" git-bisect, I created from linux-next
>> (next-20101202) GIT tree a revert-ath5k patchset (30 in total).
>>
>> [1] VERY GOOD: Revertiing all 30 patches
>>
>> ...leads to a stable system.
>>
>> [2] REDUCED DISCONNECTIONS DROPS: Reverting 0001..0008
>>
>> This stabilizes the system, but... listening to a radio
>> broadcast-stream with VLC is a pain in the ass... permanent audio
>> dropouts. I had only 2 disconnections in the first 10mins when system
>> was up (normally I can see disconnects after loggin into my KDE
>> desktop).
>>
>> [3] GOOD AUDIO STREAMING: Reverting 0001..0014
>>
>> This is just fine, system like I am used to.
>>
>> [4] CONCLUSION
>>
>> So I played a bit with my revert-patchset.
>>
>> Reverting 0001..0008 + a refreshed v2 of
>> 0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch (patch attached) is
>> doing the job here.
>>
>> Having a closer look into 0008 (parts of
>> drivers/net/wireless/ath/ath5k/reset.c):
>>
>> $ grep AR5212 patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>> - if (ah->ah_version == AR5K_AR5212)
>> + * On AR5212 TSF is almost preserved across a
>> - * On AR5212 TSF is almost preserved across a
>> + if (ah->ah_version == AR5K_AR5212) {
>> - if (ah->ah_version == AR5K_AR5212 &&
>>
>> As I mentionned I have a AR5212 wlan device!
>> What to do with that parts?
>> Any idea?
>>
>> Kind Regards,
>> - Sedat -
>>
>> P.S.: I have added a list containing all commit-ids (chronological)
>> and a script how I reverted (documenting for myself).
>>
>> $ ls patches/revert-wireless-patches/00*.patch
>> patches/revert-wireless-patches/0001-Revert-ath5k-Set-turbo-bit-on-rf-bank-2.patch
>> patches/revert-wireless-patches/0002-Revert-ath5k-Clean-up-turbo-mode-initvals-rfregs.patch
>> patches/revert-wireless-patches/0003-Revert-ath5k-Cleanup-turbo-channel-flags.patch
>> patches/revert-wireless-patches/0004-Revert-ath5k-Use-correct-clock-when-setting-ofdm-tim.patch
>> patches/revert-wireless-patches/0005-Revert-ath5k-Skip-tx-power-setting-on-AR5210-for-now.patch
>> patches/revert-wireless-patches/0006-Revert-ath5k-Tweak-phy-activate-to-rx-start-delay-ba.patch
>> patches/revert-wireless-patches/0007-Revert-ath5k-No-need-to-save-restore-staid-flags-on-.patch
>> patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>> patches/revert-wireless-patches/0009-Revert-ath5k-Skip-powertable-setting-when-we-are-on-.patch
>> patches/revert-wireless-patches/0010-Revert-ath5k-Update-PLL-programming-for-turbo-half-q.patch
>> patches/revert-wireless-patches/0011-Revert-ath5k-Update-spur-mitigation-filter-for-turbo.patch
>> patches/revert-wireless-patches/0012-Revert-ath5k-Tweak-power-detector-delays-on-RF5111-R.patch
>> patches/revert-wireless-patches/0013-Revert-ath5k-Always-set-IFS-intervals-on-reset.patch
>> patches/revert-wireless-patches/0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch
>> patches/revert-wireless-patches/0015-Revert-ath5k-Set-all-IFS-intervals-not-just-slot-tim.patch
>> patches/revert-wireless-patches/0016-Revert-ath5k-Extend-rate_duration.patch
>> patches/revert-wireless-patches/0017-Revert-ath5k-Extend-get_default_sifs-slot_time.patch
>> patches/revert-wireless-patches/0018-Revert-ath5k-Move-tx-retries-setting-outside-reset_t.patch
>> patches/revert-wireless-patches/0019-Revert-ath5k-Increase-PHY-settling-parameters-for-tu.patch
>> patches/revert-wireless-patches/0020-Revert-ath5k-Small-cleanup-on-tweak_initvals.patch
>> patches/revert-wireless-patches/0021-Revert-ath5k-Put-core-clock-initialization-on-a-new-.patch
>> patches/revert-wireless-patches/0022-Revert-ath5k-Add-new-field-on-ath5k_hw-to-track-band.patch
>> patches/revert-wireless-patches/0023-Revert-ath5k-Use-new-function-to-stop-beacon-queue.patch
>> patches/revert-wireless-patches/0024-Revert-ath5k-Check-RXE-when-setting-RXDP.patch
>> patches/revert-wireless-patches/0025-Revert-ath5k-Use-DCU-early-termination-correctly.patch
>> patches/revert-wireless-patches/0026-Revert-ath5k-Debug-DMA-timeouts.patch
>> patches/revert-wireless-patches/0027-Revert-ath5k-Use-new-dma_stop-function-on-base.c.patch
>> patches/revert-wireless-patches/0028-Revert-ath5k-Stop-PCU-on-reset.patch
>> patches/revert-wireless-patches/0029-Revert-ath5k-Add-new-function-to-stop-rx-tx-DMA.patch
>> patches/revert-wireless-patches/0030-Revert-ath5k-Reset-cleanup-and-generic-cleanup.patch
>>
>
> OK this doesn't make any sense, based on your logs you have an
> AR5212+RF5111+RF2111 combination, synth-only channel change (0008) is
> only executed on AR2413 and AR5413 so you don't even run that code,
> setting turbo flag on DCU (0014) is also unrelated since we never
> enable turbo mode and if we did you wouldn't be able to receive
> anything non-turbo.
>
> I am going to test 2 cards like yours a CM6 and an older one from
> Atheros and come back to you ASAP...
>
I just reproduced it on a CM6 and a CM9 (AR5212 + RF5112), problem
occurs when card is idle (no traffic) that's why my automated test
didn't catch it I can still run iperf after connecting and leave it
running without problems, when traffic stops it soon gets
disconnected. I suspect it's something related to IFS timings/ACK
timeout (0013 on your reverted series), maybe Jonathan Guerin was
correct about ACK timeout...
I'll try something and come back to you with code ;-)
Thanks for reporting !
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
2010/12/3 Nick Kossifidis <[email protected]>:
> 2010/12/2 Nick Kossifidis <[email protected]>:
>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>> 2010/12/2 Sedat Dilek <[email protected]>:
>>>> On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
>>>>> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have built today a linux-next (next-20101201) kernel which includes
>>>>>> wireless-next-2.6 up to master-2010-11-30.
>>>> [...]
>>>>>> Unfortunately, my wlan network connection is totally unstable.
>>>> [...]
>>>>> 1.) For identification of the chipset, please:
>>>>> dmesg |grep "ath5.*chip"
>>>>>
>>>>> 2.) Is there a problem when you don't use encryption?
>>>>>
>>>>> 3.) git bisect might help track it down.
>>>>>
>>>>> bruno
>>>>
>>>> OK, I did not a "classic" git-bisect, I created from linux-next
>>>> (next-20101202) GIT tree a revert-ath5k patchset (30 in total).
>>>>
>>>> [1] VERY GOOD: Revertiing all 30 patches
>>>>
>>>> ...leads to a stable system.
>>>>
>>>> [2] REDUCED DISCONNECTIONS DROPS: Reverting 0001..0008
>>>>
>>>> This stabilizes the system, but... listening to a radio
>>>> broadcast-stream with VLC is a pain in the ass... permanent audio
>>>> dropouts. I had only 2 disconnections in the first 10mins when system
>>>> was up (normally I can see disconnects after loggin into my KDE
>>>> desktop).
>>>>
>>>> [3] GOOD AUDIO STREAMING: Reverting 0001..0014
>>>>
>>>> This is just fine, system like I am used to.
>>>>
>>>> [4] CONCLUSION
>>>>
>>>> So I played a bit with my revert-patchset.
>>>>
>>>> Reverting 0001..0008 + a refreshed v2 of
>>>> 0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch (patch attached) is
>>>> doing the job here.
>>>>
>>>> Having a closer look into 0008 (parts of
>>>> drivers/net/wireless/ath/ath5k/reset.c):
>>>>
>>>> $ grep AR5212 patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>> - if (ah->ah_version == AR5K_AR5212)
>>>> + * On AR5212 TSF is almost preserved across a
>>>> - * On AR5212 TSF is almost preserved across a
>>>> + if (ah->ah_version == AR5K_AR5212) {
>>>> - if (ah->ah_version == AR5K_AR5212 &&
>>>>
>>>> As I mentionned I have a AR5212 wlan device!
>>>> What to do with that parts?
>>>> Any idea?
>>>>
>>>> Kind Regards,
>>>> - Sedat -
>>>>
>>>> P.S.: I have added a list containing all commit-ids (chronological)
>>>> and a script how I reverted (documenting for myself).
>>>>
>>>> $ ls patches/revert-wireless-patches/00*.patch
>>>> patches/revert-wireless-patches/0001-Revert-ath5k-Set-turbo-bit-on-rf-bank-2.patch
>>>> patches/revert-wireless-patches/0002-Revert-ath5k-Clean-up-turbo-mode-initvals-rfregs.patch
>>>> patches/revert-wireless-patches/0003-Revert-ath5k-Cleanup-turbo-channel-flags.patch
>>>> patches/revert-wireless-patches/0004-Revert-ath5k-Use-correct-clock-when-setting-ofdm-tim.patch
>>>> patches/revert-wireless-patches/0005-Revert-ath5k-Skip-tx-power-setting-on-AR5210-for-now.patch
>>>> patches/revert-wireless-patches/0006-Revert-ath5k-Tweak-phy-activate-to-rx-start-delay-ba.patch
>>>> patches/revert-wireless-patches/0007-Revert-ath5k-No-need-to-save-restore-staid-flags-on-.patch
>>>> patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>> patches/revert-wireless-patches/0009-Revert-ath5k-Skip-powertable-setting-when-we-are-on-.patch
>>>> patches/revert-wireless-patches/0010-Revert-ath5k-Update-PLL-programming-for-turbo-half-q.patch
>>>> patches/revert-wireless-patches/0011-Revert-ath5k-Update-spur-mitigation-filter-for-turbo.patch
>>>> patches/revert-wireless-patches/0012-Revert-ath5k-Tweak-power-detector-delays-on-RF5111-R.patch
>>>> patches/revert-wireless-patches/0013-Revert-ath5k-Always-set-IFS-intervals-on-reset.patch
>>>> patches/revert-wireless-patches/0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch
>>>> patches/revert-wireless-patches/0015-Revert-ath5k-Set-all-IFS-intervals-not-just-slot-tim.patch
>>>> patches/revert-wireless-patches/0016-Revert-ath5k-Extend-rate_duration.patch
>>>> patches/revert-wireless-patches/0017-Revert-ath5k-Extend-get_default_sifs-slot_time.patch
>>>> patches/revert-wireless-patches/0018-Revert-ath5k-Move-tx-retries-setting-outside-reset_t.patch
>>>> patches/revert-wireless-patches/0019-Revert-ath5k-Increase-PHY-settling-parameters-for-tu.patch
>>>> patches/revert-wireless-patches/0020-Revert-ath5k-Small-cleanup-on-tweak_initvals.patch
>>>> patches/revert-wireless-patches/0021-Revert-ath5k-Put-core-clock-initialization-on-a-new-.patch
>>>> patches/revert-wireless-patches/0022-Revert-ath5k-Add-new-field-on-ath5k_hw-to-track-band.patch
>>>> patches/revert-wireless-patches/0023-Revert-ath5k-Use-new-function-to-stop-beacon-queue.patch
>>>> patches/revert-wireless-patches/0024-Revert-ath5k-Check-RXE-when-setting-RXDP.patch
>>>> patches/revert-wireless-patches/0025-Revert-ath5k-Use-DCU-early-termination-correctly.patch
>>>> patches/revert-wireless-patches/0026-Revert-ath5k-Debug-DMA-timeouts.patch
>>>> patches/revert-wireless-patches/0027-Revert-ath5k-Use-new-dma_stop-function-on-base.c.patch
>>>> patches/revert-wireless-patches/0028-Revert-ath5k-Stop-PCU-on-reset.patch
>>>> patches/revert-wireless-patches/0029-Revert-ath5k-Add-new-function-to-stop-rx-tx-DMA.patch
>>>> patches/revert-wireless-patches/0030-Revert-ath5k-Reset-cleanup-and-generic-cleanup.patch
>>>>
>>>
>>> OK this doesn't make any sense, based on your logs you have an
>>> AR5212+RF5111+RF2111 combination, synth-only channel change (0008) is
>>> only executed on AR2413 and AR5413 so you don't even run that code,
>>> setting turbo flag on DCU (0014) is also unrelated since we never
>>> enable turbo mode and if we did you wouldn't be able to receive
>>> anything non-turbo.
>>>
>>> I am going to test 2 cards like yours a CM6 and an older one from
>>> Atheros and come back to you ASAP...
>>>
>>
>> I just reproduced it on a CM6 and a CM9 (AR5212 + RF5112), problem
>> occurs when card is idle (no traffic) that's why my automated test
>> didn't catch it I can still run iperf after connecting and leave it
>> running without problems, when traffic stops it soon gets
>> disconnected. I suspect it's something related to IFS timings/ACK
>> timeout (0013 on your reverted series), maybe Jonathan Guerin was
>> correct about ACK timeout...
>>
>> I'll try something and come back to you with code ;-)
>>
>> Thanks for reporting !
>>
>
> Nope, it's PHY related and only affects RF5111/RF5112, AR2413 and
> above work fine...
>
Got it, patch on the way...
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Wed, Dec 1, 2010 at 11:05 PM, Nick Kossifidis <[email protected]> wrote:
> 2010/12/1 Sedat Dilek <[email protected]>:
>> Hi,
>>
>> I have built today a linux-next (next-20101201) kernel which includes
>> wireless-next-2.6 up to master-2010-11-30.
>>
>> From tig utility:
>> 2010-11-30 15:33 Stanislaw Gruszka [wireless-next-2.6] iwlagn: fix
>> microcode error on 4965
>> [main] 61790c5f3c5f158821821a00797d94504531839f - commit 1929 of 226338 (0%)
>>
>> Unfortunately, my wlan network connection is totally unstable.
>>
>> $ dmesg | grep "RX AssocResp" | wc -l
>> 216
>>
>> The block looks like this:
>> [ 4436.504059] ieee80211 phy0: wlan0: No probe response from AP
>> 00:04:0e:e4:00:3d after 500ms, disconnecting.
>> [ 4436.504490] cfg80211: Calling CRDA to update world regulatory domain
>> [ 4440.677020] wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
>> [ 4440.679096] wlan0: authenticated
>> [ 4440.679158] wlan0: associate with 00:04:0e:e4:00:3d (try 1)
>> [ 4440.684667] wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411
>> status=0 aid=1)
>> [ 4440.684673] wlan0: associated
>>
>> My wlan device is an ath5k:
>>
>> $ lspci -nnvv | grep "Ethernet controller" | grep -i ath
>> 02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
>> 802.11abg NIC [168c:1014] (rev 01)
>>
>> Any idea what's wrong? (Just speculating on the last patch-set from Nick...)
>> How can I help to dig into this problem?
>> Debug-session with wpasupplicant? Which kernel-parameters (debug) to
>> be considered/set?
>>
>> Kind Regards,
>> - Sedat -
>>
>
> That's weird I tested all patches for connectivity + iperf, maybe
> something else also went on the tree that results such behavior...
>
> 1) Are you using NetworkManager ? If so disable it and connect manually.
No NM here, using "classic" /etc/network/interfaces with IP-static setup.
[ /etc/network/interfaces ]
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The wireless LAN interface
auto wlan0
iface wlan0 inet static
address 192.168.178.25
netmask 255.255.255.0
broadcast 192.168.178.255
gateway 192.168.178.1
dns-nameservers 192.168.178.1 208.67.222.222 208.67.220.220
wpa-ssid myCastle-WLAN WPA (Wireless LAN)
wpa-psk mySecretPWD
- EOF -
> 2) Can you disable encryption on your AP and see if it works without it ?
[ /etc/network/interfaces ]
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The wireless LAN interface
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-key-mgmt NONE
wpa-ssid myCastle-WLAN WPA (Wireless LAN)
- EOF -
Router "open" and ath5k "normal":
Dec 1 23:49:26 tbox kernel: [ 8192.504060] ieee80211 phy0: wlan0: No
probe response from AP 00:04:0e:e4:00:3d after 500ms, disconnecting.
Dec 1 23:49:26 tbox wpa_supplicant[5472]: CTRL-EVENT-DISCONNECTED -
Disconnect event - remove keys
Dec 1 23:49:26 tbox kernel: [ 8192.517097] cfg80211: Calling CRDA to
update world regulatory domain
Dec 1 23:49:31 tbox wpa_supplicant[5472]: Trying to associate with
00:04:0e:e4:00:3d (SSID='myCastle-WLAN WPA (Wireless LAN)' freq=2442
MHz)
Dec 1 23:49:31 tbox kernel: [ 8196.683802] wlan0: authenticate with
00:04:0e:e4:00:3d (try 1)
Dec 1 23:49:31 tbox kernel: [ 8196.686256] wlan0: authenticated
Dec 1 23:49:31 tbox kernel: [ 8196.686302] wlan0: associate with
00:04:0e:e4:00:3d (try 1)
Dec 1 23:49:31 tbox kernel: [ 8196.688608] wlan0: RX AssocResp from
00:04:0e:e4:00:3d (capab=0x401 status=0 aid=1)
Dec 1 23:49:31 tbox kernel: [ 8196.688620] wlan0: associated
Dec 1 23:49:31 tbox wpa_supplicant[5472]: Associated with 00:04:0e:e4:00:3d
Dec 1 23:49:31 tbox wpa_supplicant[5472]: CTRL-EVENT-CONNECTED -
Connection to 00:04:0e:e4:00:3d completed (reauth) [id=0 id_str=]
Router "open" ath5k with nohwcrypt=1:
Dec 1 23:51:20 tbox kernel: [ 8306.504080] ieee80211 phy0: wlan0: No
probe response from AP 00:04:0e:e4:00:3d after 500ms, disconnecting.
Dec 1 23:51:20 tbox kernel: [ 8306.504968] cfg80211: Calling CRDA to
update world regulatory domain
Dec 1 23:51:22 tbox ntpdate[5739]: adjust time server 192.53.103.108
offset 0.001238 sec
Dec 1 23:51:25 tbox wpa_supplicant[5677]: Trying to associate with
00:04:0e:e4:00:3d (SSID='myCastle-WLAN WPA (Wireless LAN)' freq=2442
MHz)
Dec 1 23:51:25 tbox kernel: [ 8310.755922] wlan0: authenticate with
00:04:0e:e4:00:3d (try 1)
Dec 1 23:51:25 tbox kernel: [ 8310.758023] wlan0: authenticated
Dec 1 23:51:25 tbox kernel: [ 8310.758103] wlan0: associate with
00:04:0e:e4:00:3d (try 1)
Dec 1 23:51:25 tbox kernel: [ 8310.760738] wlan0: RX AssocResp from
00:04:0e:e4:00:3d (capab=0x401 status=0 aid=1)
Dec 1 23:51:25 tbox kernel: [ 8310.760750] wlan0: associated
Dec 1 23:51:25 tbox wpa_supplicant[5677]: Associated with 00:04:0e:e4:00:3d
Dec 1 23:51:25 tbox wpa_supplicant[5677]: CTRL-EVENT-CONNECTED -
Connection to 00:04:0e:e4:00:3d completed (reauth) [id=0 id_str=]
> 3) Try and enable/disable hw encryption with nohwcrypt module parameter.
# modinfo ath5k | grep nohwcrypt
parm: nohwcrypt:Disable hardware encryption. (bool)
# modprobe -v ath5k nohwcrypt=1
# lsmod | egrep -i 'ath|80211|aes'
ath5k 137422 0
ath 10977 1 ath5k
mac80211 150863 1 ath5k
cfg80211 97248 3 ath5k,ath,mac80211
aes_i586 6856 0
aes_generic 25758 1 aes_i586
rfkill 10754 4 cfg80211,bluetooth,thinkpad_acpi
Same error-messages AFAICS:
Dec 1 23:22:27 tbox kernel: [ 6573.500056] ieee80211 phy0: wlan0: No
probe response from AP 00:04:0e:e4:00:3d after 500ms, disconnecting.
Dec 1 23:22:27 tbox kernel: [ 6573.500541] cfg80211: Calling CRDA to
update world regulatory domain
Dec 1 23:22:32 tbox wpa_supplicant[3372]: Trying to associate with
00:04:0e:e4:00:3d (SSID='myCastle-WLAN WPA (Wireless LAN)' freq=2442
MHz)
Dec 1 23:22:32 tbox kernel: [ 6577.739895] wlan0: authenticate with
00:04:0e:e4:00:3d (try 1)
Dec 1 23:22:32 tbox kernel: [ 6577.741981] wlan0: authenticated
Dec 1 23:22:32 tbox kernel: [ 6577.742028] wlan0: associate with
00:04:0e:e4:00:3d (try 1)
Dec 1 23:22:32 tbox kernel: [ 6577.747151] wlan0: RX AssocResp from
00:04:0e:e4:00:3d (capab=0x411 status=0 aid=1)
Dec 1 23:22:32 tbox kernel: [ 6577.747163] wlan0: associated
Dec 1 23:22:32 tbox wpa_supplicant[3372]: Associated with 00:04:0e:e4:00:3d
Dec 1 23:22:33 tbox wpa_supplicant[3372]: WPA: Key negotiation
completed with 00:04:0e:e4:00:3d [PTK=CCMP GTK=CCMP]
Dec 1 23:22:33 tbox wpa_supplicant[3372]: CTRL-EVENT-CONNECTED -
Connection to 00:04:0e:e4:00:3d completed (reauth) [id=0 id_str=]
> 4) What's your signal strength/rate when you connect to the AP ?
[1] ath5k with nohwcrypt=1 (mostly 1MBps @ -55dBm)
# iw dev wlan0 station dump
Station 00:04:0e:e4:00:3d (on wlan0)
inactive time: 1876 ms
rx bytes: 28313
rx packets: 341
tx bytes: 4629
tx packets: 29
signal: -66 dBm
tx bitrate: 1.0 MBit/s
# iw dev wlan0 station dump
Station 00:04:0e:e4:00:3d (on wlan0)
inactive time: 708 ms
rx bytes: 26476
rx packets: 334
tx bytes: 2835
tx packets: 10
signal: -66 dBm
tx bitrate: 48.0 MBit/s
[2] ath5k (with no modules options):
# iw dev wlan0 station dump
Station 00:04:0e:e4:00:3d (on wlan0)
inactive time: 32 ms
rx bytes: 17987
rx packets: 197
tx bytes: 15193
tx packets: 56
signal: -64 dBm
tx bitrate: 18.0 MBit/s
- Sedat -
2010/12/1 Sedat Dilek <[email protected]>:
> Hi,
>
> I have built today a linux-next (next-20101201) kernel which includes
> wireless-next-2.6 up to master-2010-11-30.
>
> From tig utility:
> 2010-11-30 15:33 Stanislaw Gruszka [wireless-next-2.6] iwlagn: fix
> microcode error on 4965
> [main] 61790c5f3c5f158821821a00797d94504531839f - commit 1929 of 226338 (0%)
>
> Unfortunately, my wlan network connection is totally unstable.
>
> $ dmesg | grep "RX AssocResp" | wc -l
> 216
>
> The block looks like this:
> [ 4436.504059] ieee80211 phy0: wlan0: No probe response from AP
> 00:04:0e:e4:00:3d after 500ms, disconnecting.
> [ 4436.504490] cfg80211: Calling CRDA to update world regulatory domain
> [ 4440.677020] wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
> [ 4440.679096] wlan0: authenticated
> [ 4440.679158] wlan0: associate with 00:04:0e:e4:00:3d (try 1)
> [ 4440.684667] wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411
> status=0 aid=1)
> [ 4440.684673] wlan0: associated
>
> My wlan device is an ath5k:
>
> $ lspci -nnvv | grep "Ethernet controller" | grep -i ath
> 02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
> 802.11abg NIC [168c:1014] (rev 01)
>
> Any idea what's wrong? (Just speculating on the last patch-set from Nick...)
> How can I help to dig into this problem?
> Debug-session with wpasupplicant? Which kernel-parameters (debug) to
> be considered/set?
>
> Kind Regards,
> - Sedat -
>
That's weird I tested all patches for connectivity + iperf, maybe
something else also went on the tree that results such behavior...
1) Are you using NetworkManager ? If so disable it and connect manually.
2) Can you disable encryption on your AP and see if it works without it ?
3) Try and enable/disable hw encryption with nohwcrypt module parameter.
4) What's your signal strength/rate when you connect to the AP ?
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>> Hi,
>>
>> I have built today a linux-next (next-20101201) kernel which includes
>> wireless-next-2.6 up to master-2010-11-30.
>>
>> >From tig utility:
>> 2010-11-30 15:33 Stanislaw Gruszka [wireless-next-2.6] iwlagn: fix
>> microcode error on 4965
>> [main] 61790c5f3c5f158821821a00797d94504531839f - commit 1929 of 226338
>> (0%)
>>
>> Unfortunately, my wlan network connection is totally unstable.
>>
>> $ dmesg | grep "RX AssocResp" | wc -l
>> 216
>>
>> The block looks like this:
>> [ 4436.504059] ieee80211 phy0: wlan0: No probe response from AP
>> 00:04:0e:e4:00:3d after 500ms, disconnecting.
>> [ 4436.504490] cfg80211: Calling CRDA to update world regulatory domain
>> [ 4440.677020] wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
>> [ 4440.679096] wlan0: authenticated
>> [ 4440.679158] wlan0: associate with 00:04:0e:e4:00:3d (try 1)
>> [ 4440.684667] wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411
>> status=0 aid=1)
>> [ 4440.684673] wlan0: associated
>>
>> My wlan device is an ath5k:
>>
>> $ lspci -nnvv | grep "Ethernet controller" | grep -i ath
>> 02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
>> 802.11abg NIC [168c:1014] (rev 01)
>>
>> Any idea what's wrong? (Just speculating on the last patch-set from
>> Nick...) How can I help to dig into this problem?
>> Debug-session with wpasupplicant? Which kernel-parameters (debug) to
>> be considered/set?
>
> 1.) For identification of the chipset, please:
> dmesg |grep "ath5.*chip"
>
> 2.) Is there a problem when you don't use encryption?
>
> 3.) git bisect might help track it down.
>
> bruno
>
Now, I have a debug-session via:
# modprobe -v ath5k debug=0xffffffff
Looks like I am using AES encryption here:
# lsmod | egrep -i 'ath|80211|aes'
aes_i586 6856 2
aes_generic 25758 1 aes_i586
ath5k 137422 0
ath 10977 1 ath5k
mac80211 150863 1 ath5k
cfg80211 97248 3 ath5k,ath,mac80211
rfkill 10754 4 bluetooth,thinkpad_acpi,cfg80211
Here the status via wpa_cli:
# wpa_cli status -i wlan0
bssid=00:04:0e:e4:00:3d
ssid=myCastle-WLAN WPA (Wireless LAN)
id=0
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=192.168.178.25
Hope the (filtered log helps)... I have more but it's 600KiB (xz-compressed).
Please, let me know.
- Sedat -
2010/12/3 Nick Kossifidis <[email protected]>:
> 2010/12/3 Nick Kossifidis <[email protected]>:
>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>>> 2010/12/2 Sedat Dilek <[email protected]>:
>>>>>> On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
>>>>>>> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have built today a linux-next (next-20101201) kernel which includes
>>>>>>>> wireless-next-2.6 up to master-2010-11-30.
>>>>>> [...]
>>>>>>>> Unfortunately, my wlan network connection is totally unstable.
>>>>>> [...]
>>>>>>> 1.) For identification of the chipset, please:
>>>>>>> dmesg |grep "ath5.*chip"
>>>>>>>
>>>>>>> 2.) Is there a problem when you don't use encryption?
>>>>>>>
>>>>>>> 3.) git bisect might help track it down.
>>>>>>>
>>>>>>> bruno
>>>>>>
>>>>>> OK, I did not a "classic" git-bisect, I created from linux-next
>>>>>> (next-20101202) GIT tree a revert-ath5k patchset (30 in total).
>>>>>>
>>>>>> [1] VERY GOOD: Revertiing all 30 patches
>>>>>>
>>>>>> ...leads to a stable system.
>>>>>>
>>>>>> [2] REDUCED DISCONNECTIONS DROPS: Reverting 0001..0008
>>>>>>
>>>>>> This stabilizes the system, but... listening to a radio
>>>>>> broadcast-stream with VLC is a pain in the ass... permanent audio
>>>>>> dropouts. I had only 2 disconnections in the first 10mins when system
>>>>>> was up (normally I can see disconnects after loggin into my KDE
>>>>>> desktop).
>>>>>>
>>>>>> [3] GOOD AUDIO STREAMING: Reverting 0001..0014
>>>>>>
>>>>>> This is just fine, system like I am used to.
>>>>>>
>>>>>> [4] CONCLUSION
>>>>>>
>>>>>> So I played a bit with my revert-patchset.
>>>>>>
>>>>>> Reverting 0001..0008 + a refreshed v2 of
>>>>>> 0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch (patch attached) is
>>>>>> doing the job here.
>>>>>>
>>>>>> Having a closer look into 0008 (parts of
>>>>>> drivers/net/wireless/ath/ath5k/reset.c):
>>>>>>
>>>>>> $ grep AR5212 patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>>> - if (ah->ah_version == AR5K_AR5212)
>>>>>> + * On AR5212 TSF is almost preserved across a
>>>>>> - * On AR5212 TSF is almost preserved across a
>>>>>> + if (ah->ah_version == AR5K_AR5212) {
>>>>>> - if (ah->ah_version == AR5K_AR5212 &&
>>>>>>
>>>>>> As I mentionned I have a AR5212 wlan device!
>>>>>> What to do with that parts?
>>>>>> Any idea?
>>>>>>
>>>>>> Kind Regards,
>>>>>> - Sedat -
>>>>>>
>>>>>> P.S.: I have added a list containing all commit-ids (chronological)
>>>>>> and a script how I reverted (documenting for myself).
>>>>>>
>>>>>> $ ls patches/revert-wireless-patches/00*.patch
>>>>>> patches/revert-wireless-patches/0001-Revert-ath5k-Set-turbo-bit-on-rf-bank-2.patch
>>>>>> patches/revert-wireless-patches/0002-Revert-ath5k-Clean-up-turbo-mode-initvals-rfregs.patch
>>>>>> patches/revert-wireless-patches/0003-Revert-ath5k-Cleanup-turbo-channel-flags.patch
>>>>>> patches/revert-wireless-patches/0004-Revert-ath5k-Use-correct-clock-when-setting-ofdm-tim.patch
>>>>>> patches/revert-wireless-patches/0005-Revert-ath5k-Skip-tx-power-setting-on-AR5210-for-now.patch
>>>>>> patches/revert-wireless-patches/0006-Revert-ath5k-Tweak-phy-activate-to-rx-start-delay-ba.patch
>>>>>> patches/revert-wireless-patches/0007-Revert-ath5k-No-need-to-save-restore-staid-flags-on-.patch
>>>>>> patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>>> patches/revert-wireless-patches/0009-Revert-ath5k-Skip-powertable-setting-when-we-are-on-.patch
>>>>>> patches/revert-wireless-patches/0010-Revert-ath5k-Update-PLL-programming-for-turbo-half-q.patch
>>>>>> patches/revert-wireless-patches/0011-Revert-ath5k-Update-spur-mitigation-filter-for-turbo.patch
>>>>>> patches/revert-wireless-patches/0012-Revert-ath5k-Tweak-power-detector-delays-on-RF5111-R.patch
>>>>>> patches/revert-wireless-patches/0013-Revert-ath5k-Always-set-IFS-intervals-on-reset.patch
>>>>>> patches/revert-wireless-patches/0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch
>>>>>> patches/revert-wireless-patches/0015-Revert-ath5k-Set-all-IFS-intervals-not-just-slot-tim.patch
>>>>>> patches/revert-wireless-patches/0016-Revert-ath5k-Extend-rate_duration.patch
>>>>>> patches/revert-wireless-patches/0017-Revert-ath5k-Extend-get_default_sifs-slot_time.patch
>>>>>> patches/revert-wireless-patches/0018-Revert-ath5k-Move-tx-retries-setting-outside-reset_t.patch
>>>>>> patches/revert-wireless-patches/0019-Revert-ath5k-Increase-PHY-settling-parameters-for-tu.patch
>>>>>> patches/revert-wireless-patches/0020-Revert-ath5k-Small-cleanup-on-tweak_initvals.patch
>>>>>> patches/revert-wireless-patches/0021-Revert-ath5k-Put-core-clock-initialization-on-a-new-.patch
>>>>>> patches/revert-wireless-patches/0022-Revert-ath5k-Add-new-field-on-ath5k_hw-to-track-band.patch
>>>>>> patches/revert-wireless-patches/0023-Revert-ath5k-Use-new-function-to-stop-beacon-queue.patch
>>>>>> patches/revert-wireless-patches/0024-Revert-ath5k-Check-RXE-when-setting-RXDP.patch
>>>>>> patches/revert-wireless-patches/0025-Revert-ath5k-Use-DCU-early-termination-correctly.patch
>>>>>> patches/revert-wireless-patches/0026-Revert-ath5k-Debug-DMA-timeouts.patch
>>>>>> patches/revert-wireless-patches/0027-Revert-ath5k-Use-new-dma_stop-function-on-base.c.patch
>>>>>> patches/revert-wireless-patches/0028-Revert-ath5k-Stop-PCU-on-reset.patch
>>>>>> patches/revert-wireless-patches/0029-Revert-ath5k-Add-new-function-to-stop-rx-tx-DMA.patch
>>>>>> patches/revert-wireless-patches/0030-Revert-ath5k-Reset-cleanup-and-generic-cleanup.patch
>>>>>>
>>>>>
>>>>> OK this doesn't make any sense, based on your logs you have an
>>>>> AR5212+RF5111+RF2111 combination, synth-only channel change (0008) is
>>>>> only executed on AR2413 and AR5413 so you don't even run that code,
>>>>> setting turbo flag on DCU (0014) is also unrelated since we never
>>>>> enable turbo mode and if we did you wouldn't be able to receive
>>>>> anything non-turbo.
>>>>>
>>>>> I am going to test 2 cards like yours a CM6 and an older one from
>>>>> Atheros and come back to you ASAP...
>>>>>
>>>>
>>>> I just reproduced it on a CM6 and a CM9 (AR5212 + RF5112), problem
>>>> occurs when card is idle (no traffic) that's why my automated test
>>>> didn't catch it I can still run iperf after connecting and leave it
>>>> running without problems, when traffic stops it soon gets
>>>> disconnected. I suspect it's something related to IFS timings/ACK
>>>> timeout (0013 on your reverted series), maybe Jonathan Guerin was
>>>> correct about ACK timeout...
>>>>
>>>> I'll try something and come back to you with code ;-)
>>>>
>>>> Thanks for reporting !
>>>>
>>>
>>> Nope, it's PHY related and only affects RF5111/RF5112, AR2413 and
>>> above work fine...
>>>
>>
>> Got it, patch on the way...
>>
>
> First the problem is with patch 22 (0009), we still need to write the
> power table on hw, that fixes transmission and my CM9 works just fine
> after that. Now my 2 RF5111 based cards seem to also have some problem
> with stuck tx queues, after some time of fine operation (nearly
> 28Mbits with iperf). It might be a hw failure or something but i want
> to try and debug this further in case there is something i can do to
> fix it. I also found some other things, eg. i report RX dma stop
> failure when i shouldn't etc. Anyway back to debuging ;-)
>
>
> --
> GPG ID: 0xD21DB2DB
> As you read this post global entropy rises. Have Fun ;-)
> Nick
>
Done, works fine for me now, check it out ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Fri, Dec 3, 2010 at 7:31 AM, Nick Kossifidis <[email protected]> wrote:
> 2010/12/3 Sedat Dilek <[email protected]>:
>> On Fri, Dec 3, 2010 at 5:16 AM, Nick Kossifidis <[email protected]> wrote:
>>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>>>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>>>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>>>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>>>>>> 2010/12/2 Sedat Dilek <[email protected]>:
>>>>>>>>> On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
>>>>>>>>>> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I have built today a linux-next (next-20101201) kernel which includes
>>>>>>>>>>> wireless-next-2.6 up to master-2010-11-30.
>>>>>>>>> [...]
>>>>>>>>>>> Unfortunately, my wlan network connection is totally unstable.
>>>>>>>>> [...]
>>>>>>>>>> 1.) For identification of the chipset, please:
>>>>>>>>>> dmesg |grep "ath5.*chip"
>>>>>>>>>>
>>>>>>>>>> 2.) Is there a problem when you don't use encryption?
>>>>>>>>>>
>>>>>>>>>> 3.) git bisect might help track it down.
>>>>>>>>>>
>>>>>>>>>> bruno
>>>>>>>>>
>>>>>>>>> OK, I did not a "classic" git-bisect, I created from linux-next
>>>>>>>>> (next-20101202) GIT tree a revert-ath5k patchset (30 in total).
>>>>>>>>>
>>>>>>>>> [1] VERY GOOD: Revertiing all 30 patches
>>>>>>>>>
>>>>>>>>> ...leads to a stable system.
>>>>>>>>>
>>>>>>>>> [2] REDUCED DISCONNECTIONS DROPS: Reverting 0001..0008
>>>>>>>>>
>>>>>>>>> This stabilizes the system, but... listening to a radio
>>>>>>>>> broadcast-stream with VLC is a pain in the ass... permanent audio
>>>>>>>>> dropouts. I had only 2 disconnections in the first 10mins when system
>>>>>>>>> was up (normally I can see disconnects after loggin into my KDE
>>>>>>>>> desktop).
>>>>>>>>>
>>>>>>>>> [3] GOOD AUDIO STREAMING: Reverting 0001..0014
>>>>>>>>>
>>>>>>>>> This is just fine, system like I am used to.
>>>>>>>>>
>>>>>>>>> [4] CONCLUSION
>>>>>>>>>
>>>>>>>>> So I played a bit with my revert-patchset.
>>>>>>>>>
>>>>>>>>> Reverting 0001..0008 + a refreshed v2 of
>>>>>>>>> 0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch (patch attached) is
>>>>>>>>> doing the job here.
>>>>>>>>>
>>>>>>>>> Having a closer look into 0008 (parts of
>>>>>>>>> drivers/net/wireless/ath/ath5k/reset.c):
>>>>>>>>>
>>>>>>>>> $ grep AR5212 patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>>>>>> - if (ah->ah_version == AR5K_AR5212)
>>>>>>>>> + * On AR5212 TSF is almost preserved across a
>>>>>>>>> - * On AR5212 TSF is almost preserved across a
>>>>>>>>> + if (ah->ah_version == AR5K_AR5212) {
>>>>>>>>> - if (ah->ah_version == AR5K_AR5212 &&
>>>>>>>>>
>>>>>>>>> As I mentionned I have a AR5212 wlan device!
>>>>>>>>> What to do with that parts?
>>>>>>>>> Any idea?
>>>>>>>>>
>>>>>>>>> Kind Regards,
>>>>>>>>> - Sedat -
>>>>>>>>>
>>>>>>>>> P.S.: I have added a list containing all commit-ids (chronological)
>>>>>>>>> and a script how I reverted (documenting for myself).
>>>>>>>>>
>>>>>>>>> $ ls patches/revert-wireless-patches/00*.patch
>>>>>>>>> patches/revert-wireless-patches/0001-Revert-ath5k-Set-turbo-bit-on-rf-bank-2.patch
>>>>>>>>> patches/revert-wireless-patches/0002-Revert-ath5k-Clean-up-turbo-mode-initvals-rfregs.patch
>>>>>>>>> patches/revert-wireless-patches/0003-Revert-ath5k-Cleanup-turbo-channel-flags.patch
>>>>>>>>> patches/revert-wireless-patches/0004-Revert-ath5k-Use-correct-clock-when-setting-ofdm-tim.patch
>>>>>>>>> patches/revert-wireless-patches/0005-Revert-ath5k-Skip-tx-power-setting-on-AR5210-for-now.patch
>>>>>>>>> patches/revert-wireless-patches/0006-Revert-ath5k-Tweak-phy-activate-to-rx-start-delay-ba.patch
>>>>>>>>> patches/revert-wireless-patches/0007-Revert-ath5k-No-need-to-save-restore-staid-flags-on-.patch
>>>>>>>>> patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>>>>>> patches/revert-wireless-patches/0009-Revert-ath5k-Skip-powertable-setting-when-we-are-on-.patch
>>>>>>>>> patches/revert-wireless-patches/0010-Revert-ath5k-Update-PLL-programming-for-turbo-half-q.patch
>>>>>>>>> patches/revert-wireless-patches/0011-Revert-ath5k-Update-spur-mitigation-filter-for-turbo.patch
>>>>>>>>> patches/revert-wireless-patches/0012-Revert-ath5k-Tweak-power-detector-delays-on-RF5111-R.patch
>>>>>>>>> patches/revert-wireless-patches/0013-Revert-ath5k-Always-set-IFS-intervals-on-reset.patch
>>>>>>>>> patches/revert-wireless-patches/0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch
>>>>>>>>> patches/revert-wireless-patches/0015-Revert-ath5k-Set-all-IFS-intervals-not-just-slot-tim.patch
>>>>>>>>> patches/revert-wireless-patches/0016-Revert-ath5k-Extend-rate_duration.patch
>>>>>>>>> patches/revert-wireless-patches/0017-Revert-ath5k-Extend-get_default_sifs-slot_time.patch
>>>>>>>>> patches/revert-wireless-patches/0018-Revert-ath5k-Move-tx-retries-setting-outside-reset_t.patch
>>>>>>>>> patches/revert-wireless-patches/0019-Revert-ath5k-Increase-PHY-settling-parameters-for-tu.patch
>>>>>>>>> patches/revert-wireless-patches/0020-Revert-ath5k-Small-cleanup-on-tweak_initvals.patch
>>>>>>>>> patches/revert-wireless-patches/0021-Revert-ath5k-Put-core-clock-initialization-on-a-new-.patch
>>>>>>>>> patches/revert-wireless-patches/0022-Revert-ath5k-Add-new-field-on-ath5k_hw-to-track-band.patch
>>>>>>>>> patches/revert-wireless-patches/0023-Revert-ath5k-Use-new-function-to-stop-beacon-queue.patch
>>>>>>>>> patches/revert-wireless-patches/0024-Revert-ath5k-Check-RXE-when-setting-RXDP.patch
>>>>>>>>> patches/revert-wireless-patches/0025-Revert-ath5k-Use-DCU-early-termination-correctly.patch
>>>>>>>>> patches/revert-wireless-patches/0026-Revert-ath5k-Debug-DMA-timeouts.patch
>>>>>>>>> patches/revert-wireless-patches/0027-Revert-ath5k-Use-new-dma_stop-function-on-base.c.patch
>>>>>>>>> patches/revert-wireless-patches/0028-Revert-ath5k-Stop-PCU-on-reset.patch
>>>>>>>>> patches/revert-wireless-patches/0029-Revert-ath5k-Add-new-function-to-stop-rx-tx-DMA.patch
>>>>>>>>> patches/revert-wireless-patches/0030-Revert-ath5k-Reset-cleanup-and-generic-cleanup.patch
>>>>>>>>>
>>>>>>>>
>>>>>>>> OK this doesn't make any sense, based on your logs you have an
>>>>>>>> AR5212+RF5111+RF2111 combination, synth-only channel change (0008) is
>>>>>>>> only executed on AR2413 and AR5413 so you don't even run that code,
>>>>>>>> setting turbo flag on DCU (0014) is also unrelated since we never
>>>>>>>> enable turbo mode and if we did you wouldn't be able to receive
>>>>>>>> anything non-turbo.
>>>>>>>>
>>>>>>>> I am going to test 2 cards like yours a CM6 and an older one from
>>>>>>>> Atheros and come back to you ASAP...
>>>>>>>>
>>>>>>>
>>>>>>> I just reproduced it on a CM6 and a CM9 (AR5212 + RF5112), problem
>>>>>>> occurs when card is idle (no traffic) that's why my automated test
>>>>>>> didn't catch it I can still run iperf after connecting and leave it
>>>>>>> running without problems, when traffic stops it soon gets
>>>>>>> disconnected. I suspect it's something related to IFS timings/ACK
>>>>>>> timeout (0013 on your reverted series), maybe Jonathan Guerin was
>>>>>>> correct about ACK timeout...
>>>>>>>
>>>>>>> I'll try something and come back to you with code ;-)
>>>>>>>
>>>>>>> Thanks for reporting !
>>>>>>>
>>>>>>
>>>>>> Nope, it's PHY related and only affects RF5111/RF5112, AR2413 and
>>>>>> above work fine...
>>>>>>
>>>>>
>>>>> Got it, patch on the way...
>>>>>
>>>>
>>>> First the problem is with patch 22 (0009), we still need to write the
>>>> power table on hw, that fixes transmission and my CM9 works just fine
>>>> after that. Now my 2 RF5111 based cards seem to also have some problem
>>>> with stuck tx queues, after some time of fine operation (nearly
>>>> 28Mbits with iperf). It might be a hw failure or something but i want
>>>> to try and debug this further in case there is something i can do to
>>>> fix it. I also found some other things, eg. i report RX dma stop
>>>> failure when i shouldn't etc. Anyway back to debuging ;-)
>>>>
>>>>
>>>> --
>>>> GPG ID: 0xD21DB2DB
>>>> As you read this post global entropy rises. Have Fun ;-)
>>>> Nick
>>>>
>>>
>>> Done, works fine for me now, check it out ;-)
>>>
>>> --
>>> GPG ID: 0xD21DB2DB
>>> As you read this post global entropy rises. Have Fun ;-)
>>> Nick
>>>
>>
>> Hi Nick,
>>
>> I have applied the 6 patches you sent to linux-wireless list.
>>
>> $ cd $HOME/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none
>>
>> $ cat .pc/applied-patches
>> from_nkossifidis/1-6-ath5k-Always-write-tx-powertable-on-hw.patch
>> from_nkossifidis/2-6-ath5k-Always-free-tx-buffers-before-reset.patch
>> from_nkossifidis/3-6-ath5k-Disable-ANI-during-reset.patch
>> from_nkossifidis/4-6-ath5k-Fix-reporting-of-RX-dma-stop-failure.patch
>> from_nkossifidis/5-6-ath5k-Update-version-string.patch
>> from_nkossifidis/6-6-ath5k-Include-tx-ack-reporting-on-hw-flags.patch
>>
>> No more disconnects and no more audio-dropouts when listening to live-radio.
>> A big big big thank you!
>>
>> Shall I add to each of your patches a "Tested-by: Sedat Dilek
>> <[email protected]>?
>>
>> Kind Regards,
>> - Sedat -
>>
>
> Sure, again thanks a lot for reporting this and testing ;-)
>
> --
> GPG ID: 0xD21DB2DB
> As you read this post global entropy rises. Have Fun ;-)
> Nick
>
Hi Nick, Hi John,
Hey, approx 48hrs to get this fixed is quite good!
Can the patchset go into wireless-next-2.6?
As you remember I am on linux-next and discovered the bug from there.
OK, next linux-next refresh will be on Monday...
Regards,
- Sedat -
On Fri, Dec 3, 2010 at 7:15 AM, Sedat Dilek <[email protected]> wrote:
> On Fri, Dec 3, 2010 at 5:16 AM, Nick Kossifidis <[email protected]> wrote:
>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>>>>> 2010/12/2 Sedat Dilek <[email protected]>:
>>>>>>>> On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
>>>>>>>>> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I have built today a linux-next (next-20101201) kernel which includes
>>>>>>>>>> wireless-next-2.6 up to master-2010-11-30.
>>>>>>>> [...]
>>>>>>>>>> Unfortunately, my wlan network connection is totally unstable.
>>>>>>>> [...]
>>>>>>>>> 1.) For identification of the chipset, please:
>>>>>>>>> dmesg |grep "ath5.*chip"
>>>>>>>>>
>>>>>>>>> 2.) Is there a problem when you don't use encryption?
>>>>>>>>>
>>>>>>>>> 3.) git bisect might help track it down.
>>>>>>>>>
>>>>>>>>> bruno
>>>>>>>>
>>>>>>>> OK, I did not a "classic" git-bisect, I created from linux-next
>>>>>>>> (next-20101202) GIT tree a revert-ath5k patchset (30 in total).
>>>>>>>>
>>>>>>>> [1] VERY GOOD: Revertiing all 30 patches
>>>>>>>>
>>>>>>>> ...leads to a stable system.
>>>>>>>>
>>>>>>>> [2] REDUCED DISCONNECTIONS DROPS: Reverting 0001..0008
>>>>>>>>
>>>>>>>> This stabilizes the system, but... listening to a radio
>>>>>>>> broadcast-stream with VLC is a pain in the ass... permanent audio
>>>>>>>> dropouts. I had only 2 disconnections in the first 10mins when system
>>>>>>>> was up (normally I can see disconnects after loggin into my KDE
>>>>>>>> desktop).
>>>>>>>>
>>>>>>>> [3] GOOD AUDIO STREAMING: Reverting 0001..0014
>>>>>>>>
>>>>>>>> This is just fine, system like I am used to.
>>>>>>>>
>>>>>>>> [4] CONCLUSION
>>>>>>>>
>>>>>>>> So I played a bit with my revert-patchset.
>>>>>>>>
>>>>>>>> Reverting 0001..0008 + a refreshed v2 of
>>>>>>>> 0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch (patch attached) is
>>>>>>>> doing the job here.
>>>>>>>>
>>>>>>>> Having a closer look into 0008 (parts of
>>>>>>>> drivers/net/wireless/ath/ath5k/reset.c):
>>>>>>>>
>>>>>>>> $ grep AR5212 patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>>>>> - if (ah->ah_version == AR5K_AR5212)
>>>>>>>> + * On AR5212 TSF is almost preserved across a
>>>>>>>> - * On AR5212 TSF is almost preserved across a
>>>>>>>> + if (ah->ah_version == AR5K_AR5212) {
>>>>>>>> - if (ah->ah_version == AR5K_AR5212 &&
>>>>>>>>
>>>>>>>> As I mentionned I have a AR5212 wlan device!
>>>>>>>> What to do with that parts?
>>>>>>>> Any idea?
>>>>>>>>
>>>>>>>> Kind Regards,
>>>>>>>> - Sedat -
>>>>>>>>
>>>>>>>> P.S.: I have added a list containing all commit-ids (chronological)
>>>>>>>> and a script how I reverted (documenting for myself).
>>>>>>>>
>>>>>>>> $ ls patches/revert-wireless-patches/00*.patch
>>>>>>>> patches/revert-wireless-patches/0001-Revert-ath5k-Set-turbo-bit-on-rf-bank-2.patch
>>>>>>>> patches/revert-wireless-patches/0002-Revert-ath5k-Clean-up-turbo-mode-initvals-rfregs.patch
>>>>>>>> patches/revert-wireless-patches/0003-Revert-ath5k-Cleanup-turbo-channel-flags.patch
>>>>>>>> patches/revert-wireless-patches/0004-Revert-ath5k-Use-correct-clock-when-setting-ofdm-tim.patch
>>>>>>>> patches/revert-wireless-patches/0005-Revert-ath5k-Skip-tx-power-setting-on-AR5210-for-now.patch
>>>>>>>> patches/revert-wireless-patches/0006-Revert-ath5k-Tweak-phy-activate-to-rx-start-delay-ba.patch
>>>>>>>> patches/revert-wireless-patches/0007-Revert-ath5k-No-need-to-save-restore-staid-flags-on-.patch
>>>>>>>> patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>>>>> patches/revert-wireless-patches/0009-Revert-ath5k-Skip-powertable-setting-when-we-are-on-.patch
>>>>>>>> patches/revert-wireless-patches/0010-Revert-ath5k-Update-PLL-programming-for-turbo-half-q.patch
>>>>>>>> patches/revert-wireless-patches/0011-Revert-ath5k-Update-spur-mitigation-filter-for-turbo.patch
>>>>>>>> patches/revert-wireless-patches/0012-Revert-ath5k-Tweak-power-detector-delays-on-RF5111-R.patch
>>>>>>>> patches/revert-wireless-patches/0013-Revert-ath5k-Always-set-IFS-intervals-on-reset.patch
>>>>>>>> patches/revert-wireless-patches/0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch
>>>>>>>> patches/revert-wireless-patches/0015-Revert-ath5k-Set-all-IFS-intervals-not-just-slot-tim.patch
>>>>>>>> patches/revert-wireless-patches/0016-Revert-ath5k-Extend-rate_duration.patch
>>>>>>>> patches/revert-wireless-patches/0017-Revert-ath5k-Extend-get_default_sifs-slot_time.patch
>>>>>>>> patches/revert-wireless-patches/0018-Revert-ath5k-Move-tx-retries-setting-outside-reset_t.patch
>>>>>>>> patches/revert-wireless-patches/0019-Revert-ath5k-Increase-PHY-settling-parameters-for-tu.patch
>>>>>>>> patches/revert-wireless-patches/0020-Revert-ath5k-Small-cleanup-on-tweak_initvals.patch
>>>>>>>> patches/revert-wireless-patches/0021-Revert-ath5k-Put-core-clock-initialization-on-a-new-.patch
>>>>>>>> patches/revert-wireless-patches/0022-Revert-ath5k-Add-new-field-on-ath5k_hw-to-track-band.patch
>>>>>>>> patches/revert-wireless-patches/0023-Revert-ath5k-Use-new-function-to-stop-beacon-queue.patch
>>>>>>>> patches/revert-wireless-patches/0024-Revert-ath5k-Check-RXE-when-setting-RXDP.patch
>>>>>>>> patches/revert-wireless-patches/0025-Revert-ath5k-Use-DCU-early-termination-correctly.patch
>>>>>>>> patches/revert-wireless-patches/0026-Revert-ath5k-Debug-DMA-timeouts.patch
>>>>>>>> patches/revert-wireless-patches/0027-Revert-ath5k-Use-new-dma_stop-function-on-base.c.patch
>>>>>>>> patches/revert-wireless-patches/0028-Revert-ath5k-Stop-PCU-on-reset.patch
>>>>>>>> patches/revert-wireless-patches/0029-Revert-ath5k-Add-new-function-to-stop-rx-tx-DMA.patch
>>>>>>>> patches/revert-wireless-patches/0030-Revert-ath5k-Reset-cleanup-and-generic-cleanup.patch
>>>>>>>>
>>>>>>>
>>>>>>> OK this doesn't make any sense, based on your logs you have an
>>>>>>> AR5212+RF5111+RF2111 combination, synth-only channel change (0008) is
>>>>>>> only executed on AR2413 and AR5413 so you don't even run that code,
>>>>>>> setting turbo flag on DCU (0014) is also unrelated since we never
>>>>>>> enable turbo mode and if we did you wouldn't be able to receive
>>>>>>> anything non-turbo.
>>>>>>>
>>>>>>> I am going to test 2 cards like yours a CM6 and an older one from
>>>>>>> Atheros and come back to you ASAP...
>>>>>>>
>>>>>>
>>>>>> I just reproduced it on a CM6 and a CM9 (AR5212 + RF5112), problem
>>>>>> occurs when card is idle (no traffic) that's why my automated test
>>>>>> didn't catch it I can still run iperf after connecting and leave it
>>>>>> running without problems, when traffic stops it soon gets
>>>>>> disconnected. I suspect it's something related to IFS timings/ACK
>>>>>> timeout (0013 on your reverted series), maybe Jonathan Guerin was
>>>>>> correct about ACK timeout...
>>>>>>
>>>>>> I'll try something and come back to you with code ;-)
>>>>>>
>>>>>> Thanks for reporting !
>>>>>>
>>>>>
>>>>> Nope, it's PHY related and only affects RF5111/RF5112, AR2413 and
>>>>> above work fine...
>>>>>
>>>>
>>>> Got it, patch on the way...
>>>>
>>>
>>> First the problem is with patch 22 (0009), we still need to write the
>>> power table on hw, that fixes transmission and my CM9 works just fine
>>> after that. Now my 2 RF5111 based cards seem to also have some problem
>>> with stuck tx queues, after some time of fine operation (nearly
>>> 28Mbits with iperf). It might be a hw failure or something but i want
>>> to try and debug this further in case there is something i can do to
>>> fix it. I also found some other things, eg. i report RX dma stop
>>> failure when i shouldn't etc. Anyway back to debuging ;-)
>>>
>>>
>>> --
>>> GPG ID: 0xD21DB2DB
>>> As you read this post global entropy rises. Have Fun ;-)
>>> Nick
>>>
>>
>> Done, works fine for me now, check it out ;-)
>>
>> --
>> GPG ID: 0xD21DB2DB
>> As you read this post global entropy rises. Have Fun ;-)
>> Nick
>>
>
> Hi Nick,
>
> I have applied the 6 patches you sent to linux-wireless list.
>
> $ cd $HOME/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none
>
> $ cat .pc/applied-patches
> from_nkossifidis/1-6-ath5k-Always-write-tx-powertable-on-hw.patch
> from_nkossifidis/2-6-ath5k-Always-free-tx-buffers-before-reset.patch
> from_nkossifidis/3-6-ath5k-Disable-ANI-during-reset.patch
> from_nkossifidis/4-6-ath5k-Fix-reporting-of-RX-dma-stop-failure.patch
> from_nkossifidis/5-6-ath5k-Update-version-string.patch
> from_nkossifidis/6-6-ath5k-Include-tx-ack-reporting-on-hw-flags.patch
>
> No more disconnects and no more audio-dropouts when listening to live-radio.
> A big big big thank you!
>
> Shall I add to each of your patches a "Tested-by: Sedat Dilek
> <[email protected]>?
>
> Kind Regards,
> - Sedat -
>
Bitrates now seem to be fine, too (36-48MBps).
- Sedat -
# iw dev wlan0 station dump
Station 00:04:0e:e4:00:3d (on wlan0)
inactive time: 12 ms
rx bytes: 16446860
rx packets: 36582
tx bytes: 1353803
tx packets: 14138
signal: -60 dBm
tx bitrate: 36.0 MBit/s
# iw dev wlan0 station dump
Station 00:04:0e:e4:00:3d (on wlan0)
inactive time: 72 ms
rx bytes: 16459615
rx packets: 36613
tx bytes: 1354835
tx packets: 14150
signal: -60 dBm
tx bitrate: 48.0 MBit/s
2010/12/2 Nick Kossifidis <[email protected]>:
> 2010/12/2 Nick Kossifidis <[email protected]>:
>> 2010/12/2 Sedat Dilek <[email protected]>:
>>> On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
>>>> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>>>>> Hi,
>>>>>
>>>>> I have built today a linux-next (next-20101201) kernel which includes
>>>>> wireless-next-2.6 up to master-2010-11-30.
>>> [...]
>>>>> Unfortunately, my wlan network connection is totally unstable.
>>> [...]
>>>> 1.) For identification of the chipset, please:
>>>> dmesg |grep "ath5.*chip"
>>>>
>>>> 2.) Is there a problem when you don't use encryption?
>>>>
>>>> 3.) git bisect might help track it down.
>>>>
>>>> bruno
>>>
>>> OK, I did not a "classic" git-bisect, I created from linux-next
>>> (next-20101202) GIT tree a revert-ath5k patchset (30 in total).
>>>
>>> [1] VERY GOOD: Revertiing all 30 patches
>>>
>>> ...leads to a stable system.
>>>
>>> [2] REDUCED DISCONNECTIONS DROPS: Reverting 0001..0008
>>>
>>> This stabilizes the system, but... listening to a radio
>>> broadcast-stream with VLC is a pain in the ass... permanent audio
>>> dropouts. I had only 2 disconnections in the first 10mins when system
>>> was up (normally I can see disconnects after loggin into my KDE
>>> desktop).
>>>
>>> [3] GOOD AUDIO STREAMING: Reverting 0001..0014
>>>
>>> This is just fine, system like I am used to.
>>>
>>> [4] CONCLUSION
>>>
>>> So I played a bit with my revert-patchset.
>>>
>>> Reverting 0001..0008 + a refreshed v2 of
>>> 0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch (patch attached) is
>>> doing the job here.
>>>
>>> Having a closer look into 0008 (parts of
>>> drivers/net/wireless/ath/ath5k/reset.c):
>>>
>>> $ grep AR5212 patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>> - if (ah->ah_version == AR5K_AR5212)
>>> + * On AR5212 TSF is almost preserved across a
>>> - * On AR5212 TSF is almost preserved across a
>>> + if (ah->ah_version == AR5K_AR5212) {
>>> - if (ah->ah_version == AR5K_AR5212 &&
>>>
>>> As I mentionned I have a AR5212 wlan device!
>>> What to do with that parts?
>>> Any idea?
>>>
>>> Kind Regards,
>>> - Sedat -
>>>
>>> P.S.: I have added a list containing all commit-ids (chronological)
>>> and a script how I reverted (documenting for myself).
>>>
>>> $ ls patches/revert-wireless-patches/00*.patch
>>> patches/revert-wireless-patches/0001-Revert-ath5k-Set-turbo-bit-on-rf-bank-2.patch
>>> patches/revert-wireless-patches/0002-Revert-ath5k-Clean-up-turbo-mode-initvals-rfregs.patch
>>> patches/revert-wireless-patches/0003-Revert-ath5k-Cleanup-turbo-channel-flags.patch
>>> patches/revert-wireless-patches/0004-Revert-ath5k-Use-correct-clock-when-setting-ofdm-tim.patch
>>> patches/revert-wireless-patches/0005-Revert-ath5k-Skip-tx-power-setting-on-AR5210-for-now.patch
>>> patches/revert-wireless-patches/0006-Revert-ath5k-Tweak-phy-activate-to-rx-start-delay-ba.patch
>>> patches/revert-wireless-patches/0007-Revert-ath5k-No-need-to-save-restore-staid-flags-on-.patch
>>> patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>> patches/revert-wireless-patches/0009-Revert-ath5k-Skip-powertable-setting-when-we-are-on-.patch
>>> patches/revert-wireless-patches/0010-Revert-ath5k-Update-PLL-programming-for-turbo-half-q.patch
>>> patches/revert-wireless-patches/0011-Revert-ath5k-Update-spur-mitigation-filter-for-turbo.patch
>>> patches/revert-wireless-patches/0012-Revert-ath5k-Tweak-power-detector-delays-on-RF5111-R.patch
>>> patches/revert-wireless-patches/0013-Revert-ath5k-Always-set-IFS-intervals-on-reset.patch
>>> patches/revert-wireless-patches/0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch
>>> patches/revert-wireless-patches/0015-Revert-ath5k-Set-all-IFS-intervals-not-just-slot-tim.patch
>>> patches/revert-wireless-patches/0016-Revert-ath5k-Extend-rate_duration.patch
>>> patches/revert-wireless-patches/0017-Revert-ath5k-Extend-get_default_sifs-slot_time.patch
>>> patches/revert-wireless-patches/0018-Revert-ath5k-Move-tx-retries-setting-outside-reset_t.patch
>>> patches/revert-wireless-patches/0019-Revert-ath5k-Increase-PHY-settling-parameters-for-tu.patch
>>> patches/revert-wireless-patches/0020-Revert-ath5k-Small-cleanup-on-tweak_initvals.patch
>>> patches/revert-wireless-patches/0021-Revert-ath5k-Put-core-clock-initialization-on-a-new-.patch
>>> patches/revert-wireless-patches/0022-Revert-ath5k-Add-new-field-on-ath5k_hw-to-track-band.patch
>>> patches/revert-wireless-patches/0023-Revert-ath5k-Use-new-function-to-stop-beacon-queue.patch
>>> patches/revert-wireless-patches/0024-Revert-ath5k-Check-RXE-when-setting-RXDP.patch
>>> patches/revert-wireless-patches/0025-Revert-ath5k-Use-DCU-early-termination-correctly.patch
>>> patches/revert-wireless-patches/0026-Revert-ath5k-Debug-DMA-timeouts.patch
>>> patches/revert-wireless-patches/0027-Revert-ath5k-Use-new-dma_stop-function-on-base.c.patch
>>> patches/revert-wireless-patches/0028-Revert-ath5k-Stop-PCU-on-reset.patch
>>> patches/revert-wireless-patches/0029-Revert-ath5k-Add-new-function-to-stop-rx-tx-DMA.patch
>>> patches/revert-wireless-patches/0030-Revert-ath5k-Reset-cleanup-and-generic-cleanup.patch
>>>
>>
>> OK this doesn't make any sense, based on your logs you have an
>> AR5212+RF5111+RF2111 combination, synth-only channel change (0008) is
>> only executed on AR2413 and AR5413 so you don't even run that code,
>> setting turbo flag on DCU (0014) is also unrelated since we never
>> enable turbo mode and if we did you wouldn't be able to receive
>> anything non-turbo.
>>
>> I am going to test 2 cards like yours a CM6 and an older one from
>> Atheros and come back to you ASAP...
>>
>
> I just reproduced it on a CM6 and a CM9 (AR5212 + RF5112), problem
> occurs when card is idle (no traffic) that's why my automated test
> didn't catch it I can still run iperf after connecting and leave it
> running without problems, when traffic stops it soon gets
> disconnected. I suspect it's something related to IFS timings/ACK
> timeout (0013 on your reverted series), maybe Jonathan Guerin was
> correct about ACK timeout...
>
> I'll try something and come back to you with code ;-)
>
> Thanks for reporting !
>
Nope, it's PHY related and only affects RF5111/RF5112, AR2413 and
above work fine...
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>> Hi,
>>
>> I have built today a linux-next (next-20101201) kernel which includes
>> wireless-next-2.6 up to master-2010-11-30.
[...]
>> Unfortunately, my wlan network connection is totally unstable.
[...]
> 1.) For identification of the chipset, please:
> dmesg |grep "ath5.*chip"
>
> 2.) Is there a problem when you don't use encryption?
>
> 3.) git bisect might help track it down.
>
> bruno
OK, I did not a "classic" git-bisect, I created from linux-next
(next-20101202) GIT tree a revert-ath5k patchset (30 in total).
[1] VERY GOOD: Revertiing all 30 patches
...leads to a stable system.
[2] REDUCED DISCONNECTIONS DROPS: Reverting 0001..0008
This stabilizes the system, but... listening to a radio
broadcast-stream with VLC is a pain in the ass... permanent audio
dropouts. I had only 2 disconnections in the first 10mins when system
was up (normally I can see disconnects after loggin into my KDE
desktop).
[3] GOOD AUDIO STREAMING: Reverting 0001..0014
This is just fine, system like I am used to.
[4] CONCLUSION
So I played a bit with my revert-patchset.
Reverting 0001..0008 + a refreshed v2 of
0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch (patch attached) is
doing the job here.
Having a closer look into 0008 (parts of
drivers/net/wireless/ath/ath5k/reset.c):
$ grep AR5212 patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
- if (ah->ah_version == AR5K_AR5212)
+ * On AR5212 TSF is almost preserved across a
- * On AR5212 TSF is almost preserved across a
+ if (ah->ah_version == AR5K_AR5212) {
- if (ah->ah_version == AR5K_AR5212 &&
As I mentionned I have a AR5212 wlan device!
What to do with that parts?
Any idea?
Kind Regards,
- Sedat -
P.S.: I have added a list containing all commit-ids (chronological)
and a script how I reverted (documenting for myself).
$ ls patches/revert-wireless-patches/00*.patch
patches/revert-wireless-patches/0001-Revert-ath5k-Set-turbo-bit-on-rf-bank-2.patch
patches/revert-wireless-patches/0002-Revert-ath5k-Clean-up-turbo-mode-initvals-rfregs.patch
patches/revert-wireless-patches/0003-Revert-ath5k-Cleanup-turbo-channel-flags.patch
patches/revert-wireless-patches/0004-Revert-ath5k-Use-correct-clock-when-setting-ofdm-tim.patch
patches/revert-wireless-patches/0005-Revert-ath5k-Skip-tx-power-setting-on-AR5210-for-now.patch
patches/revert-wireless-patches/0006-Revert-ath5k-Tweak-phy-activate-to-rx-start-delay-ba.patch
patches/revert-wireless-patches/0007-Revert-ath5k-No-need-to-save-restore-staid-flags-on-.patch
patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
patches/revert-wireless-patches/0009-Revert-ath5k-Skip-powertable-setting-when-we-are-on-.patch
patches/revert-wireless-patches/0010-Revert-ath5k-Update-PLL-programming-for-turbo-half-q.patch
patches/revert-wireless-patches/0011-Revert-ath5k-Update-spur-mitigation-filter-for-turbo.patch
patches/revert-wireless-patches/0012-Revert-ath5k-Tweak-power-detector-delays-on-RF5111-R.patch
patches/revert-wireless-patches/0013-Revert-ath5k-Always-set-IFS-intervals-on-reset.patch
patches/revert-wireless-patches/0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch
patches/revert-wireless-patches/0015-Revert-ath5k-Set-all-IFS-intervals-not-just-slot-tim.patch
patches/revert-wireless-patches/0016-Revert-ath5k-Extend-rate_duration.patch
patches/revert-wireless-patches/0017-Revert-ath5k-Extend-get_default_sifs-slot_time.patch
patches/revert-wireless-patches/0018-Revert-ath5k-Move-tx-retries-setting-outside-reset_t.patch
patches/revert-wireless-patches/0019-Revert-ath5k-Increase-PHY-settling-parameters-for-tu.patch
patches/revert-wireless-patches/0020-Revert-ath5k-Small-cleanup-on-tweak_initvals.patch
patches/revert-wireless-patches/0021-Revert-ath5k-Put-core-clock-initialization-on-a-new-.patch
patches/revert-wireless-patches/0022-Revert-ath5k-Add-new-field-on-ath5k_hw-to-track-band.patch
patches/revert-wireless-patches/0023-Revert-ath5k-Use-new-function-to-stop-beacon-queue.patch
patches/revert-wireless-patches/0024-Revert-ath5k-Check-RXE-when-setting-RXDP.patch
patches/revert-wireless-patches/0025-Revert-ath5k-Use-DCU-early-termination-correctly.patch
patches/revert-wireless-patches/0026-Revert-ath5k-Debug-DMA-timeouts.patch
patches/revert-wireless-patches/0027-Revert-ath5k-Use-new-dma_stop-function-on-base.c.patch
patches/revert-wireless-patches/0028-Revert-ath5k-Stop-PCU-on-reset.patch
patches/revert-wireless-patches/0029-Revert-ath5k-Add-new-function-to-stop-rx-tx-DMA.patch
patches/revert-wireless-patches/0030-Revert-ath5k-Reset-cleanup-and-generic-cleanup.patch
On Fri, Dec 3, 2010 at 5:16 AM, Nick Kossifidis <[email protected]> wrote:
> 2010/12/3 Nick Kossifidis <[email protected]>:
>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>>>> 2010/12/2 Sedat Dilek <[email protected]>:
>>>>>>> On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
>>>>>>>> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I have built today a linux-next (next-20101201) kernel which includes
>>>>>>>>> wireless-next-2.6 up to master-2010-11-30.
>>>>>>> [...]
>>>>>>>>> Unfortunately, my wlan network connection is totally unstable.
>>>>>>> [...]
>>>>>>>> 1.) For identification of the chipset, please:
>>>>>>>> dmesg |grep "ath5.*chip"
>>>>>>>>
>>>>>>>> 2.) Is there a problem when you don't use encryption?
>>>>>>>>
>>>>>>>> 3.) git bisect might help track it down.
>>>>>>>>
>>>>>>>> bruno
>>>>>>>
>>>>>>> OK, I did not a "classic" git-bisect, I created from linux-next
>>>>>>> (next-20101202) GIT tree a revert-ath5k patchset (30 in total).
>>>>>>>
>>>>>>> [1] VERY GOOD: Revertiing all 30 patches
>>>>>>>
>>>>>>> ...leads to a stable system.
>>>>>>>
>>>>>>> [2] REDUCED DISCONNECTIONS DROPS: Reverting 0001..0008
>>>>>>>
>>>>>>> This stabilizes the system, but... listening to a radio
>>>>>>> broadcast-stream with VLC is a pain in the ass... permanent audio
>>>>>>> dropouts. I had only 2 disconnections in the first 10mins when system
>>>>>>> was up (normally I can see disconnects after loggin into my KDE
>>>>>>> desktop).
>>>>>>>
>>>>>>> [3] GOOD AUDIO STREAMING: Reverting 0001..0014
>>>>>>>
>>>>>>> This is just fine, system like I am used to.
>>>>>>>
>>>>>>> [4] CONCLUSION
>>>>>>>
>>>>>>> So I played a bit with my revert-patchset.
>>>>>>>
>>>>>>> Reverting 0001..0008 + a refreshed v2 of
>>>>>>> 0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch (patch attached) is
>>>>>>> doing the job here.
>>>>>>>
>>>>>>> Having a closer look into 0008 (parts of
>>>>>>> drivers/net/wireless/ath/ath5k/reset.c):
>>>>>>>
>>>>>>> $ grep AR5212 patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>>>> - if (ah->ah_version == AR5K_AR5212)
>>>>>>> + * On AR5212 TSF is almost preserved across a
>>>>>>> - * On AR5212 TSF is almost preserved across a
>>>>>>> + if (ah->ah_version == AR5K_AR5212) {
>>>>>>> - if (ah->ah_version == AR5K_AR5212 &&
>>>>>>>
>>>>>>> As I mentionned I have a AR5212 wlan device!
>>>>>>> What to do with that parts?
>>>>>>> Any idea?
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>> - Sedat -
>>>>>>>
>>>>>>> P.S.: I have added a list containing all commit-ids (chronological)
>>>>>>> and a script how I reverted (documenting for myself).
>>>>>>>
>>>>>>> $ ls patches/revert-wireless-patches/00*.patch
>>>>>>> patches/revert-wireless-patches/0001-Revert-ath5k-Set-turbo-bit-on-rf-bank-2.patch
>>>>>>> patches/revert-wireless-patches/0002-Revert-ath5k-Clean-up-turbo-mode-initvals-rfregs.patch
>>>>>>> patches/revert-wireless-patches/0003-Revert-ath5k-Cleanup-turbo-channel-flags.patch
>>>>>>> patches/revert-wireless-patches/0004-Revert-ath5k-Use-correct-clock-when-setting-ofdm-tim.patch
>>>>>>> patches/revert-wireless-patches/0005-Revert-ath5k-Skip-tx-power-setting-on-AR5210-for-now.patch
>>>>>>> patches/revert-wireless-patches/0006-Revert-ath5k-Tweak-phy-activate-to-rx-start-delay-ba.patch
>>>>>>> patches/revert-wireless-patches/0007-Revert-ath5k-No-need-to-save-restore-staid-flags-on-.patch
>>>>>>> patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>>>> patches/revert-wireless-patches/0009-Revert-ath5k-Skip-powertable-setting-when-we-are-on-.patch
>>>>>>> patches/revert-wireless-patches/0010-Revert-ath5k-Update-PLL-programming-for-turbo-half-q.patch
>>>>>>> patches/revert-wireless-patches/0011-Revert-ath5k-Update-spur-mitigation-filter-for-turbo.patch
>>>>>>> patches/revert-wireless-patches/0012-Revert-ath5k-Tweak-power-detector-delays-on-RF5111-R.patch
>>>>>>> patches/revert-wireless-patches/0013-Revert-ath5k-Always-set-IFS-intervals-on-reset.patch
>>>>>>> patches/revert-wireless-patches/0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch
>>>>>>> patches/revert-wireless-patches/0015-Revert-ath5k-Set-all-IFS-intervals-not-just-slot-tim.patch
>>>>>>> patches/revert-wireless-patches/0016-Revert-ath5k-Extend-rate_duration.patch
>>>>>>> patches/revert-wireless-patches/0017-Revert-ath5k-Extend-get_default_sifs-slot_time.patch
>>>>>>> patches/revert-wireless-patches/0018-Revert-ath5k-Move-tx-retries-setting-outside-reset_t.patch
>>>>>>> patches/revert-wireless-patches/0019-Revert-ath5k-Increase-PHY-settling-parameters-for-tu.patch
>>>>>>> patches/revert-wireless-patches/0020-Revert-ath5k-Small-cleanup-on-tweak_initvals.patch
>>>>>>> patches/revert-wireless-patches/0021-Revert-ath5k-Put-core-clock-initialization-on-a-new-.patch
>>>>>>> patches/revert-wireless-patches/0022-Revert-ath5k-Add-new-field-on-ath5k_hw-to-track-band.patch
>>>>>>> patches/revert-wireless-patches/0023-Revert-ath5k-Use-new-function-to-stop-beacon-queue.patch
>>>>>>> patches/revert-wireless-patches/0024-Revert-ath5k-Check-RXE-when-setting-RXDP.patch
>>>>>>> patches/revert-wireless-patches/0025-Revert-ath5k-Use-DCU-early-termination-correctly.patch
>>>>>>> patches/revert-wireless-patches/0026-Revert-ath5k-Debug-DMA-timeouts.patch
>>>>>>> patches/revert-wireless-patches/0027-Revert-ath5k-Use-new-dma_stop-function-on-base.c.patch
>>>>>>> patches/revert-wireless-patches/0028-Revert-ath5k-Stop-PCU-on-reset.patch
>>>>>>> patches/revert-wireless-patches/0029-Revert-ath5k-Add-new-function-to-stop-rx-tx-DMA.patch
>>>>>>> patches/revert-wireless-patches/0030-Revert-ath5k-Reset-cleanup-and-generic-cleanup.patch
>>>>>>>
>>>>>>
>>>>>> OK this doesn't make any sense, based on your logs you have an
>>>>>> AR5212+RF5111+RF2111 combination, synth-only channel change (0008) is
>>>>>> only executed on AR2413 and AR5413 so you don't even run that code,
>>>>>> setting turbo flag on DCU (0014) is also unrelated since we never
>>>>>> enable turbo mode and if we did you wouldn't be able to receive
>>>>>> anything non-turbo.
>>>>>>
>>>>>> I am going to test 2 cards like yours a CM6 and an older one from
>>>>>> Atheros and come back to you ASAP...
>>>>>>
>>>>>
>>>>> I just reproduced it on a CM6 and a CM9 (AR5212 + RF5112), problem
>>>>> occurs when card is idle (no traffic) that's why my automated test
>>>>> didn't catch it I can still run iperf after connecting and leave it
>>>>> running without problems, when traffic stops it soon gets
>>>>> disconnected. I suspect it's something related to IFS timings/ACK
>>>>> timeout (0013 on your reverted series), maybe Jonathan Guerin was
>>>>> correct about ACK timeout...
>>>>>
>>>>> I'll try something and come back to you with code ;-)
>>>>>
>>>>> Thanks for reporting !
>>>>>
>>>>
>>>> Nope, it's PHY related and only affects RF5111/RF5112, AR2413 and
>>>> above work fine...
>>>>
>>>
>>> Got it, patch on the way...
>>>
>>
>> First the problem is with patch 22 (0009), we still need to write the
>> power table on hw, that fixes transmission and my CM9 works just fine
>> after that. Now my 2 RF5111 based cards seem to also have some problem
>> with stuck tx queues, after some time of fine operation (nearly
>> 28Mbits with iperf). It might be a hw failure or something but i want
>> to try and debug this further in case there is something i can do to
>> fix it. I also found some other things, eg. i report RX dma stop
>> failure when i shouldn't etc. Anyway back to debuging ;-)
>>
>>
>> --
>> GPG ID: 0xD21DB2DB
>> As you read this post global entropy rises. Have Fun ;-)
>> Nick
>>
>
> Done, works fine for me now, check it out ;-)
>
> --
> GPG ID: 0xD21DB2DB
> As you read this post global entropy rises. Have Fun ;-)
> Nick
>
Hi Nick,
I have applied the 6 patches you sent to linux-wireless list.
$ cd $HOME/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none
$ cat .pc/applied-patches
from_nkossifidis/1-6-ath5k-Always-write-tx-powertable-on-hw.patch
from_nkossifidis/2-6-ath5k-Always-free-tx-buffers-before-reset.patch
from_nkossifidis/3-6-ath5k-Disable-ANI-during-reset.patch
from_nkossifidis/4-6-ath5k-Fix-reporting-of-RX-dma-stop-failure.patch
from_nkossifidis/5-6-ath5k-Update-version-string.patch
from_nkossifidis/6-6-ath5k-Include-tx-ack-reporting-on-hw-flags.patch
No more disconnects and no more audio-dropouts when listening to live-radio.
A big big big thank you!
Shall I add to each of your patches a "Tested-by: Sedat Dilek
<[email protected]>?
Kind Regards,
- Sedat -
2010/12/3 Sedat Dilek <[email protected]>:
> On Fri, Dec 3, 2010 at 5:16 AM, Nick Kossifidis <[email protected]> wrote:
>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>>> 2010/12/3 Nick Kossifidis <[email protected]>:
>>>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>>>> 2010/12/2 Nick Kossifidis <[email protected]>:
>>>>>>> 2010/12/2 Sedat Dilek <[email protected]>:
>>>>>>>> On Wed, Dec 1, 2010 at 11:21 AM, Bruno Randolf <[email protected]> wrote:
>>>>>>>>> On Wed December 1 2010 19:09:03 Sedat Dilek wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I have built today a linux-next (next-20101201) kernel which includes
>>>>>>>>>> wireless-next-2.6 up to master-2010-11-30.
>>>>>>>> [...]
>>>>>>>>>> Unfortunately, my wlan network connection is totally unstable.
>>>>>>>> [...]
>>>>>>>>> 1.) For identification of the chipset, please:
>>>>>>>>> dmesg |grep "ath5.*chip"
>>>>>>>>>
>>>>>>>>> 2.) Is there a problem when you don't use encryption?
>>>>>>>>>
>>>>>>>>> 3.) git bisect might help track it down.
>>>>>>>>>
>>>>>>>>> bruno
>>>>>>>>
>>>>>>>> OK, I did not a "classic" git-bisect, I created from linux-next
>>>>>>>> (next-20101202) GIT tree a revert-ath5k patchset (30 in total).
>>>>>>>>
>>>>>>>> [1] VERY GOOD: Revertiing all 30 patches
>>>>>>>>
>>>>>>>> ...leads to a stable system.
>>>>>>>>
>>>>>>>> [2] REDUCED DISCONNECTIONS DROPS: Reverting 0001..0008
>>>>>>>>
>>>>>>>> This stabilizes the system, but... listening to a radio
>>>>>>>> broadcast-stream with VLC is a pain in the ass... permanent audio
>>>>>>>> dropouts. I had only 2 disconnections in the first 10mins when system
>>>>>>>> was up (normally I can see disconnects after loggin into my KDE
>>>>>>>> desktop).
>>>>>>>>
>>>>>>>> [3] GOOD AUDIO STREAMING: Reverting 0001..0014
>>>>>>>>
>>>>>>>> This is just fine, system like I am used to.
>>>>>>>>
>>>>>>>> [4] CONCLUSION
>>>>>>>>
>>>>>>>> So I played a bit with my revert-patchset.
>>>>>>>>
>>>>>>>> Reverting 0001..0008 + a refreshed v2 of
>>>>>>>> 0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch (patch attached) is
>>>>>>>> doing the job here.
>>>>>>>>
>>>>>>>> Having a closer look into 0008 (parts of
>>>>>>>> drivers/net/wireless/ath/ath5k/reset.c):
>>>>>>>>
>>>>>>>> $ grep AR5212 patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>>>>> - if (ah->ah_version == AR5K_AR5212)
>>>>>>>> + * On AR5212 TSF is almost preserved across a
>>>>>>>> - * On AR5212 TSF is almost preserved across a
>>>>>>>> + if (ah->ah_version == AR5K_AR5212) {
>>>>>>>> - if (ah->ah_version == AR5K_AR5212 &&
>>>>>>>>
>>>>>>>> As I mentionned I have a AR5212 wlan device!
>>>>>>>> What to do with that parts?
>>>>>>>> Any idea?
>>>>>>>>
>>>>>>>> Kind Regards,
>>>>>>>> - Sedat -
>>>>>>>>
>>>>>>>> P.S.: I have added a list containing all commit-ids (chronological)
>>>>>>>> and a script how I reverted (documenting for myself).
>>>>>>>>
>>>>>>>> $ ls patches/revert-wireless-patches/00*.patch
>>>>>>>> patches/revert-wireless-patches/0001-Revert-ath5k-Set-turbo-bit-on-rf-bank-2.patch
>>>>>>>> patches/revert-wireless-patches/0002-Revert-ath5k-Clean-up-turbo-mode-initvals-rfregs.patch
>>>>>>>> patches/revert-wireless-patches/0003-Revert-ath5k-Cleanup-turbo-channel-flags.patch
>>>>>>>> patches/revert-wireless-patches/0004-Revert-ath5k-Use-correct-clock-when-setting-ofdm-tim.patch
>>>>>>>> patches/revert-wireless-patches/0005-Revert-ath5k-Skip-tx-power-setting-on-AR5210-for-now.patch
>>>>>>>> patches/revert-wireless-patches/0006-Revert-ath5k-Tweak-phy-activate-to-rx-start-delay-ba.patch
>>>>>>>> patches/revert-wireless-patches/0007-Revert-ath5k-No-need-to-save-restore-staid-flags-on-.patch
>>>>>>>> patches/revert-wireless-patches/0008-Revert-ath5k-Support-synth-only-channel-change-for-A.patch
>>>>>>>> patches/revert-wireless-patches/0009-Revert-ath5k-Skip-powertable-setting-when-we-are-on-.patch
>>>>>>>> patches/revert-wireless-patches/0010-Revert-ath5k-Update-PLL-programming-for-turbo-half-q.patch
>>>>>>>> patches/revert-wireless-patches/0011-Revert-ath5k-Update-spur-mitigation-filter-for-turbo.patch
>>>>>>>> patches/revert-wireless-patches/0012-Revert-ath5k-Tweak-power-detector-delays-on-RF5111-R.patch
>>>>>>>> patches/revert-wireless-patches/0013-Revert-ath5k-Always-set-IFS-intervals-on-reset.patch
>>>>>>>> patches/revert-wireless-patches/0014-Revert-ath5k-Use-turbo-flag-on-DCU.patch
>>>>>>>> patches/revert-wireless-patches/0015-Revert-ath5k-Set-all-IFS-intervals-not-just-slot-tim.patch
>>>>>>>> patches/revert-wireless-patches/0016-Revert-ath5k-Extend-rate_duration.patch
>>>>>>>> patches/revert-wireless-patches/0017-Revert-ath5k-Extend-get_default_sifs-slot_time.patch
>>>>>>>> patches/revert-wireless-patches/0018-Revert-ath5k-Move-tx-retries-setting-outside-reset_t.patch
>>>>>>>> patches/revert-wireless-patches/0019-Revert-ath5k-Increase-PHY-settling-parameters-for-tu.patch
>>>>>>>> patches/revert-wireless-patches/0020-Revert-ath5k-Small-cleanup-on-tweak_initvals.patch
>>>>>>>> patches/revert-wireless-patches/0021-Revert-ath5k-Put-core-clock-initialization-on-a-new-.patch
>>>>>>>> patches/revert-wireless-patches/0022-Revert-ath5k-Add-new-field-on-ath5k_hw-to-track-band.patch
>>>>>>>> patches/revert-wireless-patches/0023-Revert-ath5k-Use-new-function-to-stop-beacon-queue.patch
>>>>>>>> patches/revert-wireless-patches/0024-Revert-ath5k-Check-RXE-when-setting-RXDP.patch
>>>>>>>> patches/revert-wireless-patches/0025-Revert-ath5k-Use-DCU-early-termination-correctly.patch
>>>>>>>> patches/revert-wireless-patches/0026-Revert-ath5k-Debug-DMA-timeouts.patch
>>>>>>>> patches/revert-wireless-patches/0027-Revert-ath5k-Use-new-dma_stop-function-on-base.c.patch
>>>>>>>> patches/revert-wireless-patches/0028-Revert-ath5k-Stop-PCU-on-reset.patch
>>>>>>>> patches/revert-wireless-patches/0029-Revert-ath5k-Add-new-function-to-stop-rx-tx-DMA.patch
>>>>>>>> patches/revert-wireless-patches/0030-Revert-ath5k-Reset-cleanup-and-generic-cleanup.patch
>>>>>>>>
>>>>>>>
>>>>>>> OK this doesn't make any sense, based on your logs you have an
>>>>>>> AR5212+RF5111+RF2111 combination, synth-only channel change (0008) is
>>>>>>> only executed on AR2413 and AR5413 so you don't even run that code,
>>>>>>> setting turbo flag on DCU (0014) is also unrelated since we never
>>>>>>> enable turbo mode and if we did you wouldn't be able to receive
>>>>>>> anything non-turbo.
>>>>>>>
>>>>>>> I am going to test 2 cards like yours a CM6 and an older one from
>>>>>>> Atheros and come back to you ASAP...
>>>>>>>
>>>>>>
>>>>>> I just reproduced it on a CM6 and a CM9 (AR5212 + RF5112), problem
>>>>>> occurs when card is idle (no traffic) that's why my automated test
>>>>>> didn't catch it I can still run iperf after connecting and leave it
>>>>>> running without problems, when traffic stops it soon gets
>>>>>> disconnected. I suspect it's something related to IFS timings/ACK
>>>>>> timeout (0013 on your reverted series), maybe Jonathan Guerin was
>>>>>> correct about ACK timeout...
>>>>>>
>>>>>> I'll try something and come back to you with code ;-)
>>>>>>
>>>>>> Thanks for reporting !
>>>>>>
>>>>>
>>>>> Nope, it's PHY related and only affects RF5111/RF5112, AR2413 and
>>>>> above work fine...
>>>>>
>>>>
>>>> Got it, patch on the way...
>>>>
>>>
>>> First the problem is with patch 22 (0009), we still need to write the
>>> power table on hw, that fixes transmission and my CM9 works just fine
>>> after that. Now my 2 RF5111 based cards seem to also have some problem
>>> with stuck tx queues, after some time of fine operation (nearly
>>> 28Mbits with iperf). It might be a hw failure or something but i want
>>> to try and debug this further in case there is something i can do to
>>> fix it. I also found some other things, eg. i report RX dma stop
>>> failure when i shouldn't etc. Anyway back to debuging ;-)
>>>
>>>
>>> --
>>> GPG ID: 0xD21DB2DB
>>> As you read this post global entropy rises. Have Fun ;-)
>>> Nick
>>>
>>
>> Done, works fine for me now, check it out ;-)
>>
>> --
>> GPG ID: 0xD21DB2DB
>> As you read this post global entropy rises. Have Fun ;-)
>> Nick
>>
>
> Hi Nick,
>
> I have applied the 6 patches you sent to linux-wireless list.
>
> $ cd $HOME/src/linux-2.6/linux-2.6.37-rc4/debian/build/source_i386_none
>
> $ cat .pc/applied-patches
> from_nkossifidis/1-6-ath5k-Always-write-tx-powertable-on-hw.patch
> from_nkossifidis/2-6-ath5k-Always-free-tx-buffers-before-reset.patch
> from_nkossifidis/3-6-ath5k-Disable-ANI-during-reset.patch
> from_nkossifidis/4-6-ath5k-Fix-reporting-of-RX-dma-stop-failure.patch
> from_nkossifidis/5-6-ath5k-Update-version-string.patch
> from_nkossifidis/6-6-ath5k-Include-tx-ack-reporting-on-hw-flags.patch
>
> No more disconnects and no more audio-dropouts when listening to live-radio.
> A big big big thank you!
>
> Shall I add to each of your patches a "Tested-by: Sedat Dilek
> <[email protected]>?
>
> Kind Regards,
> - Sedat -
>
Sure, again thanks a lot for reporting this and testing ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick