All of lore.kernel.org
 help / color / mirror / Atom feed
* [ath9k-devel] ath9k (AR9485) failing with PCI errors after hours of uptime with current ath9k.ko from linux-wireless
@ 2013-05-08 21:41 Joel Diaz
  2013-05-08 22:35 ` Adrian Chadd
  0 siblings, 1 reply; 8+ messages in thread
From: Joel Diaz @ 2013-05-08 21:41 UTC (permalink / raw)
  To: ath9k-devel

First some background: starting with Debian Wheezy I noticed my wireless
connection would fail after hours (sometime as quick as 15 minutes) of
uptime. Moving from Debian's 3.2 kernel to upstream's 3.9-RCs also
showed the problem.

Yesterday I pulled the linux-wireless git repo and built myself a kernel
(starting with Debian Wheezy's kernel config) with HEAD pointing to:

commit e514a9747148e3786879cc5430775a854441ba38
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu May 2 09:43:57 2013 +0200

    ath5k: do not reschedule tx_complete_work on stop

After about 10 hours of uptime with the system basically idle (since I
was at work) I see the failure:

[38951.779076] ath: phy0: received PCI FATAL interrupt
[38951.779081] ath: phy0: received PCI PERR interrupt
[38951.789851] ath: phy0: Failed to wakeup in 500us
[38951.789853] ------------[ cut here ]------------
[38951.789866] WARNING: at drivers/net/wireless/ath/ath9k/hw.c:2231
ath9k_hw_setpower+0x446/0x499 [ath9k_hw]()
[38951.789868] Hardware name: Inspiron One 2020
[38951.789870] Modules linked in: isofs udf crc_itu_t bnep rfcomm
binfmt_misc loop hid_generic usbhid hid ath3k btusb bluetooth
snd_hda_codec_realtek coretemp ehci_pci kvm_intel snd_hda_intel kvm
snd_hda_codec ehci_hcd arc4 snd_hwdep ath9k ath9k_common ath9k_hw ath
mac80211 usbcore i915 cfg80211 snd_pcm drm_kms_helper drm iTCO_wdt
iTCO_vendor_support snd_page_alloc i2c_algo_bit i2c_i801 i2c_core
snd_timer acpi_cpufreq mperf crc32c_intel ghash_clmulni_intel lpc_ich
mfd_core sparse_keymap rfkill evdev snd video dcdbas usb_common psmouse
cryptd wmi processor button soundcore pcspkr serio_raw microcode ext4
crc16 jbd2 mbcache sg sr_mod sd_mod cdrom crc_t10dif ata_generic thermal
fan thermal_sys ata_piix libata scsi_mod r8169 mii
[38951.789929] Pid: 0, comm: swapper/0 Not tainted 3.9.0ath9-wl+ #3
[38951.789931] Call Trace:
[38951.789933]  <IRQ>  [<ffffffff8103d500>] ? warn_slowpath_common
+0x76/0x8c
[38951.789946]  [<ffffffffa044e166>] ? ath9k_hw_setpower+0x446/0x499
[ath9k_hw]
[38951.789954]  [<ffffffffa0395b11>] ? ath9k_ps_wakeup+0x4c/0xa9 [ath9k]
[38951.789960]  [<ffffffffa0397374>] ? ath9k_tasklet+0x24/0x131 [ath9k]
[38951.789964]  [<ffffffff81044000>] ? tasklet_action+0x73/0xc2
[38951.789968]  [<ffffffff81043c61>] ? __do_softirq+0xe2/0x1f7
[38951.789971]  [<ffffffff81043e41>] ? irq_exit+0x3f/0x82
[38951.789975]  [<ffffffff8102c301>] ? __x2apic_send_IPI_mask+0xb9/0x140
[38951.789979]  [<ffffffff8100f701>] ? do_IRQ+0x81/0x97
[38951.789984]  [<ffffffff813856ed>] ? common_interrupt+0x6d/0x6d
[38951.789985]  <EOI>  [<ffffffff8129f3d8>] ? arch_local_irq_enable
+0x4/0x8
[38951.789994]  [<ffffffff8129fa5c>] ? cpuidle_wrap_enter+0x3c/0x71
[38951.789999]  [<ffffffff8129f78e>] ? cpuidle_enter_state+0xa/0x2f
[38951.790002]  [<ffffffff8129f85c>] ? cpuidle_idle_call+0xa9/0xfb
[38951.790007]  [<ffffffff81014c6f>] ? cpu_idle+0x9c/0xe6
[38951.790011]  [<ffffffff816aed23>] ? start_kernel+0x3b8/0x3c3
[38951.790014]  [<ffffffff816ae781>] ? repair_env_string+0x57/0x57
[38951.790018]  [<ffffffff816ae59c>] ? x86_64_start_kernel+0xf2/0xfd
[38951.790021] ---[ end trace bff1151979a9309c ]---
[38951.800533] ath: phy0: Failed to wakeup in 500us
[38951.865086] ath: phy0: Failed to stop TX DMA, queues=0x10f!
[38951.876459] ath: phy0: DMA failed to stop in 10 ms AR_CR=0xffffffff
AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
[38951.876494] ath: phy0: Could not stop RX, we could be confusing the
DMA engine when we start RX up

At this point the wireless connection is gone and can't be restored
without a full reboot.

In the past while looking at this with the upstream RC kernels I tried
setting ath9k.debug=0xffffffff, but it didn't seem to add anything
useful ( https://bugzilla.kernel.org/show_bug.cgi?id=56301 ).

Since the full kern.log is over 50 megs (lots of repeated error
messages) I'm only attaching the first 1000 lines which should be more
than enough.

Not sure where to go from here since I'm using the most current ath9k
that I could find. Is there anything else I could do to help get to the
bottom of this issue?

Joel






-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-wireless-edited-kern.log.gz
Type: application/x-gzip
Size: 17199 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130508/8b90ce89/attachment.bin 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ath9k-devel] ath9k (AR9485) failing with PCI errors after hours of uptime with current ath9k.ko from linux-wireless
  2013-05-08 21:41 [ath9k-devel] ath9k (AR9485) failing with PCI errors after hours of uptime with current ath9k.ko from linux-wireless Joel Diaz
@ 2013-05-08 22:35 ` Adrian Chadd
  2013-05-09  0:21   ` Joel Diaz
  0 siblings, 1 reply; 8+ messages in thread
From: Adrian Chadd @ 2013-05-08 22:35 UTC (permalink / raw)
  To: ath9k-devel

Step 0 - disable station mode power save; see if that has any impact.



adrian


On 8 May 2013 14:41, Joel Diaz <joeldiaz@earthlink.net> wrote:
> First some background: starting with Debian Wheezy I noticed my wireless
> connection would fail after hours (sometime as quick as 15 minutes) of
> uptime. Moving from Debian's 3.2 kernel to upstream's 3.9-RCs also
> showed the problem.
>
> Yesterday I pulled the linux-wireless git repo and built myself a kernel
> (starting with Debian Wheezy's kernel config) with HEAD pointing to:
>
> commit e514a9747148e3786879cc5430775a854441ba38
> Author: Stanislaw Gruszka <sgruszka@redhat.com>
> Date:   Thu May 2 09:43:57 2013 +0200
>
>     ath5k: do not reschedule tx_complete_work on stop
>
> After about 10 hours of uptime with the system basically idle (since I
> was at work) I see the failure:
>
> [38951.779076] ath: phy0: received PCI FATAL interrupt
> [38951.779081] ath: phy0: received PCI PERR interrupt
> [38951.789851] ath: phy0: Failed to wakeup in 500us
> [38951.789853] ------------[ cut here ]------------
> [38951.789866] WARNING: at drivers/net/wireless/ath/ath9k/hw.c:2231
> ath9k_hw_setpower+0x446/0x499 [ath9k_hw]()
> [38951.789868] Hardware name: Inspiron One 2020
> [38951.789870] Modules linked in: isofs udf crc_itu_t bnep rfcomm
> binfmt_misc loop hid_generic usbhid hid ath3k btusb bluetooth
> snd_hda_codec_realtek coretemp ehci_pci kvm_intel snd_hda_intel kvm
> snd_hda_codec ehci_hcd arc4 snd_hwdep ath9k ath9k_common ath9k_hw ath
> mac80211 usbcore i915 cfg80211 snd_pcm drm_kms_helper drm iTCO_wdt
> iTCO_vendor_support snd_page_alloc i2c_algo_bit i2c_i801 i2c_core
> snd_timer acpi_cpufreq mperf crc32c_intel ghash_clmulni_intel lpc_ich
> mfd_core sparse_keymap rfkill evdev snd video dcdbas usb_common psmouse
> cryptd wmi processor button soundcore pcspkr serio_raw microcode ext4
> crc16 jbd2 mbcache sg sr_mod sd_mod cdrom crc_t10dif ata_generic thermal
> fan thermal_sys ata_piix libata scsi_mod r8169 mii
> [38951.789929] Pid: 0, comm: swapper/0 Not tainted 3.9.0ath9-wl+ #3
> [38951.789931] Call Trace:
> [38951.789933]  <IRQ>  [<ffffffff8103d500>] ? warn_slowpath_common
> +0x76/0x8c
> [38951.789946]  [<ffffffffa044e166>] ? ath9k_hw_setpower+0x446/0x499
> [ath9k_hw]
> [38951.789954]  [<ffffffffa0395b11>] ? ath9k_ps_wakeup+0x4c/0xa9 [ath9k]
> [38951.789960]  [<ffffffffa0397374>] ? ath9k_tasklet+0x24/0x131 [ath9k]
> [38951.789964]  [<ffffffff81044000>] ? tasklet_action+0x73/0xc2
> [38951.789968]  [<ffffffff81043c61>] ? __do_softirq+0xe2/0x1f7
> [38951.789971]  [<ffffffff81043e41>] ? irq_exit+0x3f/0x82
> [38951.789975]  [<ffffffff8102c301>] ? __x2apic_send_IPI_mask+0xb9/0x140
> [38951.789979]  [<ffffffff8100f701>] ? do_IRQ+0x81/0x97
> [38951.789984]  [<ffffffff813856ed>] ? common_interrupt+0x6d/0x6d
> [38951.789985]  <EOI>  [<ffffffff8129f3d8>] ? arch_local_irq_enable
> +0x4/0x8
> [38951.789994]  [<ffffffff8129fa5c>] ? cpuidle_wrap_enter+0x3c/0x71
> [38951.789999]  [<ffffffff8129f78e>] ? cpuidle_enter_state+0xa/0x2f
> [38951.790002]  [<ffffffff8129f85c>] ? cpuidle_idle_call+0xa9/0xfb
> [38951.790007]  [<ffffffff81014c6f>] ? cpu_idle+0x9c/0xe6
> [38951.790011]  [<ffffffff816aed23>] ? start_kernel+0x3b8/0x3c3
> [38951.790014]  [<ffffffff816ae781>] ? repair_env_string+0x57/0x57
> [38951.790018]  [<ffffffff816ae59c>] ? x86_64_start_kernel+0xf2/0xfd
> [38951.790021] ---[ end trace bff1151979a9309c ]---
> [38951.800533] ath: phy0: Failed to wakeup in 500us
> [38951.865086] ath: phy0: Failed to stop TX DMA, queues=0x10f!
> [38951.876459] ath: phy0: DMA failed to stop in 10 ms AR_CR=0xffffffff
> AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
> [38951.876494] ath: phy0: Could not stop RX, we could be confusing the
> DMA engine when we start RX up
>
> At this point the wireless connection is gone and can't be restored
> without a full reboot.
>
> In the past while looking at this with the upstream RC kernels I tried
> setting ath9k.debug=0xffffffff, but it didn't seem to add anything
> useful ( https://bugzilla.kernel.org/show_bug.cgi?id=56301 ).
>
> Since the full kern.log is over 50 megs (lots of repeated error
> messages) I'm only attaching the first 1000 lines which should be more
> than enough.
>
> Not sure where to go from here since I'm using the most current ath9k
> that I could find. Is there anything else I could do to help get to the
> bottom of this issue?
>
> Joel
>
>
>
>
>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ath9k-devel] ath9k (AR9485) failing with PCI errors after hours of uptime with current ath9k.ko from linux-wireless
  2013-05-08 22:35 ` Adrian Chadd
