network breaks - ath9k for TP-Link 5008

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

I'm facing the same problem and stacktrace output is similar:

[ 3232.387605] ------------[ cut here ]------------
[ 3232.387612] WARNING: at drivers/net/wireless/ath/ath9k/rc.c:697 ath_rc_get_highest_rix.isra.16+0x15c/0x1e0 [ath9k]()
[ 3232.387614] Hardware name: To Be Filled By O.E.M.
[ 3232.387615] Modules linked in: bnep rfcomm bluetooth pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) aesni_intel cryptd aes_x86_64 aes_generic vboxdrv(O) parport_pc ppdev binfmt_misc dm_crypt snd_hda_codec_hdmi arc4 snd_hda_codec_realtek joydev nvidia(P) ath9k snd_hda_intel mac80211 snd_hda_codec snd_hwdep snd_seq_midi snd_pcm snd_rawmidi snd_seq_midi_event snd_seq ath9k_common ath9k_hw ath cfg80211 snd_timer snd_seq_device psmouse serio_raw shpchp snd soundcore snd_page_alloc coretemp lp parport usbhid hid usb_storage uas firewire_ohci i915 mxm_wmi firewire_core tg3 drm_kms_helper crc_itu_t ahci libahci xhci_hcd drm video
[ 3232.387645] Pid: 2702, comm: bash Tainted: P W O 3.2.0-core2 #1
[ 3232.387646] Call Trace:
[ 3232.387647] <IRQ> [<ffffffff8105b3cf>] warn_slowpath_common+0x7f/0xc0
[ 3232.387653] [<ffffffff8105b42a>] warn_slowpath_null+0x1a/0x20
[ 3232.387656] [<ffffffffa032b48c>] ath_rc_get_highest_rix.isra.16+0x15c/0x1e0 [ath9k]
[ 3232.387660] [<ffffffffa032b594>] ath_get_rate+0x84/0x400 [ath9k]
[ 3232.387664] [<ffffffffa03276f4>] ? ath_tx_send_normal+0x84/0xd0 [ath9k]
[ 3232.387670] [<ffffffffa02b2ea6>] rate_control_get_rate+0x96/0x170 [mac80211]
[ 3232.387677] [<ffffffffa02bd977>] invoke_tx_handlers+0x7c7/0x10e0 [mac80211]
[ 3232.387679] [<ffffffff814b5954>] ? led_trigger_event+0x24/0x80
[ 3232.387685] [<ffffffffa02be3da>] ieee80211_tx+0x5a/0xc0 [mac80211]
[ 3232.387690] [<ffffffffa02be4cd>] ieee80211_xmit+0x8d/0xd0 [mac80211]
[ 3232.387695] [<ffffffffa02beb84>] ieee80211_subif_start_xmit+0x3c4/0xa60 [mac80211]
[ 3232.387698] [<ffffffff814dca22>] dev_hard_start_xmit+0x322/0x6d0
[ 3232.387701] [<ffffffff8104dd97>] ? select_task_rq_fair+0x327/0xaa0
[ 3232.387703] [<ffffffff814f9e5e>] sch_direct_xmit+0xfe/0x1d0
[ 3232.387706] [<ffffffff814dcf51>] dev_queue_xmit+0x181/0x630
[ 3232.387708] [<ffffffff8151417a>] ip_finish_output+0x16a/0x2f0
[ 3232.387711] [<ffffffff81514cd8>] ip_output+0x98/0xa0
[ 3232.387713] [<ffffffff8150bf3f>] ? ipv4_dst_check+0x2f/0x50
[ 3232.387716] [<ffffffff815143d9>] ip_local_out+0x29/0x30
[ 3232.387718] [<ffffffff8151453a>] ip_queue_xmit+0x15a/0x400
[ 3232.387721] [<ffffffff8152b8c4>] tcp_transmit_skb+0x3e4/0x8d0
[ 3232.387723] [<ffffffff8152dbdc>] tcp_send_ack+0x8c/0xe0
[ 3232.387725] [<ffffffff815213ce>] __tcp_ack_snd_check+0x5e/0xa0
[ 3232.387728] [<ffffffff8152994c>] tcp_rcv_established+0x52c/0x8b0
[ 3232.387730] [<ffffffff8153164f>] tcp_v4_do_rcv+0x27f/0x440
[ 3232.387733] [<ffffffff81533450>] tcp_v4_rcv+0x620/0x8f0
[ 3232.387735] [<ffffffff8150d686>] ? ip_route_input_common+0xcc6/0xe60
[ 3232.387738] [<ffffffff81039d59>] ? default_spin_lock_flags+0x9/0x10
[ 3232.387741] [<ffffffff8150f575>] ip_local_deliver_finish+0xd5/0x270
[ 3232.387743] [<ffffffff8150f8d8>] ip_local_deliver+0x88/0x90
[ 3232.387746] [<ffffffff8150f251>] ip_rcv_finish+0x131/0x38...

I have updated to kernel 3.2 final as requested. For now I did not see any stacktrace anymore in kern.log.

@ Keith Baker: What is on your system?

