Similar problem with wakeup from suspend:

uname -a
Linux oboe.localdomain 3.8.4-202.fc18.x86_64 #1 SMP Thu Mar 21 17:02:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux


Apr 15 23:40:53 oboe kernel: [36058.580353] WARNING: at drivers/net/wireless/ath/ath9k/hw.c:794 ar9003_get_pll_sqsum_dvc+0xb6/0xc0 [ath9k_hw]()
Apr 15 23:40:53 oboe kernel: [36058.580354] Hardware name: X202E
Apr 15 23:40:53 oboe kernel: [36058.580356] Modules linked in: lp parport ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables fuse rfcomm bnep vfat fat arc4 ath9k ath9k_common ath9k_hw snd_hda_codec_hdmi snd_hda_codec_realtek ath snd_hda_intel snd_hda_codec snd_hwdep uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev mac80211 snd_seq snd_seq_device media snd_pcm ath3k btusb snd_page_alloc bluetooth snd_timer cfg80211 snd coretemp kvm_intel asus_nb_wmi hid_multitouch asus_wmi sparse_keymap iTCO_wdt iTCO_vendor_support soundcore rfkill kvm mei lpc_ich serio_raw i2c_i801 mfd_core microcode uinput i915 crc32c_intel i2c_algo_bit ghash_clmulni_intel drm_kms_helper drm i2c_core wmi video [last unloaded: iptable_mangle]
Apr 15 23:40:53 oboe kernel: [36058.580406] Pid: 31402, comm: kworker/u:25 Not tainted 3.8.4-202.fc18.x86_64 #1
Apr 15 23:40:53 oboe kernel: [36058.580408] Call Trace:
Apr 15 23:40:53 oboe kernel: [36058.580415]  [<ffffffff8105e62f>] warn_slowpath_common+0x7f/0xc0
Apr 15 23:40:53 oboe kernel: [36058.580419]  [<ffffffff8105e68a>] warn_slowpath_null+0x1a/0x20
Apr 15 23:40:53 oboe kernel: [36058.580426]  [<ffffffffa04a89e6>] ar9003_get_pll_sqsum_dvc+0xb6/0xc0 [ath9k_hw]
Apr 15 23:40:53 oboe kernel: [36058.580432]  [<ffffffffa0517323>] ath_hw_pll_work+0x53/0xd0 [ath9k]
Apr 15 23:40:53 oboe kernel: [36058.580438]  [<ffffffff8107a693>] process_one_work+0x163/0x490
Apr 15 23:40:53 oboe kernel: [36058.580441]  [<ffffffff8107ceee>] worker_thread+0x15e/0x450
Apr 15 23:40:53 oboe kernel: [36058.580444]  [<ffffffff8107cd90>] ? busy_worker_rebind_fn+0x110/0x110
Apr 15 23:40:53 oboe kernel: [36058.580448]  [<ffffffff81081fb0>] kthread+0xc0/0xd0
Apr 15 23:40:53 oboe kernel: [36058.580452]  [<ffffffff81010000>] ? ftrace_define_fields_xen_mc_entry+0xa0/0xf0
Apr 15 23:40:53 oboe kernel: [36058.580456]  [<ffffffff81081ef0>] ? kthread_create_on_node+0x120/0x120
Apr 15 23:40:53 oboe kernel: [36058.580460]  [<ffffffff8165882c>] ret_from_fork+0x7c/0xb0
Apr 15 23:40:53 oboe kernel: [36058.580463]  [<ffffffff81081ef0>] ? kthread_create_on_node+0x120/0x120
Apr 15 23:40:53 oboe kernel: [36058.580465] ---[ end trace dc4f1bb94f008835 ]---
Apr 15 23:40:53 oboe kernel: [36058.580467] ath: phy0: PLL4 meaurement not done
Apr 15 23:40:53 oboe kernel: [36058.596139] usb 1-1.1: new full-speed USB device number 14 using ehci-pci
Apr 15 23:40:53 oboe dbus-daemon[608]: dbus[608]: [system] Successfully activated service 'org.freedesktop.PackageKit'
Apr 15 23:40:53 oboe dbus[608]: [system] Successfully activated service 'org.freedesktop.PackageKit'
Apr 15 23:40:53 oboe kernel: [36058.685121] usb 1-1.1: New USB device found, idVendor=04ca, idProduct=3005
Apr 15 23:40:53 oboe kernel: [36058.685135] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 15 23:40:53 oboe kernel: [36058.685144] usb 1-1.1: Product: Bluetooth USB Host Controller
Apr 15 23:40:53 oboe kernel: [36058.685152] usb 1-1.1: Manufacturer: Atheros Communications
Apr 15 23:40:53 oboe kernel: [36058.685160] usb 1-1.1: SerialNumber: Alaska Day 2006
Apr 15 23:40:53 oboe kernel: [36058.693327] ath: phy0: PLL4 meaurement not done
Apr 15 23:40:53 oboe kernel: [36058.806920] ath: phy0: PLL4 meaurement not done
Apr 15 23:40:54 oboe kernel: [36058.920778] ath: phy0: PLL4 meaurement not done
Apr 15 23:40:54 oboe kernel: [36058.982696] usb 1-1.1: USB disconnect, device number 14
Apr 15 23:40:54 oboe kernel: [36059.033643] ath: phy0: PLL4 meaurement not done
Apr 15 23:40:54 oboe kernel: [36059.146278] ath: phy0: PLL4 meaurement not done
Apr 15 23:40:54 oboe kernel: [36059.160182] usb 1-1.1: new full-speed USB device number 15 using ehci-pci
Apr 15 23:40:54 oboe kernel: [36059.247111] usb 1-1.1: New USB device found, idVendor=04ca, idProduct=3005
Apr 15 23:40:54 oboe kernel: [36059.247121] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 15 23:40:54 oboe kernel: [36059.247127] usb 1-1.1: Product: Bluetooth USB Host Controller
Apr 15 23:40:54 oboe kernel: [36059.247132] usb 1-1.1: Manufacturer: Atheros Communications
Apr 15 23:40:54 oboe kernel: [36059.247136] usb 1-1.1: SerialNumber: Alaska Day 2006
Apr 15 23:40:54 oboe kernel: [36059.259092] ath: phy0: PLL4 meaurement not done

