[ath9k-devel] ath9k buggy in 2.6.31-rc7

[ath9k-devel] ath9k buggy in 2.6.31-rc7

[Thomas Backlund]

Hi,

I'm tracking a bug in ath9k in 2.6.31-rc7 series, and have been 
cherrypicking patches from wireless-testing to try to get a stable ath9k...

The problem is that if the user configures the interface it works, but 
have a weak signal and tends to drop the connection.

If he reboots, the signal is even weaker, and also drops the connection
faster. He has to reconfigure the interface to get it back up.

So here is what I have applied:

net-wireless-ath9k-downgrade-ASSERT-in-ath_clone_txbuf.patch
net-wireless-ath9k-Manipulate-and-report-the-correct-RSSI.patch
net-wireless-ath9k-RX-stucks-during-heavy-traffic-in-HT40-mode.patch
net-wireless-ath9k-Handle-tx-desc-shortage-more-appropriately.patch
net-wireless-ath9k-Trivial-fix-in-Kconfig.patch
net-wireless-ath9k-Update-beacon-RSSI.patch
net-wireless-ath9k-Fix-bug-in-PCI-resume.patch
net-wireless-ath9k-Set-HW-state-properly.patch
net-wireless-ath9k-Fix-bug-in-retrieving-average-beacon-rssi.patch


Now with theese patches the signal strength is correct, and the 
connection survives the reboot, but does disconnect when transfer
load increases.

The good part of the above patches is that only a simple network restart
is needed to get the connection back...
(In some cases the connection resets itself and starts working again)

The fix for the connection dropping is to apply the patch:

net-wireless-ath9k-Fix-TX-hang-issue-with-Atheros-chipsets.patch

with this patch applied the link is stable, and keeps working no
matter how much data is pushed through it ...

But the patch has bad side-effects....
The transfers are slower, and loading webpages in firefox takes longer...
It also makes cpu usage higher...

So... What am I missing to get this stable for 2.6.31 ?
(going full wireless-testing is not an option, as this intended for
  main distribution kernel.)

And to help debug the connection dropping issue, attached is a kernel 
2.6.31-rc7 log with "debug=0xffffffff" (and without the last patch)

seems that AR_INTR_SYNC_LOCAL_TIMEOUT happends just before the link
dies...

I seem to recall a fix for that, but cant find it now...

--
Thomas
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ath9k.messages.bug
Url: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090823/9893fe48/attachment.txt 

[ath9k-devel] ath9k buggy in 2.6.31-rc7

[Kemble Wagner]

could you please send me an attachment of the
net-wireless-ath9k-Fix-TX-hang-issue-with-Atheros-chipsets.patch patch file
i want to try testing it

On Sun, Aug 23, 2009 at 8:24 AM, Thomas Backlund <tmb@mandriva.org> wrote:

> Hi,
>
> I'm tracking a bug in ath9k in 2.6.31-rc7 series, and have been
> cherrypicking patches from wireless-testing to try to get a stable ath9k...
>
> The problem is that if the user configures the interface it works, but have
> a weak signal and tends to drop the connection.
>
> If he reboots, the signal is even weaker, and also drops the connection
> faster. He has to reconfigure the interface to get it back up.
>
> So here is what I have applied:
>
> net-wireless-ath9k-downgrade-ASSERT-in-ath_clone_txbuf.patch
> net-wireless-ath9k-Manipulate-and-report-the-correct-RSSI.patch
> net-wireless-ath9k-RX-stucks-during-heavy-traffic-in-HT40-mode.patch
> net-wireless-ath9k-Handle-tx-desc-shortage-more-appropriately.patch
> net-wireless-ath9k-Trivial-fix-in-Kconfig.patch
> net-wireless-ath9k-Update-beacon-RSSI.patch
> net-wireless-ath9k-Fix-bug-in-PCI-resume.patch
> net-wireless-ath9k-Set-HW-state-properly.patch
> net-wireless-ath9k-Fix-bug-in-retrieving-average-beacon-rssi.patch
>
>
> Now with theese patches the signal strength is correct, and the connection
> survives the reboot, but does disconnect when transfer
> load increases.
>
> The good part of the above patches is that only a simple network restart
> is needed to get the connection back...
> (In some cases the connection resets itself and starts working again)
>
> The fix for the connection dropping is to apply the patch:
>
> net-wireless-ath9k-Fix-TX-hang-issue-with-Atheros-chipsets.patch
>
> with this patch applied the link is stable, and keeps working no
> matter how much data is pushed through it ...
>
> But the patch has bad side-effects....
> The transfers are slower, and loading webpages in firefox takes longer...
> It also makes cpu usage higher...
>
> So... What am I missing to get this stable for 2.6.31 ?
> (going full wireless-testing is not an option, as this intended for
>  main distribution kernel.)
>
> And to help debug the connection dropping issue, attached is a kernel
> 2.6.31-rc7 log with "debug=0xffffffff" (and without the last patch)
>
> seems that AR_INTR_SYNC_LOCAL_TIMEOUT happends just before the link
> dies...
>
> I seem to recall a fix for that, but cant find it now...
>
> --
> Thomas
>
> Aug 22 22:00:48 localhost klogd: cfg80211: Calling CRDA to update world
> regulatory domain
> Aug 22 22:00:48 localhost klogd: cfg80211: World regulatory domain updated:
> Aug 22 22:00:48 localhost klogd: ^I(start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> Aug 22 22:00:48 localhost klogd: ^I(2402000 KHz - 2472000 KHz @ 40000 KHz),
> (300 mBi, 2000 mBm)
> Aug 22 22:00:48 localhost klogd: ^I(2457000 KHz - 2482000 KHz @ 20000 KHz),
> (300 mBi, 2000 mBm)
> Aug 22 22:00:48 localhost klogd: ^I(2474000 KHz - 2494000 KHz @ 20000 KHz),
> (300 mBi, 2000 mBm)
> Aug 22 22:00:48 localhost klogd: ^I(5170000 KHz - 5250000 KHz @ 40000 KHz),
> (300 mBi, 2000 mBm)
> Aug 22 22:00:48 localhost klogd: ^I(5735000 KHz - 5835000 KHz @ 40000 KHz),
> (300 mBi, 2000 mBm)
> Aug 22 22:00:48 localhost klogd: ath9k 0000:03:00.0: PCI INT A -> GSI 17
> (level, low) -> IRQ 17
> Aug 22 22:00:49 localhost klogd: Registered led device: ath9k-phy0::radio
> Aug 22 22:00:49 localhost klogd: Registered led device: ath9k-phy0::assoc
> Aug 22 22:00:49 localhost klogd: Registered led device: ath9k-phy0::tx
> Aug 22 22:00:49 localhost klogd: Registered led device: ath9k-phy0::rx
> Aug 22 22:00:49 localhost klogd: phy0: Atheros AR9280 MAC/BB Rev:2 AR5133
> RF Rev:d0: mem=0xffffc900110e0000, irq=17
> Aug 22 22:00:53 localhost klogd: cfg80211: Calling CRDA for country: FR
> Aug 22 22:00:53 localhost klogd: cfg80211: Regulatory domain changed to
> country: FR
> Aug 22 22:00:53 localhost klogd: ^I(start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> Aug 22 22:00:53 localhost klogd: ^I(2402000 KHz - 2482000 KHz @ 40000 KHz),
> (N/A, 2000 mBm)
> Aug 22 22:00:53 localhost klogd: ^I(5170000 KHz - 5250000 KHz @ 40000 KHz),
> (N/A, 2000 mBm)
> Aug 22 22:00:53 localhost klogd: ^I(5250000 KHz - 5330000 KHz @ 40000 KHz),
> (N/A, 2000 mBm)
> Aug 22 22:00:53 localhost klogd: ^I(5490000 KHz - 5710000 KHz @ 40000 KHz),
> (N/A, 2700 mBm)
> Aug 22 22:00:53 localhost klogd: ADDRCONF(NETDEV_UP): wlan0: link is not
> ready
> Aug 22 22:00:53 localhost klogd:
> Aug 22 22:00:54 localhost klogd: ADDRCONF(NETDEV_CHANGE): wlan0: link
> becomes ready
> Aug 22 22:00:56 localhost klogd:
> Aug 22 22:00:57 localhost klogd:
> Aug 22 22:00:58 localhost klogd: NET: Registered protocol family 17
> Aug 22 22:00:58 localhost klogd:
> Aug 22 22:00:59 localhost klogd:
> Aug 22 22:00:59 localhost klogd:
> Aug 22 22:01:02 localhost klogd: qnum: 1, txq depth: 2
> Aug 22 22:01:02 localhost klogd: tx queue 1 (a4fa2d20), link
> ffff8800a4fa2d20
> Aug 22 22:01:02 localhost klogd:
> Aug 22 22:01:04 localhost klogd: 0xf4041071 => 0x0
> Aug 22 22:01:19 localhost klogd: tx queue 1 (a4fa46a8), link
> ffff8800a4fa46a8
> Aug 22 22:01:22 localhost klogd: TX complete: skb: ffff8800a4e14900
> Aug 22 22:01:23 localhost klogd: 0x0 => 0xf4041071
> Aug 22 22:01:38 localhost klogd: transmitting packet, skb: ffff8800ad5fa700
> Aug 22 22:01:38 localhost klogd: qnum: 1, txq depth: 2
> Aug 22 22:01:38 localhost klogd: link[1] (ffff8800a4fa8cb8)=50
> (ffff8800a4fa8d50)
> Aug 22 22:01:42 localhost klogd: transmitting packet, skb: ffff8800aa9c6d00
> Aug 22 22:02:02 localhost klogd: 0xf4041071 => 0x0
> Aug 22 22:02:02 localhost klogd: link[1] (ffff8800a4faeeb0)=48
> (ffff8800a4faef48)
> Aug 22 22:02:02 localhost klogd: Enable TXE on queue: 1
> Aug 22 22:02:09 localhost klogd:
> Aug 22 22:02:09 localhost klogd:
> Aug 22 22:02:23 localhost klogd: transmitting packet, skb: ffff8800af0d0c00
> Aug 22 22:02:23 localhost klogd: new IMR 0x0
> Aug 22 22:02:23 localhost klogd: enable IER
> Aug 22 22:02:24 localhost klogd: transmitting packet, skb: ffff8800a4e16e00
> Aug 22 22:02:24 localhost klogd: qnum: 1, txq depth: 3
> Aug 22 22:02:24 localhost klogd: qnum: 1, txq depth: 2
> Aug 22 22:02:24 localhost klogd: 0xf4041071 => 0x0
> Aug 22 22:02:24 localhost klogd: qnum: 1, txq depth: 2
> Aug 22 22:02:24 localhost klogd: new IMR 0x0
> Aug 22 22:02:27 localhost klogd: transmitting packet, skb: ffff88008a9396f8
> Aug 22 22:02:27 localhost klogd: qnum: 1, txq depth: 2
> Aug 22 22:02:30 localhost klogd: disable IER
> Aug 22 22:02:31 localhost klogd: transmitting packet, skb: ffff88007024d900
> Aug 22 22:02:31 localhost klogd: Enable TXE on queue: 1
> Aug 22 22:02:31 localhost klogd: transmitting packet, skb: ffff8800a75df000
> Aug 22 22:02:34 localhost klogd: qnum: 1, txq depth: 3
> Aug 22 22:02:34 localhost klogd: new IMR 0x0
> Aug 22 22:02:37 localhost klogd: disable IER
> Aug 22 22:02:37 localhost klogd: qnum: 1, txq depth: 1
> Aug 22 22:02:37 localhost klogd: 0xf4041071 => 0x0
> Aug 22 22:02:40 localhost klogd: link[1] (ffff8800a4fa7b80)=18
> (ffff8800a4fa7c18)
> Aug 22 22:02:40 localhost klogd: Enable TXE on queue: 1
> Aug 22 22:02:41 localhost klogd: transmitting packet, skb: ffff8800a206fd00
> Aug 22 22:02:41 localhost klogd: disable IER
> Aug 22 22:02:41 localhost klogd: disable IER
> Aug 22 22:02:41 localhost klogd: 0xf4041071 => 0x0
> Aug 22 22:02:41 localhost klogd: 0xf4041071 => 0x0
> Aug 22 22:02:41 localhost klogd: disable IER
> Aug 22 22:02:41 localhost klogd: link[1] (ffff8800a4faa348)=e0
> (ffff8800a4faa3e0)
> Aug 22 22:02:41 localhost klogd: new IMR 0x0
> Aug 22 22:02:41 localhost klogd: qnum: 1, txq depth: 3
> Aug 22 22:02:41 localhost klogd: new IMR 0x918414b4
> Aug 22 22:02:41 localhost klogd: transmitting packet, skb: ffff8800af0d0300
> Aug 22 22:02:43 localhost klogd: link[1] (ffff8800a4faca78)=10
> (ffff8800a4facb10)
> Aug 22 22:02:43 localhost klogd: transmitting packet, skb: ffff8800a4dac200
> Aug 22 22:02:43 localhost klogd: new IMR 0x0
> Aug 22 22:02:43 localhost klogd: qnum: 1, txq depth: 2
> Aug 22 22:02:46 localhost klogd: AR_IMR 0x918414b4 IER 0x1
> Aug 22 22:02:46 localhost klogd: AR_IMR 0x918414b4 IER 0x1
> Aug 22 22:02:46 localhost klogd: enable IER
> Aug 22 22:02:46 localhost klogd: Writing ofdmbase=12582412
> cckbase=12582712
> Aug 22 22:02:47 localhost klogd: enable IER
> Aug 22 22:02:47 localhost klogd: AR_INTR_SYNC_LOCAL_TIMEOUT
> Aug 22 22:02:48 localhost klogd: AR_INTR_SYNC_LOCAL_TIMEOUT
> Aug 22 22:02:48 localhost klogd: 0x0 => 0xf4041071
> Aug 22 22:02:49 localhost klogd: CE: hpet increasing min_delta_ns to 15000
> nsec
> Aug 22 22:02:52 localhost klogd: 0x0 => 0xf4041071
> Aug 22 22:02:53 localhost klogd: new IMR 0x918414b4
> Aug 22 22:02:53 localhost klogd: 0x0 => 0xf4041071
> Aug 22 22:02:54 localhost klogd: 0xf4041071 => 0x0
> Aug 22 22:02:54 localhost klogd: enable IER
> Aug 22 22:02:54 localhost klogd: AWAKE -> AWAKE
> Aug 22 22:02:55 localhost klogd: ADDRCONF(NETDEV_UP): wlan0: link is not
> ready
> Aug 22 22:03:07 localhost klogd:
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20091111/406734e5/attachment-0001.htm 

[ath9k-devel] ath9k buggy in 2.6.31-rc7

[Luis R. Rodriguez]

On Sat, Aug 22, 2009 at 1:24 PM, Thomas Backlund <tmb@mandriva.org> wrote:
> Hi,
>
> I'm tracking a bug in ath9k in 2.6.31-rc7 series, and have been
> cherrypicking patches from wireless-testing to try to get a stable ath9k...
>
> The problem is that if the user configures the interface it works, but have
> a weak signal and tends to drop the connection.
>
> If he reboots, the signal is even weaker, and also drops the connection
> faster. He has to reconfigure the interface to get it back up.
>
> So here is what I have applied:
>
> net-wireless-ath9k-downgrade-ASSERT-in-ath_clone_txbuf.patch
> net-wireless-ath9k-Manipulate-and-report-the-correct-RSSI.patch
> net-wireless-ath9k-RX-stucks-during-heavy-traffic-in-HT40-mode.patch
> net-wireless-ath9k-Handle-tx-desc-shortage-more-appropriately.patch
> net-wireless-ath9k-Trivial-fix-in-Kconfig.patch
> net-wireless-ath9k-Update-beacon-RSSI.patch
> net-wireless-ath9k-Fix-bug-in-PCI-resume.patch
> net-wireless-ath9k-Set-HW-state-properly.patch
> net-wireless-ath9k-Fix-bug-in-retrieving-average-beacon-rssi.patch
>
>
> Now with theese patches the signal strength is correct, and the connection
> survives the reboot, but does disconnect when transfer
> load increases.

BTW if you notice any *small* patch which made a huge difference in
something very significant please consider e-mailing linux-wireless
and Cc'ing stable at kernel.org about it with as much details as you can
provide.

Stable will not apply large patches to fix small issues or large
non-trivial patches to fix some non-oops. It really varies what will
get applied.. but if some few small patches *really* help its worth
noting at the very least.

Because we cannot get some of these patches into 2.6.31 what we tend
to recommend is to upgrade just your wireless subsystem to the newer
stable kernel release. This can be done with something like:

http://wireless.kernel.org/en/users/Download/stable

  Luis

[ath9k-devel] ath9k buggy in 2.6.31-rc7

[Luis R. Rodriguez]

On Tue, Nov 10, 2009 at 11:57 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Sat, Aug 22, 2009 at 1:24 PM, Thomas Backlund <tmb@mandriva.org> wrote:
>> Hi,
>>
>> I'm tracking a bug in ath9k in 2.6.31-rc7 series, and have been
>> cherrypicking patches from wireless-testing to try to get a stable ath9k...
>>
>> The problem is that if the user configures the interface it works, but have
>> a weak signal and tends to drop the connection.
>>
>> If he reboots, the signal is even weaker, and also drops the connection
>> faster. He has to reconfigure the interface to get it back up.
>>
>> So here is what I have applied:
>>
>> net-wireless-ath9k-downgrade-ASSERT-in-ath_clone_txbuf.patch
>> net-wireless-ath9k-Manipulate-and-report-the-correct-RSSI.patch
>> net-wireless-ath9k-RX-stucks-during-heavy-traffic-in-HT40-mode.patch
>> net-wireless-ath9k-Handle-tx-desc-shortage-more-appropriately.patch
>> net-wireless-ath9k-Trivial-fix-in-Kconfig.patch
>> net-wireless-ath9k-Update-beacon-RSSI.patch
>> net-wireless-ath9k-Fix-bug-in-PCI-resume.patch
>> net-wireless-ath9k-Set-HW-state-properly.patch
>> net-wireless-ath9k-Fix-bug-in-retrieving-average-beacon-rssi.patch
>>
>>
>> Now with theese patches the signal strength is correct, and the connection
>> survives the reboot, but does disconnect when transfer
>> load increases.
>
> BTW if you notice any *small* patch which made a huge difference in
> something very significant please consider e-mailing linux-wireless
> and Cc'ing stable at kernel.org about it with as much details as you can
> provide.

I'll also note that we try to be good about this and once we fix
something in wireless-testing we CC stable at kernel.org so the fix is
also propagated to stable kernels but *sometimes* some few fixes go
through without a CC, so if you do notice something worthy please
don't hesitate to note.

> Stable will not apply large patches to fix small issues or large
> non-trivial patches to fix some non-oops. It really varies what will
> get applied.. but if some few small patches *really* help its worth
> noting at the very least.
>
> Because we cannot get some of these patches into 2.6.31 what we tend
> to recommend is to upgrade just your wireless subsystem to the newer
> stable kernel release. This can be done with something like:
>
> http://wireless.kernel.org/en/users/Download/stable

Oh and as an example Ubuntu ships the linux-backport-modules package
and in it it has the stable compat-wireless stuff.

  Luis

[ath9k-devel] ath9k buggy in 2.6.31-rc7

[Thomas Backlund]

Kemble Wagner skrev:
> could you please send me an attachment of the 
> net-wireless-ath9k-Fix-TX-hang-issue-with-Atheros-chipsets.patch patch 
> file i want to try testing it
> 

It wont help you on its own...
You need a lot of patches to get it fully working again.

After a lot of testing with different sets/combinations of patches,
here is what I ended up with:

# Fixes for ath9k (# 52739)
net-wireless-ath9k-downgrade-ASSERT-in-ath_clone_txbuf.patch
net-wireless-ath9k-Make-sure-we-configure-a-non-zero-beacon-interval.patch
net-wireless-ath9k-differentiate-quality-reporting-between-legacy-and-HT-configurations.patch
net-wireless-ath9k-remove-unnecessary-STATION-mode-check.patch
net-wireless-ath9k-stop-ani-when-the-STA-gets-disconnected.patch
net-wireless-ath9k-race-condition-in-SCANNING-state-check-during-ANI-calibration.patch
net-wireless-ath9k-Handle-different-TX-and-RX-streams-properly.patch
net-wireless-ath9k-downgrade-assert-in-rc.c-for-invalid-rate.patch
net-wireless-ath9k-Manipulate-and-report-the-correct-RSSI.patch
net-wireless-ath9k-RX-stucks-during-heavy-traffic-in-HT40-mode.patch
net-wireless-ath9k-Fix-TX-hang-issue-with-Atheros-chipsets.patch
net-wireless-ath9k-Remove-bogus-assert-in-ath_clone_txbuf.patch
net-wireless-ath9k-Handle-tx-desc-shortage-more-appropriately.patch
net-wireless-ath9k-do-not-stop-the-queues-in-driver-stop.patch
net-wireless-ath9k-Trivial-fix-in-Kconfig.patch
net-wireless-ath9k-Update-beacon-RSSI.patch
net-wireless-ath9k-Fix-bug-in-PCI-resume.patch
net-wireless-ath9k-Set-HW-state-properly.patch
net-wireless-ath9k-Fix-TX-poll-cancelling.patch
net-wireless-ath9k-Fix-bug-in-retrieving-average-beacon-rssi.patch
net-wireless-ath9k-Fix-read-buffer-overflow.patch
net-wireless-ath9k-claim-irq-for-ath9k-not-ath-for-pci.patch
net-wireless-ath9k-Fix-bug-in-ANI-channel-handling.patch
net-wireless-ath9k-Do-a-full-reset-for-AR9280.patch
net-wireless-ath9k-Disable-autosleep-feature-by-default.patch
net-wireless-ath9k-Fix-RFKILL-bugs.patch
net-wireless-ath9k-fix-misplaced-semicolon-on-rate-control.patch

Now theese are all merged in upstream linus git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

but to make it easier for you, and since some of them had to be rediffed 
to apply cleanly as I only cherrypicked ath9k specific fixes, you can 
find them all here:

http://tmb.mine.nu/Mandriva/Cooker/bugs/ath9k_bug52739/patches/
http://tmb2.mine.nu/Mandriva/Cooker/bugs/ath9k_bug52739/patches/

along with a series file that shows the order they have to be applied in...

Now with all theese in place I have no complaints about the ath9k in our 
2.6.31.x series kernels...

--
Have fun

Thomas