With kernel3.2 final it has changed to the following every repeating(every 1min) message:
:
Jan 7 16:16:02 userHOST kernel: [ 4078.749287] wlan0: associated
Jan 7 16:17:27 userHOST kernel: [ 4163.760556] cfg80211: All devices are disconnected, going to restore regulatory settings
Jan 7 16:17:27 userHOST kernel: [ 4163.760563] cfg80211: Restoring regulatory settings
Jan 7 16:17:27 userHOST kernel: [ 4163.760566] cfg80211: Calling CRDA to update world regulatory domain
Jan 7 16:17:27 userHOST kernel: [ 4163.766238] cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width channel with regulatory rule:
Jan 7 16:17:27 userHOST kernel: [ 4163.766242] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
Jan 7 16:17:27 userHOST kernel: [ 4163.766244] cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width channel with regulatory rule:
Jan 7 16:17:27 userHOST kernel: [ 4163.766246] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
Jan 7 16:17:27 userHOST kernel: [ 4163.766248] cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width channel with regulatory rule:
Jan 7 16:17:27 userHOST kernel: [ 4163.766250] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
Jan 7 16:17:27 userHOST kernel: [ 4163.766252] cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width channel with regulatory rule:
Jan 7 16:17:27 userHOST kernel: [ 4163.766254] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
Jan 7 16:17:27 userHOST kernel: [ 4163.766256] cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width channel with regulatory rule:
Jan 7 16:17:27 userHOST kernel: [ 4163.766258] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
Jan 7 16:17:27 userHOST kernel: [ 4163.766259] cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width channel with regulatory rule:
Jan 7 16:17:27 userHOST kernel: [ 4163.766261] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
Jan 7 16:17:27 userHOST kernel: [ 4163.766263] cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width channel with regulatory rule:
Jan 7 16:17:27 userHOST kernel: [ 4163.766265] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
Jan 7 16:17:27 userHOST kernel: [ 4163.766266] cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width channel with regulatory rule:
Jan 7 16:17:27 userHOST kernel: [ 4163.766268] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
Jan 7 16:17:27 userHOST kernel: [ 4163.766270] cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width channel with regulatory rule:
Jan 7 16:17:27 userHOST kernel: [ 4163.766272] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
Jan 7 16:17:27 userHOST kernel: [ 4163.766273] cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width channel with regulatory rule:
Jan 7 16:17:27 userHOST kernel: [ 4163.766275] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
Jan 7 16:17:27 userHOST kernel: [ 4163.7662...

I downgraded to kernel 3.1.8 because I saw some fixes in the ath-module. I'm still testing.

These frequent CRDA-update occure also very often on my system. Approx. all 10 minutes it switches to world und then to my local CRDA. But that seems to be another bug.

Have it catched again on kernel 3.2.0 final, this time right after the stacktraces my system crashed. I have had to shut it down the hardway. Some indodes became corrupteted, but were cleaned uped the next start as far as I could see.

I attach the stacktraces again from begiining until system crashed(not much). There are points on it:

With kernel 3.2.0 final the error become rarer than with 3.2.0rc7. Instead of the error you could see in mass what I have posted in #5.

The stacktraces looks verry similiar, but they are not really the same.

At timepoint of crashing the log shows nothing, only the stacktrace of the ath9k error. Than follows the newstart sequence.

There is one more hint. At the time of the crash I had virtualbox 4.1.6 runnig with windows xp guest on it.

I have reside for long on openSUSE and just switched to Ubuntu. On openSUSE there were also some problems with ath9k and virtualbox. They did not like each other.

Do you know if this issue happened in previous version of Ubuntu, or is this a new issue?

Would it be possible for you to test the latest upstream kernel? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . If possible, please test the latest v3.2 kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed by the mainline kernel, please add the following tag 'kernel-fixed-upstream-KERNEL-VERSION'. For example, if kernel version 3.2-rc1 fixed the issue, the tag would be: 'kernel-fixed-upstream-v3.2-rc1'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'. If you believe this bug does not require upstream testing, please add the tag: 'kernel-upstream-testing-not-needed'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-precise/

Q:Do you know if this issue happened in previous version of Ubuntu, or is this a new issue?

I can say, that especial the bug:

Dec 31 17:22:31 userHOST kernel: [ 2684.225824] WARNING: at /build/buildd/linux-3.2.0/drivers/net/wireless/ath/ath9k/rc.c:697 ath_rc_get_highest_rix.isra.19+0x15c/0x1e0 [ath9k]()

is new to kernel3.2.0 and what not observed by me since kernel 2.6.arround 30 as far as I remember.

I was on with atk9 originally with openSUSE(reside most), but I have also a short intermezzo with ubuntu11.10 and it was not there.

Q:Would it be possible for you to test the latest upstream kernel?

May be I understand you not correct:

In moment precise is on 3.2.0 final and GK Hardtman has not given out an following one.

Also in

http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D

and especially in

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-precise/

is not newer one than that from 5.1.2012 which I have already on sice comment #5: "Have it catched again on kernel 3.2.0 final, this time rig..."

So, you already have what you request.

Please give a confirmation about.

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

It is still there with newest kernel version.

I do the checks by myself regular, so I disable the reminer bot.

As long as I post nothing different the bug keeps unchanched and ready for developer for handling.

Update is done by me to every new developer kernel on precise.

Still in 3.2.0-9-generic.

Still in 3.2.0-10-generic

Problem also in vanilla kernel 3.2.1.

Still in 3.2.2.

This problem seems to be the one reported upstreams here https://lkml.org/lkml/2012/2/5/284 and commits 2504a6423b9ab4c36df78227055995644de19edb and 8149415efa033ca138c0080ded77329e98697c7b should fix it. So I built a test kernel that include these commits.

You can find this kernel in http://people.canonical.com/~henrix/lp910519/.

Would you please be able to download it, check if you still see the problem and report back?

The kernel packages from Luis fixed the issue for me.

@_oOMOo_
Thank you for testing and reporting back.

Could you please confirm that newer version of development kernel solves the issue as well? It should be fixed there now.

Yes, I have the new kernel packages now and the issue has not reappeared. Thanks,

Great, thanks for testing. Just for the record, the issu has been solved after a rebase to v.3.2.9.