Interesting the error occurs repeatedly when the following message comes from a WARN_ONCE.  
ath: phy0: PLL4 meaurement not done
I'm looking at the code upstream and it seems to be this is something that occurs only when connected.  More to come on that point after I look a bit deeper.

Does the message continue to occur if you connect wifi? 
Have you tried a later kernel, perhaps 3.8 or so?

After reporting the bug, to stop the message from recurring, I disabled the Wi-Fi Controller in bios.  I haven't seen the message since I did that.

This morning, I re-enabled the wi-fi controller, and will see if the message comes back.  After a couple of days, I will switch to running wirelessly to see if the message recurs when I actually connect wi-fi.

markusN seems to have been running the 3.8 kernel when getting the message, which would answer your second question.

I will post another comment if/when I get the bug to show again.  Before I disabled Wi-Fi in bios, this message was showing up only occasionally, unlike the problem in bug 873914.

Currently running fedora kernel  3.8.4-102.fc17.x86_64.

At this point, resuming from hibernation does not wake up the monitor, so it's impossible for me to test this bug at this time.

If the hibernation problem gets fixed, then I will try again to test this bug.

Greta, 

Thanks for the input.  Of course, disabling wifi in the bios obviously disables the driver, and no issue will occur.  Let me know if you see further problems in regard to the above.

Not waking the monitor is a separate (irritating) issue, would invite you to open a separate bug if you haven't already.

I'll keep digging on this point as I can, good piece of info that it's still an issue with 3.8.4 and older 3.6.1 also.

Would like to refine my understanding of the problem:
>Desktop has both ethernet and wireless.  Ethernet is system connection, and 
> connects automatically.  Wireless does not connect automatically.

1. Wireless doesn't connect automatically: is this because either you have it disabled or choose to use ethernet and just don't have connect by choice? Or does the "does not connect" mean the above problem prevents the connection?   I don't think this issue will cause a connection issue at first blush.  Does this cause a functionality problem or is it just the WARN in the log but things work reasonably ok?

Either way, I will see about getting a fix.

Since my ethernet connection is faster, I chose to use ethernet.  I chose not to connect wirelessly.  The warning message did not cause a functionality problem on this machine.

