Possible background on this issue, although perhaps not directly related?

http://en.it-usenet.org/thread/11744/16564/

I have now obtained a trace:

[ 328.843253] ------------[ cut here ]------------
[ 328.843279] WARNING: at drivers/net/wireless/ath/ath9k/hw.c:794 ar9003_get_pll_sqsum_dvc+0xb6/0xc0 [ath9k_hw]()
[ 328.843284] Hardware name: UX31E
[ 328.843287] Modules linked in: iTCO_wdt iTCO_vendor_support joydev nls_cp437 vfat fat coretemp arc4 crc32c_intel ghash_clmulni_intel cryptd ath9k uvcvideo ath9k_common ath9k_hw ath3k ath btusb videobuf2_vmalloc rts5139(C) mac80211 asus_nb_wmi videobuf2_memops videobuf2_core asus_wmi psmouse sparse_keymap bluetooth cfg80211 videodev media crc16 pci_hotplug serio_raw snd_hda_codec_hdmi rfkill evdev tun pcspkr i2c_i801 snd_hda_codec_realtek lpc_ich microcode kvm_intel i915 kvm sg snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_hwdep snd_pcm snd_page_alloc intel_agp intel_gtt drm_kms_helper ac video drm battery wmi acpi_cpufreq mperf snd_timer i2c_algo_bit snd i2c_core soundcore button thermal mei processor jfs sd_mod ahci xhci_hcd ehci_hcd libahci libata scsi_mod usbcore usb_common
[ 328.843466] Pid: 11004, comm: kworker/u:2 Tainted: G C 3.7.10-1-ARCH #1
[ 328.843468] Call Trace:
[ 328.843474] [<ffffffff8105756f>] warn_slowpath_common+0x7f/0xc0
[ 328.843477] [<ffffffff810575ca>] warn_slowpath_null+0x1a/0x20
[ 328.843483] [<ffffffffa0661986>] ar9003_get_pll_sqsum_dvc+0xb6/0xc0 [ath9k_hw]
[ 328.843488] [<ffffffffa047fa23>] ath_hw_pll_work+0x53/0xd0 [ath9k]
[ 328.843494] [<ffffffff81075e52>] process_one_work+0x132/0x4f0
[ 328.843497] [<ffffffff8107526a>] ? manage_workers+0x1ea/0x290
[ 328.843502] [<ffffffffa047f9d0>] ? ath_tx_complete_poll_work+0xe0/0xe0 [ath9k]
[ 328.843505] [<ffffffff810765ed>] worker_thread+0x15d/0x400
[ 328.843509] [<ffffffff81076490>] ? rescuer_thread+0x240/0x240
[ 328.843513] [<ffffffff8107b1b0>] kthread+0xc0/0xd0
[ 328.843521] [<ffffffff81010000>] ? perf_trace_xen_mmu_set_pte_at+0xb0/0x100
[ 328.843526] [<ffffffff8107b0f0>] ? kthread_freezable_should_stop+0x70/0x70
[ 328.843531] [<ffffffff814c35ac>] ret_from_fork+0x7c/0xb0
[ 328.843534] [<ffffffff8107b0f0>] ? kthread_freezable_should_stop+0x70/0x70
[ 328.843536] ---[ end trace 601bae43822e136e ]---

Far more useful ! Also I have attached dmesg and lspci supplied by the user.

Ta,
Edward.

OK, so it seems the issue could be related to:
https://patchwork.kernel.org/patch/1144741/

Chat log from #ath9k as of today:
15:30 < PaulFertser> functorfun: hm, it asks the hardware to measure some parameter of PLL3 but then it checks for PLL4 measurement readiness, and if it doesn't happen timely enough (in 100us * 100), prints a
warning. I do not have access to the datasheet so i can not check if checking PLL4 to see if PLL3 measurement is ready is correct.
15:30 < functorfun> PaulFertser: The most I can understand is this patch is correct in the technical sense that its better to timeout than totally lock up
15:31 < PaulFertser> functorfun: indeed, but there're two possibilities: timeout is too tight for your device; the code is incorrect and either doesn't activate the measurement properly or fails to check the
appropriate end conditions.

A possible fix is to perhaps use 1000 instead of 100 and add an additional printk to output the actual i value if it exits the loop normally.

* I have patched the typo in the kprint here:
http://marc.info/?l=linux-kernel&m=136488187325892&w=2