@ 2013-05-09  0:21   ` Joel Diaz
  2013-05-09  5:10     ` Adrian Chadd
  0 siblings, 1 reply; 8+ messages in thread
From: Joel Diaz @ 2013-05-09  0:21 UTC (permalink / raw)
  To: ath9k-devel

On Wed, 2013-05-08 at 15:35 -0700, Adrian Chadd wrote:
> Step 0 - disable station mode power save; see if that has any impact.
> 
> 
The base station is an Apple Airport Extreme (version 7.6.3 in case that
matters). I don't see anything in the settings for power saving. And a
google search didn't help much.

Joel
> 
> adrian
> 
> 
> On 8 May 2013 14:41, Joel Diaz <joeldiaz@earthlink.net> wrote:
> > First some background: starting with Debian Wheezy I noticed my wireless
> > connection would fail after hours (sometime as quick as 15 minutes) of
> > uptime. Moving from Debian's 3.2 kernel to upstream's 3.9-RCs also
> > showed the problem.
> >
> > Yesterday I pulled the linux-wireless git repo and built myself a kernel
> > (starting with Debian Wheezy's kernel config) with HEAD pointing to:
> >
> > commit e514a9747148e3786879cc5430775a854441ba38
> > Author: Stanislaw Gruszka <sgruszka@redhat.com>
> > Date:   Thu May 2 09:43:57 2013 +0200
> >
> >     ath5k: do not reschedule tx_complete_work on stop
> >
> > After about 10 hours of uptime with the system basically idle (since I
> > was at work) I see the failure:
> >
> > [38951.779076] ath: phy0: received PCI FATAL interrupt
> > [38951.779081] ath: phy0: received PCI PERR interrupt
> > [38951.789851] ath: phy0: Failed to wakeup in 500us
> > [38951.789853] ------------[ cut here ]------------
> > [38951.789866] WARNING: at drivers/net/wireless/ath/ath9k/hw.c:2231
> > ath9k_hw_setpower+0x446/0x499 [ath9k_hw]()
> > [38951.789868] Hardware name: Inspiron One 2020
> > [38951.789870] Modules linked in: isofs udf crc_itu_t bnep rfcomm
> > binfmt_misc loop hid_generic usbhid hid ath3k btusb bluetooth
> > snd_hda_codec_realtek coretemp ehci_pci kvm_intel snd_hda_intel kvm
> > snd_hda_codec ehci_hcd arc4 snd_hwdep ath9k ath9k_common ath9k_hw ath
> > mac80211 usbcore i915 cfg80211 snd_pcm drm_kms_helper drm iTCO_wdt
> > iTCO_vendor_support snd_page_alloc i2c_algo_bit i2c_i801 i2c_core
> > snd_timer acpi_cpufreq mperf crc32c_intel ghash_clmulni_intel lpc_ich
> > mfd_core sparse_keymap rfkill evdev snd video dcdbas usb_common psmouse
> > cryptd wmi processor button soundcore pcspkr serio_raw microcode ext4
> > crc16 jbd2 mbcache sg sr_mod sd_mod cdrom crc_t10dif ata_generic thermal
> > fan thermal_sys ata_piix libata scsi_mod r8169 mii
> > [38951.789929] Pid: 0, comm: swapper/0 Not tainted 3.9.0ath9-wl+ #3
> > [38951.789931] Call Trace:
> > [38951.789933]  <IRQ>  [<ffffffff8103d500>] ? warn_slowpath_common
> > +0x76/0x8c
> > [38951.789946]  [<ffffffffa044e166>] ? ath9k_hw_setpower+0x446/0x499
> > [ath9k_hw]
> > [38951.789954]  [<ffffffffa0395b11>] ? ath9k_ps_wakeup+0x4c/0xa9 [ath9k]
> > [38951.789960]  [<ffffffffa0397374>] ? ath9k_tasklet+0x24/0x131 [ath9k]
> > [38951.789964]  [<ffffffff81044000>] ? tasklet_action+0x73/0xc2
> > [38951.789968]  [<ffffffff81043c61>] ? __do_softirq+0xe2/0x1f7
> > [38951.789971]  [<ffffffff81043e41>] ? irq_exit+0x3f/0x82
> > [38951.789975]  [<ffffffff8102c301>] ? __x2apic_send_IPI_mask+0xb9/0x140
> > [38951.789979]  [<ffffffff8100f701>] ? do_IRQ+0x81/0x97
> > [38951.789984]  [<ffffffff813856ed>] ? common_interrupt+0x6d/0x6d
> > [38951.789985]  <EOI>  [<ffffffff8129f3d8>] ? arch_local_irq_enable
> > +0x4/0x8
> > [38951.789994]  [<ffffffff8129fa5c>] ? cpuidle_wrap_enter+0x3c/0x71
> > [38951.789999]  [<ffffffff8129f78e>] ? cpuidle_enter_state+0xa/0x2f
> > [38951.790002]  [<ffffffff8129f85c>] ? cpuidle_idle_call+0xa9/0xfb
> > [38951.790007]  [<ffffffff81014c6f>] ? cpu_idle+0x9c/0xe6
> > [38951.790011]  [<ffffffff816aed23>] ? start_kernel+0x3b8/0x3c3
> > [38951.790014]  [<ffffffff816ae781>] ? repair_env_string+0x57/0x57
> > [38951.790018]  [<ffffffff816ae59c>] ? x86_64_start_kernel+0xf2/0xfd
> > [38951.790021] ---[ end trace bff1151979a9309c ]---
> > [38951.800533] ath: phy0: Failed to wakeup in 500us
> > [38951.865086] ath: phy0: Failed to stop TX DMA, queues=0x10f!
> > [38951.876459] ath: phy0: DMA failed to stop in 10 ms AR_CR=0xffffffff
> > AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
> > [38951.876494] ath: phy0: Could not stop RX, we could be confusing the
> > DMA engine when we start RX up
> >
> > At this point the wireless connection is gone and can't be restored
> > without a full reboot.
> >
> > In the past while looking at this with the upstream RC kernels I tried
> > setting ath9k.debug=0xffffffff, but it didn't seem to add anything
> > useful ( https://bugzilla.kernel.org/show_bug.cgi?id=56301 ).
> >
> > Since the full kern.log is over 50 megs (lots of repeated error
> > messages) I'm only attaching the first 1000 lines which should be more
> > than enough.
> >
> > Not sure where to go from here since I'm using the most current ath9k
> > that I could find. Is there anything else I could do to help get to the
> > bottom of this issue?
> >
> > Joel
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ath9k-devel] ath9k (AR9485) failing with PCI errors after hours of uptime with current ath9k.ko from linux-wireless
  2013-05-09  0:21   ` Joel Diaz
@ 2013-05-09  5:10     ` Adrian Chadd
  2013-05-09 11:32       ` Joel Diaz
  2013-05-13 11:28       ` Joel Diaz
  0 siblings, 2 replies; 8+ messages in thread
From: Adrian Chadd @ 2013-05-09  5:10 UTC (permalink / raw)
  To: ath9k-devel

No, I mean - there's an iw command to disable entering power save on
your linux station. Find that and disable it.



Adrian

On 8 May 2013 17:21, Joel Diaz <joeldiaz@earthlink.net> wrote:
> On Wed, 2013-05-08 at 15:35 -0700, Adrian Chadd wrote:
>> Step 0 - disable station mode power save; see if that has any impact.
>>
>>
> The base station is an Apple Airport Extreme (version 7.6.3 in case that
> matters). I don't see anything in the settings for power saving. And a
> google search didn't help much.
>
> Joel
>>
>> adrian
>>
>>
>> On 8 May 2013 14:41, Joel Diaz <joeldiaz@earthlink.net> wrote:
>> > First some background: starting with Debian Wheezy I noticed my wireless
>> > connection would fail after hours (sometime as quick as 15 minutes) of
>> > uptime. Moving from Debian's 3.2 kernel to upstream's 3.9-RCs also
>> > showed the problem.
>> >
>> > Yesterday I pulled the linux-wireless git repo and built myself a kernel
>> > (starting with Debian Wheezy's kernel config) with HEAD pointing to:
>> >
>> > commit e514a9747148e3786879cc5430775a854441ba38
>> > Author: Stanislaw Gruszka <sgruszka@redhat.com>
>> > Date:   Thu May 2 09:43:57 2013 +0200
>> >
>> >     ath5k: do not reschedule tx_complete_work on stop
>> >
>> > After about 10 hours of uptime with the system basically idle (since I
>> > was at work) I see the failure:
>> >
>> > [38951.779076] ath: phy0: received PCI FATAL interrupt
>> > [38951.779081] ath: phy0: received PCI PERR interrupt
>> > [38951.789851] ath: phy0: Failed to wakeup in 500us
>> > [38951.789853] ------------[ cut here ]------------
>> > [38951.789866] WARNING: at drivers/net/wireless/ath/ath9k/hw.c:2231
>> > ath9k_hw_setpower+0x446/0x499 [ath9k_hw]()
>> > [38951.789868] Hardware name: Inspiron One 2020
>> > [38951.789870] Modules linked in: isofs udf crc_itu_t bnep rfcomm
>> > binfmt_misc loop hid_generic usbhid hid ath3k btusb bluetooth
>> > snd_hda_codec_realtek coretemp ehci_pci kvm_intel snd_hda_intel kvm
>> > snd_hda_codec ehci_hcd arc4 snd_hwdep ath9k ath9k_common ath9k_hw ath
>> > mac80211 usbcore i915 cfg80211 snd_pcm drm_kms_helper drm iTCO_wdt
>> > iTCO_vendor_support snd_page_alloc i2c_algo_bit i2c_i801 i2c_core
>> > snd_timer acpi_cpufreq mperf crc32c_intel ghash_clmulni_intel lpc_ich
>> > mfd_core sparse_keymap rfkill evdev snd video dcdbas usb_common psmouse
>> > cryptd wmi processor button soundcore pcspkr serio_raw microcode ext4
>> > crc16 jbd2 mbcache sg sr_mod sd_mod cdrom crc_t10dif ata_generic thermal
>> > fan thermal_sys ata_piix libata scsi_mod r8169 mii
>> > [38951.789929] Pid: 0, comm: swapper/0 Not tainted 3.9.0ath9-wl+ #3
>> > [38951.789931] Call Trace:
>> > [38951.789933]  <IRQ>  [<ffffffff8103d500>] ? warn_slowpath_common
>> > +0x76/0x8c
>> > [38951.789946]  [<ffffffffa044e166>] ? ath9k_hw_setpower+0x446/0x499
>> > [ath9k_hw]
>> > [38951.789954]  [<ffffffffa0395b11>] ? ath9k_ps_wakeup+0x4c/0xa9 [ath9k]
>> > [38951.789960]  [<ffffffffa0397374>] ? ath9k_tasklet+0x24/0x131 [ath9k]
>> > [38951.789964]  [<ffffffff81044000>] ? tasklet_action+0x73/0xc2
>> > [38951.789968]  [<ffffffff81043c61>] ? __do_softirq+0xe2/0x1f7
>> > [38951.789971]  [<ffffffff81043e41>] ? irq_exit+0x3f/0x82
>> > [38951.789975]  [<ffffffff8102c301>] ? __x2apic_send_IPI_mask+0xb9/0x140
>> > [38951.789979]  [<ffffffff8100f701>] ? do_IRQ+0x81/0x97
>> > [38951.789984]  [<ffffffff813856ed>] ? common_interrupt+0x6d/0x6d
>> > [38951.789985]  <EOI>  [<ffffffff8129f3d8>] ? arch_local_irq_enable
>> > +0x4/0x8
>> > [38951.789994]  [<ffffffff8129fa5c>] ? cpuidle_wrap_enter+0x3c/0x71
>> > [38951.789999]  [<ffffffff8129f78e>] ? cpuidle_enter_state+0xa/0x2f
>> > [38951.790002]  [<ffffffff8129f85c>] ? cpuidle_idle_call+0xa9/0xfb
>> > [38951.790007]  [<ffffffff81014c6f>] ? cpu_idle+0x9c/0xe6
>> > [38951.790011]  [<ffffffff816aed23>] ? start_kernel+0x3b8/0x3c3
>> > [38951.790014]  [<ffffffff816ae781>] ? repair_env_string+0x57/0x57
>> > [38951.790018]  [<ffffffff816ae59c>] ? x86_64_start_kernel+0xf2/0xfd
>> > [38951.790021] ---[ end trace bff1151979a9309c ]---
>> > [38951.800533] ath: phy0: Failed to wakeup in 500us
>> > [38951.865086] ath: phy0: Failed to stop TX DMA, queues=0x10f!
>> > [38951.876459] ath: phy0: DMA failed to stop in 10 ms AR_CR=0xffffffff
>> > AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
>> > [38951.876494] ath: phy0: Could not stop RX, we could be confusing the
>> > DMA engine when we start RX up
>> >
>> > At this point the wireless connection is gone and can't be restored
>> > without a full reboot.
>> >
>> > In the past while looking at this with the upstream RC kernels I tried
>> > setting ath9k.debug=0xffffffff, but it didn't seem to add anything
>> > useful ( https://bugzilla.kernel.org/show_bug.cgi?id=56301 ).
>> >
>> > Since the full kern.log is over 50 megs (lots of repeated error
>> > messages) I'm only attaching the first 1000 lines which should be more
>> > than enough.
>> >
>> > Not sure where to go from here since I'm using the most current ath9k
>> > that I could find. Is there anything else I could do to help get to the
>> > bottom of this issue?
>> >
>> > Joel
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > ath9k-devel mailing list
>> > ath9k-devel at lists.ath9k.org
>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>> >
>
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ath9k-devel] ath9k (AR9485) failing with PCI errors after hours of uptime with current ath9k.ko from linux-wireless
  2013-05-09  5:10     ` Adrian Chadd
@ 2013-05-09 11:32       ` Joel Diaz
  2013-05-13 11:28       ` Joel Diaz
  1 sibling, 0 replies; 8+ messages in thread
From: Joel Diaz @ 2013-05-09 11:32 UTC (permalink / raw)
  To: ath9k-devel

On Wed, 2013-05-08 at 22:10 -0700, Adrian Chadd wrote:
> No, I mean - there's an iw command to disable entering power save on
> your linux station. Find that and disable it.
> 
> 
Ok, it's now off. Now I'll just wait and see.

Joel
> 
> Adrian
> 
> On 8 May 2013 17:21, Joel Diaz <joeldiaz@earthlink.net> wrote:
> > On Wed, 2013-05-08 at 15:35 -0700, Adrian Chadd wrote:
> >> Step 0 - disable station mode power save; see if that has any impact.
> >>
> >>
> > The base station is an Apple Airport Extreme (version 7.6.3 in case that
> > matters). I don't see anything in the settings for power saving. And a
> > google search didn't help much.
> >
> > Joel
> >>
> >> adrian
> >>
> >>
> >> On 8 May 2013 14:41, Joel Diaz <joeldiaz@earthlink.net> wrote:
> >> > First some background: starting with Debian Wheezy I noticed my wireless
> >> > connection would fail after hours (sometime as quick as 15 minutes) of
> >> > uptime. Moving from Debian's 3.2 kernel to upstream's 3.9-RCs also
> >> > showed the problem.
> >> >
> >> > Yesterday I pulled the linux-wireless git repo and built myself a kernel
> >> > (starting with Debian Wheezy's kernel config) with HEAD pointing to:
> >> >
> >> > commit e514a9747148e3786879cc5430775a854441ba38
> >> > Author: Stanislaw Gruszka <sgruszka@redhat.com>
> >> > Date:   Thu May 2 09:43:57 2013 +0200
> >> >
> >> >     ath5k: do not reschedule tx_complete_work on stop
> >> >
> >> > After about 10 hours of uptime with the system basically idle (since I
> >> > was at work) I see the failure:
> >> >
> >> > [38951.779076] ath: phy0: received PCI FATAL interrupt
> >> > [38951.779081] ath: phy0: received PCI PERR interrupt
> >> > [38951.789851] ath: phy0: Failed to wakeup in 500us
> >> > [38951.789853] ------------[ cut here ]------------
> >> > [38951.789866] WARNING: at drivers/net/wireless/ath/ath9k/hw.c:2231
> >> > ath9k_hw_setpower+0x446/0x499 [ath9k_hw]()
> >> > [38951.789868] Hardware name: Inspiron One 2020
> >> > [38951.789870] Modules linked in: isofs udf crc_itu_t bnep rfcomm
> >> > binfmt_misc loop hid_generic usbhid hid ath3k btusb bluetooth
> >> > snd_hda_codec_realtek coretemp ehci_pci kvm_intel snd_hda_intel kvm
> >> > snd_hda_codec ehci_hcd arc4 snd_hwdep ath9k ath9k_common ath9k_hw ath
> >> > mac80211 usbcore i915 cfg80211 snd_pcm drm_kms_helper drm iTCO_wdt
> >> > iTCO_vendor_support snd_page_alloc i2c_algo_bit i2c_i801 i2c_core
> >> > snd_timer acpi_cpufreq mperf crc32c_intel ghash_clmulni_intel lpc_ich
> >> > mfd_core sparse_keymap rfkill evdev snd video dcdbas usb_common psmouse
> >> > cryptd wmi processor button soundcore pcspkr serio_raw microcode ext4
> >> > crc16 jbd2 mbcache sg sr_mod sd_mod cdrom crc_t10dif ata_generic thermal
> >> > fan thermal_sys ata_piix libata scsi_mod r8169 mii
> >> > [38951.789929] Pid: 0, comm: swapper/0 Not tainted 3.9.0ath9-wl+ #3
> >> > [38951.789931] Call Trace:
> >> > [38951.789933]  <IRQ>  [<ffffffff8103d500>] ? warn_slowpath_common
> >> > +0x76/0x8c
> >> > [38951.789946]  [<ffffffffa044e166>] ? ath9k_hw_setpower+0x446/0x499
> >> > [ath9k_hw]
> >> > [38951.789954]  [<ffffffffa0395b11>] ? ath9k_ps_wakeup+0x4c/0xa9 [ath9k]
> >> > [38951.789960]  [<ffffffffa0397374>] ? ath9k_tasklet+0x24/0x131 [ath9k]
> >> > [38951.789964]  [<ffffffff81044000>] ? tasklet_action+0x73/0xc2
> >> > [38951.789968]  [<ffffffff81043c61>] ? __do_softirq+0xe2/0x1f7
> >> > [38951.789971]  [<ffffffff81043e41>] ? irq_exit+0x3f/0x82
> >> > [38951.789975]  [<ffffffff8102c301>] ? __x2apic_send_IPI_mask+0xb9/0x140
> >> > [38951.789979]  [<ffffffff8100f701>] ? do_IRQ+0x81/0x97
> >> > [38951.789984]  [<ffffffff813856ed>] ? common_interrupt+0x6d/0x6d
> >> > [38951.789985]  <EOI>  [<ffffffff8129f3d8>] ? arch_local_irq_enable
> >> > +0x4/0x8
> >> > [38951.789994]  [<ffffffff8129fa5c>] ? cpuidle_wrap_enter+0x3c/0x71
> >> > [38951.789999]  [<ffffffff8129f78e>] ? cpuidle_enter_state+0xa/0x2f
> >> > [38951.790002]  [<ffffffff8129f85c>] ? cpuidle_idle_call+0xa9/0xfb
> >> > [38951.790007]  [<ffffffff81014c6f>] ? cpu_idle+0x9c/0xe6
> >> > [38951.790011]  [<ffffffff816aed23>] ? start_kernel+0x3b8/0x3c3
> >> > [38951.790014]  [<ffffffff816ae781>] ? repair_env_string+0x57/0x57
> >> > [38951.790018]  [<ffffffff816ae59c>] ? x86_64_start_kernel+0xf2/0xfd
> >> > [38951.790021] ---[ end trace bff1151979a9309c ]---
> >> > [38951.800533] ath: phy0: Failed to wakeup in 500us
> >> > [38951.865086] ath: phy0: Failed to stop TX DMA, queues=0x10f!
> >> > [38951.876459] ath: phy0: DMA failed to stop in 10 ms AR_CR=0xffffffff
> >> > AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
> >> > [38951.876494] ath: phy0: Could not stop RX, we could be confusing the
> >> > DMA engine when we start RX up
> >> >
> >> > At this point the wireless connection is gone and can't be restored
> >> > without a full reboot.
> >> >
> >> > In the past while looking at this with the upstream RC kernels I tried
> >> > setting ath9k.debug=0xffffffff, but it didn't seem to add anything
> >> > useful ( https://bugzilla.kernel.org/show_bug.cgi?id=56301 ).
> >> >
> >> > Since the full kern.log is over 50 megs (lots of repeated error
> >> > messages) I'm only attaching the first 1000 lines which should be more
> >> > than enough.
> >> >
> >> > Not sure where to go from here since I'm using the most current ath9k
> >> > that I could find. Is there anything else I could do to help get to the
> >> > bottom of this issue?
> >> >
> >> > Joel
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > ath9k-devel mailing list
> >> > ath9k-devel at lists.ath9k.org
> >> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >> >
> >
> >

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ath9k-devel] ath9k (AR9485) failing with PCI errors after hours of uptime with current ath9k.ko from linux-wireless
  2013-05-09  5:10     ` Adrian Chadd
  2013-05-09 11:32       ` Joel Diaz
@ 2013-05-13 11:28       ` Joel Diaz
  2013-05-13 13:29         ` Adrian Chadd
  1 sibling, 1 reply; 8+ messages in thread
From: Joel Diaz @ 2013-05-13 11:28 UTC (permalink / raw)
  To: ath9k-devel

On Wed, 2013-05-08 at 22:10 -0700, Adrian Chadd wrote:
> No, I mean - there's an iw command to disable entering power save on
> your linux station. Find that and disable it.
> 
It has now been running for about 4 and half days without seeing the
wireless connection drop after the 'iw dev wlan0 set power_save off'. I
hope it's not premature to say thanks, as this is the longest I've seen
it go without a failure.

I'm not at all familiar with the history behind why power saving needs
to be disabled (as this machine is a desktop, it's not terribly
important to me), but if there's any hope of having it fixed through
patches, I'd be more than willing to help out so other people don't have
to go through what I went through.

Once again, thanks.

Joel
> 
> 
> Adrian
> 
> On 8 May 2013 17:21, Joel Diaz <joeldiaz@earthlink.net> wrote:
> > On Wed, 2013-05-08 at 15:35 -0700, Adrian Chadd wrote:
> >> Step 0 - disable station mode power save; see if that has any impact.
> >>
> >>
> > The base station is an Apple Airport Extreme (version 7.6.3 in case that
> > matters). I don't see anything in the settings for power saving. And a
> > google search didn't help much.
> >
> > Joel
> >>
> >> adrian
> >>
> >>
> >> On 8 May 2013 14:41, Joel Diaz <joeldiaz@earthlink.net> wrote:
> >> > First some background: starting with Debian Wheezy I noticed my wireless
> >> > connection would fail after hours (sometime as quick as 15 minutes) of
> >> > uptime. Moving from Debian's 3.2 kernel to upstream's 3.9-RCs also
> >> > showed the problem.
> >> >
> >> > Yesterday I pulled the linux-wireless git repo and built myself a kernel
> >> > (starting with Debian Wheezy's kernel config) with HEAD pointing to:
> >> >
> >> > commit e514a9747148e3786879cc5430775a854441ba38
> >> > Author: Stanislaw Gruszka <sgruszka@redhat.com>
> >> > Date:   Thu May 2 09:43:57 2013 +0200
> >> >
> >> >     ath5k: do not reschedule tx_complete_work on stop
> >> >
> >> > After about 10 hours of uptime with the system basically idle (since I
> >> > was at work) I see the failure:
> >> >
> >> > [38951.779076] ath: phy0: received PCI FATAL interrupt
> >> > [38951.779081] ath: phy0: received PCI PERR interrupt
> >> > [38951.789851] ath: phy0: Failed to wakeup in 500us
> >> > [38951.789853] ------------[ cut here ]------------
> >> > [38951.789866] WARNING: at drivers/net/wireless/ath/ath9k/hw.c:2231
> >> > ath9k_hw_setpower+0x446/0x499 [ath9k_hw]()
> >> > [38951.789868] Hardware name: Inspiron One 2020
> >> > [38951.789870] Modules linked in: isofs udf crc_itu_t bnep rfcomm
> >> > binfmt_misc loop hid_generic usbhid hid ath3k btusb bluetooth
> >> > snd_hda_codec_realtek coretemp ehci_pci kvm_intel snd_hda_intel kvm
> >> > snd_hda_codec ehci_hcd arc4 snd_hwdep ath9k ath9k_common ath9k_hw ath
> >> > mac80211 usbcore i915 cfg80211 snd_pcm drm_kms_helper drm iTCO_wdt
> >> > iTCO_vendor_support snd_page_alloc i2c_algo_bit i2c_i801 i2c_core
> >> > snd_timer acpi_cpufreq mperf crc32c_intel ghash_clmulni_intel lpc_ich
> >> > mfd_core sparse_keymap rfkill evdev snd video dcdbas usb_common psmouse
> >> > cryptd wmi processor button soundcore pcspkr serio_raw microcode ext4
> >> > crc16 jbd2 mbcache sg sr_mod sd_mod cdrom crc_t10dif ata_generic thermal
> >> > fan thermal_sys ata_piix libata scsi_mod r8169 mii
> >> > [38951.789929] Pid: 0, comm: swapper/0 Not tainted 3.9.0ath9-wl+ #3
> >> > [38951.789931] Call Trace:
> >> > [38951.789933]  <IRQ>  [<ffffffff8103d500>] ? warn_slowpath_common
> >> > +0x76/0x8c
> >> > [38951.789946]  [<ffffffffa044e166>] ? ath9k_hw_setpower+0x446/0x499
> >> > [ath9k_hw]
> >> > [38951.789954]  [<ffffffffa0395b11>] ? ath9k_ps_wakeup+0x4c/0xa9 [ath9k]
> >> > [38951.789960]  [<ffffffffa0397374>] ? ath9k_tasklet+0x24/0x131 [ath9k]
> >> > [38951.789964]  [<ffffffff81044000>] ? tasklet_action+0x73/0xc2
> >> > [38951.789968]  [<ffffffff81043c61>] ? __do_softirq+0xe2/0x1f7
> >> > [38951.789971]  [<ffffffff81043e41>] ? irq_exit+0x3f/0x82
> >> > [38951.789975]  [<ffffffff8102c301>] ? __x2apic_send_IPI_mask+0xb9/0x140
> >> > [38951.789979]  [<ffffffff8100f701>] ? do_IRQ+0x81/0x97
> >> > [38951.789984]  [<ffffffff813856ed>] ? common_interrupt+0x6d/0x6d
> >> > [38951.789985]  <EOI>  [<ffffffff8129f3d8>] ? arch_local_irq_enable
> >> > +0x4/0x8
> >> > [38951.789994]  [<ffffffff8129fa5c>] ? cpuidle_wrap_enter+0x3c/0x71
> >> > [38951.789999]  [<ffffffff8129f78e>] ? cpuidle_enter_state+0xa/0x2f
> >> > [38951.790002]  [<ffffffff8129f85c>] ? cpuidle_idle_call+0xa9/0xfb
> >> > [38951.790007]  [<ffffffff81014c6f>] ? cpu_idle+0x9c/0xe6
> >> > [38951.790011]  [<ffffffff816aed23>] ? start_kernel+0x3b8/0x3c3
> >> > [38951.790014]  [<ffffffff816ae781>] ? repair_env_string+0x57/0x57
> >> > [38951.790018]  [<ffffffff816ae59c>] ? x86_64_start_kernel+0xf2/0xfd
> >> > [38951.790021] ---[ end trace bff1151979a9309c ]---
> >> > [38951.800533] ath: phy0: Failed to wakeup in 500us
> >> > [38951.865086] ath: phy0: Failed to stop TX DMA, queues=0x10f!
> >> > [38951.876459] ath: phy0: DMA failed to stop in 10 ms AR_CR=0xffffffff
> >> > AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
> >> > [38951.876494] ath: phy0: Could not stop RX, we could be confusing the
> >> > DMA engine when we start RX up
> >> >
> >> > At this point the wireless connection is gone and can't be restored
> >> > without a full reboot.
> >> >
> >> > In the past while looking at this with the upstream RC kernels I tried
> >> > setting ath9k.debug=0xffffffff, but it didn't seem to add anything
> >> > useful ( https://bugzilla.kernel.org/show_bug.cgi?id=56301 ).
> >> >
> >> > Since the full kern.log is over 50 megs (lots of repeated error
> >> > messages) I'm only attaching the first 1000 lines which should be more
> >> > than enough.
> >> >
> >> > Not sure where to go from here since I'm using the most current ath9k
> >> > that I could find. Is there anything else I could do to help get to the
> >> > bottom of this issue?
> >> >
> >> > Joel
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > ath9k-devel mailing list
> >> > ath9k-devel at lists.ath9k.org
> >> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >> >
> >
> >

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ath9k-devel] ath9k (AR9485) failing with PCI errors after hours of uptime with current ath9k.ko from linux-wireless
  2013-05-13 11:28       ` Joel Diaz
@ 2013-05-13 13:29         ` Adrian Chadd
  2013-05-13 21:15           ` Joel Diaz
  0 siblings, 1 reply; 8+ messages in thread
From: Adrian Chadd @ 2013-05-13 13:29 UTC (permalink / raw)
  To: ath9k-devel

On 13 May 2013 04:28, Joel Diaz <joeldiaz@earthlink.net> wrote:
> On Wed, 2013-05-08 at 22:10 -0700, Adrian Chadd wrote:
>> No, I mean - there's an iw command to disable entering power save on
>> your linux station. Find that and disable it.
>>
> It has now been running for about 4 and half days without seeing the
> wireless connection drop after the 'iw dev wlan0 set power_save off'. I
> hope it's not premature to say thanks, as this is the longest I've seen
> it go without a failure.
>
> I'm not at all familiar with the history behind why power saving needs
> to be disabled (as this machine is a desktop, it's not terribly
> important to me), but if there's any hope of having it fixed through
> patches, I'd be more than willing to help out so other people don't have
> to go through what I went through.

Hi!

please file a kernel.org bugzilla bug.

There's two overarching possibilities:

* there's a driver bug (eg setting up DMA when the chip is asleep);
trying to put the NIC to sleep during a DMA, etc;
* that some PCIe quirk needs to be added to the ath9k driver to work
around some oddities with PCie sleep state(s).

Thanks,



Adrian

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ath9k-devel] ath9k (AR9485) failing with PCI errors after hours of uptime with current ath9k.ko from linux-wireless
  2013-05-13 13:29         ` Adrian Chadd
@ 2013-05-13 21:15           ` Joel Diaz
  0 siblings, 0 replies; 8+ messages in thread
From: Joel Diaz @ 2013-05-13 21:15 UTC (permalink / raw)
  To: ath9k-devel

On Mon, 2013-05-13 at 06:29 -0700, Adrian Chadd wrote:
> On 13 May 2013 04:28, Joel Diaz <joeldiaz@earthlink.net> wrote:
> > On Wed, 2013-05-08 at 22:10 -0700, Adrian Chadd wrote:
> >> No, I mean - there's an iw command to disable entering power save on
> >> your linux station. Find that and disable it.
> >>
> > It has now been running for about 4 and half days without seeing the
> > wireless connection drop after the 'iw dev wlan0 set power_save off'. I
> > hope it's not premature to say thanks, as this is the longest I've seen
> > it go without a failure.
> >
> > I'm not at all familiar with the history behind why power saving needs
> > to be disabled (as this machine is a desktop, it's not terribly
> > important to me), but if there's any hope of having it fixed through
> > patches, I'd be more than willing to help out so other people don't have
> > to go through what I went through.
> 
> Hi!
> 
> please file a kernel.org bugzilla bug.
> 
I've updated the title and added the workaround to my previously opened
bugzilla ( https://bugzilla.kernel.org/show_bug.cgi?id=56301 ).

Joel

> There's two overarching possibilities:
> 
> * there's a driver bug (eg setting up DMA when the chip is asleep);
> trying to put the NIC to sleep during a DMA, etc;
> * that some PCIe quirk needs to be added to the ath9k driver to work
> around some oddities with PCie sleep state(s).
> 
> Thanks,
> 
> 
> 
> Adrian

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2013-05-13 21:15 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-08 21:41 [ath9k-devel] ath9k (AR9485) failing with PCI errors after hours of uptime with current ath9k.ko from linux-wireless Joel Diaz
2013-05-08 22:35 ` Adrian Chadd
2013-05-09  0:21   ` Joel Diaz
2013-05-09  5:10     ` Adrian Chadd
2013-05-09 11:32       ` Joel Diaz
2013-05-13 11:28       ` Joel Diaz
2013-05-13 13:29         ` Adrian Chadd
2013-05-13 21:15           ` Joel Diaz

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.