When I first installed linux on my machine and turned it on, both ethernet and wireless were connecting automatically using system connection.  I went into Network Settings and unchecked the "connect automatically" button for the wireless.  It was after I had done that that the warning message occurred upon resumption from hibernation.

As far as I could tell, there was no functionality problem on this machine.  It was WARN in the log and in the automatic bug-reporting tool.

On my laptop, which has broadcom chip BCM4313, a similar warning message occurred a lot, not just when resuming from hibernation,  And then connectivity would slow to a crawl, to the point where I had to plug it into an ethernet connection to get downloads moving again.

Message has reappeared, but slightly different.  The number after the colon is now 794 instead of 786.  And, I got the message by putting the machine to sleep (sudo pm-suspend) and waking it, rather than hibernating it (sudo pm-hibernate).

I tried it with several variations (by changing Network Manager settings):
1.  Ethernet connected automatically; wireless not connected automatically.
2.  Wireless connected automatically; ethernet not connected automatically.
3.  Neither ethernet nor wireless connected automatically.
The first two variations caused the message to appear; the third did not.  In each of the first two, it occurred only after a reboot.  If I tried a second or third time, without an intervening reboot, the message did not appear.

The bug reporting tool thought this is a new bug.  If I see it again with the new number, should it be reported, or is it the same bug?

Couple things:

This IS apparently a functional problem..

> ..connectivity would slow to a crawl, to the point where I had to plug it into >an ethernet connection to get downloads moving again.

The different number isn't a huge thing, it's the same issue.

Appears you may have current fixes in the immediate area already.. hmm.

I'd like to see some more info it you can help:

The output from:
1. lsusb
2. lspci -nn
A log of the time during recreate of the issue (great testing work by the way!): 
3. dmesg > ~/dmesg.txt   

Can you supply these?  Thanks!

Created attachment 737664 [details]
April 18 /var/log/messages

/var/log/messages from April 18, when the message appeared.

Created attachment 737665 [details]
dmesg

Output from dmesg command

Output from lsusb command:
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 002 Device 003: ID 058f:6364 Alcor Micro Corp.

Output from lspci -nn command:
00:00.0 Host bridge [0600]: Intel Corporation Ivy Bridge DRAM Controller [8086:0150] (rev 09)
00:01.0 PCI bridge [0604]: Intel Corporation Ivy Bridge PCI Express Root Port [8086:0151] (rev 09)
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:0162] (rev 09)
00:14.0 USB Controller [0c03]: Intel Corporation Panther Point USB xHCI Host Controller [8086:1e31] (rev 04)
00:16.0 Communication controller [0780]: Intel Corporation Panther Point MEI Controller #1 [8086:1e3a] (rev 04)
00:19.0 Ethernet controller [0200]: Intel Corporation 82579V Gigabit Network Connection [8086:1503] (rev 04)
00:1a.0 USB Controller [0c03]: Intel Corporation Panther Point USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
00:1b.0 Audio device [0403]: Intel Corporation Panther Point High Definition Audio Controller [8086:1e20] (rev 04)
00:1c.0 PCI bridge [0604]: Intel Corporation Panther Point PCI Express Root Port 1 [8086:1e10] (rev c4)
00:1c.4 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev c4)
00:1c.6 PCI bridge [0604]: Intel Corporation Panther Point PCI Express Root Port 7 [8086:1e1c] (rev c4)
00:1c.7 PCI bridge [0604]: Intel Corporation Panther Point PCI Express Root Port 8 [8086:1e1e] (rev c4)
00:1d.0 USB Controller [0c03]: Intel Corporation Panther Point USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
00:1f.0 ISA bridge [0601]: Intel Corporation Panther Point LPC Controller [8086:1e44] (rev 04)
00:1f.2 SATA controller [0106]: Intel Corporation Panther Point 6 port SATA AHCI Controller [8086:1e02] (rev 04)
00:1f.3 SMBus [0c05]: Intel Corporation Panther Point SMBus Controller [8086:1e22] (rev 04)
03:00.0 PCI bridge [0604]: ASMedia Technology Inc. Device [1b21:1080] (rev 03)
05:00.0 Network controller [0280]: Atheros Communications Inc. AR9485 Wireless Network Adapter [168c:0032] (rev 01)
06:00.0 USB Controller [0c03]: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller [1b21:1042]

THanks for the info, will look at this ASAP..

Thank-you.

More weirdness.