* Other distros have bug reports on this issue, found here:
http://abrt.fedoraproject.org/faf/problems/495452/
https://bugzilla.redhat.com/show_bug.cgi?id=893713

OK, so here is the original bug report after much witch hunting:
https://bugzilla.redhat.com/show_bug.cgi?id=811142

Here is a *possible* fix? Could someone confirm this?
https://gist.github.com/victoredwardocallaghan/5298765

Cheers,
Edward.

Status on 3.9?

Tobias Powalowski: I still have the bug on Linux 3.9.4-1.

Steps to reproduce:

The bug happens when I:
-Enable WiFi through wicd
-Connect to my local access point with wicd
-Switch to any tty; i.e. tty1 => Ctrl+Alt+F1
-Observe the following message being spammed and repeated non-stop: "ath: phy0: PLL4 meaurement not done".

The bug stops when I:
-Disconnect from the local access point through wicd.
-Check the tty again; the message has ceased being repeated.

Using journalctl, I can find the same trace as Edward:

mai 28 12:46:45 liberator kernel: ------------[ cut here ]------------
mai 28 12:46:45 liberator kernel: WARNING: at drivers/net/wireless/ath/ath9k/hw.c:780 ar9003_get_pll_sqsum_dvc+0xb6/0xc0 [ath9k_hw]()
mai 28 12:46:45 liberator kernel: Hardware name: System Product Name
mai 28 12:46:45 liberator kernel: Modules linked in: joydev hid_generic usbhid hid snd_hda_codec_hdmi snd_hda_codec_realtek fuse uvcvideo videobuf2_vmallo
mai 28 12:46:45 liberator kernel: sr_mod cdrom sd_mod ahci libahci libata ehci_pci ehci_hcd xhci_hcd scsi_mod usbcore usb_common
mai 28 12:46:45 liberator kernel: Pid: 5399, comm: kworker/u:73 Tainted: P O 3.9.4-1-ARCH #1
mai 28 12:46:45 liberator kernel: Call Trace:
mai 28 12:46:45 liberator kernel: [<ffffffff810580b0>] warn_slowpath_common+0x70/0xa0
mai 28 12:46:45 liberator kernel: [<ffffffff8105819a>] warn_slowpath_null+0x1a/0x20
mai 28 12:46:45 liberator kernel: [<ffffffffa0c64e76>] ar9003_get_pll_sqsum_dvc+0xb6/0xc0 [ath9k_hw]
mai 28 12:46:45 liberator kernel: [<ffffffffa0d31b43>] ath_hw_pll_work+0x43/0xc0 [ath9k]
mai 28 12:46:45 liberator kernel: [<ffffffff81075e60>] process_one_work+0x170/0x440
mai 28 12:46:45 liberator kernel: [<ffffffff81076935>] worker_thread+0x115/0x3d0
mai 28 12:46:45 liberator kernel: [<ffffffff81076820>] ? manage_workers+0x340/0x340
mai 28 12:46:45 liberator kernel: [<ffffffff8107b600>] kthread+0xc0/0xd0
mai 28 12:46:45 liberator kernel: [<ffffffff8107b540>] ? kthread_create_on_node+0x120/0x120
mai 28 12:46:45 liberator kernel: [<ffffffff814d9dec>] ret_from_fork+0x7c/0xb0
mai 28 12:46:45 liberator kernel: [<ffffffff8107b540>] ? kthread_create_on_node+0x120/0x120
mai 28 12:46:45 liberator kernel: ---[ end trace b2f80d0097d4ce78 ]---

I've attached my dmesg log & a part of my 'journalctl -b' log, as well as the output of 'uname -a'.
The 'ath: phy0: PLL4 meaurement not done' message is constantly repeated until the end of the log, so it was useless to repeat it in the log. Hence why I've cut down the log to the part where the message arrives.

Note: my system doesn't lock up, and WiFi works just fine when it is enabled. The bug is still present but doesn't really cause any problem, however it's extremely bothering to have my tty's spammed when I need to use them.

Please report this upstream, I cannot do anything.

Status on 3.10.x?

@Tobias Powalowski
I can confirm that this issue is still present in 3.10.7 (Asus UX21E with Atheros AR9485).

Status on 3.11.1?

Asus UX21E with Atheros AR9485 - working fine - fixed, at least for me.