I figured out that the monitor wasn't waking up after hibernation if I had wireless disabled in BIOS, but had not blacklisted the wireless driver.  So, I enabled the wireless in BIOS, but that caused a different thing to happen.  When hibernating, there would be 20-30 instances of the following message as it was going down:  ath: phy0: PLL4 measurement not done.  Then the machine would hibernate, and it would later wake up properly.

When I get more testing completed, probably next week, I will file a new bug on this new message I'm getting.  I don't yet know if it occurs when I hibernate and have a wireless connection rather than an ethernet connection.  And, I have another machine which uses the same wireless driver, so need to test to see if that machine now generates the new message and/or doesn't wake properly after hibernation.

(In reply to comment #13)
> Thank-you.
> 
> More weirdness.
> 
> I figured out that the monitor wasn't waking up after hibernation if I had
> wireless disabled in BIOS, but had not blacklisted the wireless driver.  

Implying that it IS ok if you blacklist wireless driver?

Nope.  Didn't mean to imply that.  Sorry.  That is on my list of conditions yet to be tested.  I will try to do the testing in the next couple of days.

Monitor (and probably keyboard & mouse) don't wake up after hibernation only with the following combinations:  wireless disabled in bios and ethernet connecting automatically.  Other combinations, such as sleep rather than hibernate, wireless enabled in bios, wireless blacklisted, wireless connected but not ethernet, no connection, etc., did not cause hibernation to fail.  I'll submit a bug to Network Manager.

I have not seen the "ath: phy0: PLL4 measurement not done" message since Thursday.  The other machine that uses the same wireless driver does not have the option to disable wireless in bios.  It has a switch on the side of the machine to turn wireless on or off, and that made no difference in hibernation.

I did see the WARNING message (this bug) again today twice after hibernation, both times with ethernet connecting automatically.

I did some digging on this PLL4 issue.  This appears to be common issue, with no clear resolution. Perhaps some insight, still working on it.  

Can you try one thing, Greta?

If you have not already, can you try loading the driver with btcoex_enable=0?  I don't *think* it's a fix but might be a workaround and point me in a better direction.  

So can you try something along this line?

modprobe -r ath9k
modprobe ath9k btcoex_enable=0

then see if hibernate/restore creates issue.

Right now, my machine has the following settings:
  wireless enabled in bios,
  ethernet connected automatically,
  wireless not connected automatically,
  and ath9k not blacklisted.

First I did a hibernation.  Got the "ath: phy0: PLL4 measurement not done" message.  Woke the machine up.  Got the "WARNING: at drivers/net/wireless/ath/ath9k/hw.c:794 ar9003_get_pll_sqsum_dvc+0xb6/0xc0 [ath9k_hw]()" message.

Then I did the following as root:
    modprobe -r ath9k
    modprobe ath9k btcoex_enable=0

After that, I did the hibernate and wake again.  It had exactly the same messages as the first hibernate and wake.

*** Bug 893713 has been marked as a duplicate of this bug. ***

Ok, that helps me know which way to go better.  Will continue shortly.  Getting a release out.. Bear with me.

Description of problem:
Connecting to saved wireless network.

Version-Release number of selected component:
kernel

Additional info:
reporter:       libreport-2.1.4
cmdline:        BOOT_IMAGE=/vmlinuz-3.9.4-200.fc18.x86_64 root=/dev/mapper/fedora_fedorahtb-root ro rd.md=0 rd.dm=0 rd.lvm.lv=fedora_fedorahtb/swap vconsole.keymap=cz-lat2 rd.luks=0 rd.lvm.lv=fedora_fedorahtb/root rhgb quiet
kernel:         3.9.4-200.fc18.x86_64
runlevel:       N 5
type:           Kerneloops

Truncated backtrace:
WARNING: at drivers/net/wireless/ath/ath9k/hw.c:780 ar9003_get_pll_sqsum_dvc+0xb6/0xc0 [ath9k_hw]()
Hardware name: HP ProBook 4540s
Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec acpi_cpufreq arc4 mperf snd_hwdep ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 snd_seq coretemp snd_seq_device hp_wmi sparse_keymap ath3k btusb bluetooth rfkill snd_pcm snd_page_alloc snd_timer snd soundcore iTCO_wdt iTCO_vendor_support serio_raw kvm_intel kvm hp_accel lis3lv02d input_polldev microcode r8169 mii lpc_ich jmb38x_ms mfd_core memstick mei uinput binfmt_misc i915 crc32_pclmul crc32c_intel ghash_clmulni_intel i2c_algo_bit drm_kms_helper sdhci_pci drm sdhci mmc_core i2c_core wmi video
Pid: 11474, comm: kworker/u:0 Not tainted 3.9.4-200.fc18.x86_64 #1
Call Trace:
 [<ffffffff8105f125>] warn_slowpath_common+0x75/0xa0
 [<ffffffff8105f16a>] warn_slowpath_null+0x1a/0x20
 [<ffffffffa047bc76>] ar9003_get_pll_sqsum_dvc+0xb6/0xc0 [ath9k_hw]
 [<ffffffffa04ed473>] ath_hw_pll_work+0x53/0xd0 [ath9k]
 [<ffffffff8107b7a3>] process_one_work+0x173/0x3c0
 [<ffffffff8107d0cf>] worker_thread+0x10f/0x390
 [<ffffffff8107cfc0>] ? busy_worker_rebind_fn+0xb0/0xb0
 [<ffffffff81082c70>] kthread+0xc0/0xd0
 [<ffffffff81010000>] ? ftrace_define_fields_xen_mc_flush+0x20/0xb0
 [<ffffffff81082bb0>] ? kthread_create_on_node+0x120/0x120
 [<ffffffff81669eac>] ret_from_fork+0x7c/0xb0
 [<ffffffff81082bb0>] ? kthread_create_on_node+0x120/0x120

this seems to affect other distros, too :

https://bugs.mageia.org/show_bug.cgi?id=10223
http://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg17463.html

...and i'm seeing it on opensuse.

is there an upstream bugreport to link all these in ?

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Haven't had time to check on this, but it's a common issue.  No fixes yet upstream for this specifically. 
I'm moving it forward as still valid issue, it  should be addressed.
Can anyone try later kernel than 3.9.4?
Can't reproduce it here..

I see a lot of upstream changes, just nothing specific to this.
Thanks!

Got the message just this morning:
WARNING: at drivers/net/wireless/ath/ath9k/hw.c:780 ar9003_get_pll_sqsum_dvc+0xb6/0xc0 [ath9k_hw]()

Only the first number (780 instead of 786) is different.

On Fedora 19, running kernel 3.9.9-302.fc19.x86_64.

Circumstances are similar to comment 18.  However, this one occurred on wake from sleep.  Hibernation doesn't seem to be working at the moment--the screen never wakes up.

Of course, now that I said hibernation isn't working, I decided to try it.  It works this morning.  And it didn't produce the message this time.  However, I got a ton of the "ath: phy0: PLL4 measurement not done" messages while it was on the way down.  I've been putting the machine to sleep nightly, and have gotten the wireless message many, but not all, mornings in the past couple of weeks.

https://bugzilla.kernel.org/show_bug.cgi?id=53771

This issue just hit me this morning during a normal boot, haven't seen it before, until today, the running kernel is 3.9.9-302.fc19.x86_64, and I have a lot of these messages in the logs:

Jul 27 10:47:11 asus-0 kernel: [ 8376.860308] ath: phy0: PLL4 meaurement not done

But they stopped again after about an hour.
I'm on vacation, and sharing my 3G from my phone via Wifi, and had been walking away with my phone a couple of times.

The sequence of events seems to be (As far as I can see from the logs, and what happened this morning), that the laptop was associated, then I received a call, and walked away from the machine, the connection disappeared, and at some point, it could see the phone again, tried to associate again, but that timed out, and the log messages started.

The other comments seems to be related to suspend/resume, but normally, I never use any of that, so always doing clean boots.

If there is any interest, I can provide the logs and other info if needed.

Description of problem:
I am not sure what caused this problem, but the ath9k wifi driver is horrid at the moment, I loose connection very often, have a low signal strength all the time and on the same machine in the same physical location booted to windows I get at least double the number of access points listed.
The network I use is on the same AP as another 3 networks (SSIDs) often I will loose connection to the one I am using and still see the other three as available.
Often after boot I will see 1 to 3 networks listed with the one I want to connect to not listed, though they are all on the same AP.
On windows I get at least 3/4 signal strength almost consistently, in Fedora I get -90dbm or worse.

Version-Release number of selected component:
kernel

Additional info:
reporter:       libreport-2.1.5
cmdline:        BOOT_IMAGE=/vmlinuz-3.9.11-200.fc18.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 rd.luks=0 rd.lvm.lv=fedora/root vconsole.keymap=uk rhgb quiet LANG=en_GB.UTF-8
kernel:         3.9.11-200.fc18.x86_64
runlevel:       N 5
type:           Kerneloops

Truncated backtrace:
WARNING: at drivers/net/wireless/ath/ath9k/hw.c:780 ar9003_get_pll_sqsum_dvc+0xb6/0xc0 [ath9k_hw]()
Hardware name: UX31E
Modules linked in: vfat fat tcp_lp usb_storage fuse ebtable_nat nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi rfcomm bnep iTCO_wdt iTCO_vendor_support asus_nb_wmi asus_wmi sparse_keymap snd_hda_codec_hdmi arc4 acpi_cpufreq mperf coretemp snd_hda_codec_realtek ath9k ath9k_common microcode ath9k_hw ath3k ath joydev snd_hda_intel uvcvideo videobuf2_vmalloc mac80211 videobuf2_memops serio_raw snd_hda_codec btusb videobuf2_core i2c_i801 videodev bluetooth snd_hwdep media snd_seq snd_seq_device snd_pcm cfg80211 lpc_ich snd_page_alloc mfd_core snd_timer rfkill snd mei soundcore vhost_net tun macvtap macvlan kvm_intel kvm uinput crc32_pclmul crc32c_intel i915 i2c_algo_bit ghash_clmulni_intel drm_kms_helper drm i2c_core wmi video sunrpc
Pid: 10472, comm: kworker/u:47 Not tainted 3.9.11-200.fc18.x86_64 #1
Call Trace:
 [<ffffffff8105efc5>] warn_slowpath_common+0x75/0xa0
 [<ffffffff8105f00a>] warn_slowpath_null+0x1a/0x20
 [<ffffffffa04f9c76>] ar9003_get_pll_sqsum_dvc+0xb6/0xc0 [ath9k_hw]
 [<ffffffffa0570443>] ath_hw_pll_work+0x53/0xd0 [ath9k]
 [<ffffffff8107b663>] process_one_work+0x173/0x3c0
 [<ffffffff8107cf8f>] worker_thread+0x10f/0x390
 [<ffffffff8107ce80>] ? busy_worker_rebind_fn+0xb0/0xb0
 [<ffffffff81082b00>] kthread+0xc0/0xd0
 [<ffffffff81010000>] ? ftrace_define_fields_xen_mc_flush+0x80/0xb0
 [<ffffffff81082a40>] ? kthread_create_on_node+0x120/0x120
 [<ffffffff81667eec>] ret_from_fork+0x7c/0xb0
 [<ffffffff81082a40>] ? kthread_create_on_node+0x120/0x120

*** Bug 967967 has been marked as a duplicate of this bug. ***

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

The bug does not seem to be present with the current kernel.  However, I cannot be 100% sure, as sometimes the wake from hibernation does not wake up the monitor (bug 957972).

Thanks for the update Greta..just to confirm you are using  3.11.1-200.fc19?

Yes, 3.11.1-200.fc19.x86_64.  Sorry, I should have mentioned that.

Thanks Greta.  Can anyone else chime in on the issue persisting on 3.11.1-200.fc19?

Think I know why it's fixed for the record:

19c361608ce3e73f352e323262f7e0a8264be3af (patch)

ath9k: Enable PLL fix only for AR9340/AR9330
The PLL hang workaround is required only for AR9330 and AR9340. This issue was first observed on an AP121 and the WAR is enabled for AR9340 also (DB120 etc.), since it uses a PLL design identical to AR9330. This is not required for AR9485 and AR9550. 

So, marking this closed: fixed in kernel Version 3.11.1-200

The bug has not surfaced since the needinfo flag was set in comment 36.  The bug  has been closed as fixed.  I'm currently using 3.14.4-100.fc19.x86_64.

(In reply to Greta Watson from comment #38)
> The bug has not surfaced since the needinfo flag was set in comment 36.  The
> bug  has been closed as fixed.  I'm currently using 3.14.4-100.fc19.x86_64.

Good!  Thanks Greta..