* [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
@ 2014-01-23 18:30 mail at fuerstflorian.de
2014-01-23 19:44 ` Oleksij Rempel
0 siblings, 1 reply; 10+ messages in thread
From: mail at fuerstflorian.de @ 2014-01-23 18:30 UTC (permalink / raw)
To: ath9k-devel
Hello all,
my Raspberry Pi crashes about once a day with the following kernel message:
[80526.425663] wlan0: AP xx:xx:xx:xx:xx:xx changed bandwidth, new config is 2462 MHz, width 1 (2462/0 MHz)
[80527.347296] wlan0: AP xx:xx:xx:xx:xx:xx changed bandwidth, new config is 2462 MHz, width 2 (2452/0 MHz)
[80527.347683] BUG: scheduling while atomic: ksoftirqd/0/3/0x00000302
[80527.421904] Modules linked in: arc4 ath9k_htc ath9k_common ath9k_hw ath mac80211 cfg80211 leds_gpio led_class spi_bcm2708 i2c_bcm2708 snd_bcm2835 snd_pcm snd_page_alloc snd_timer snd i2c_dev bcm2708_rng rng_core ipv6
[80527.422023] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G W 3.10.26-1-ARCH #1
[80527.422096] [<c0012da8>] (unwind_backtrace+0x0/0xf0) from [<c0010ca8>] (show_stack+0x10/0x14)
[80527.422147] [<c0010ca8>] (show_stack+0x10/0x14) from [<c059ae08>] (__schedule_bug+0x44/0x5c)
[80527.422182] [<c059ae08>] (__schedule_bug+0x44/0x5c) from [<c05a15f0>] (__schedule+0x54c/0x5c4)
[80527.422213] [<c05a15f0>] (__schedule+0x54c/0x5c4) from [<c05a1d58>] (schedule_preempt_disabled+0x14/0x20)
[80527.422242] [<c05a1d58>] (schedule_preempt_disabled+0x14/0x20) from [<c05a0994>] (__mutex_lock_slowpath+0x9c/0x12c)
[80527.422337] [<c05a0994>] (__mutex_lock_slowpath+0x9c/0x12c) from [<bf2898cc>] (ath9k_htc_sta_rc_update+0x30/0x98 [ath9k_htc])
[80527.422841] [<bf2898cc>] (ath9k_htc_sta_rc_update+0x30/0x98 [ath9k_htc]) from [<bf1863b0>] (ieee80211_rx_handlers+0x1994/0x24a4 [mac80211])
[80527.423397] [<bf1863b0>] (ieee80211_rx_handlers+0x1994/0x24a4 [mac80211]) from [<bf1872e0>] (ieee80211_prepare_and_rx_handle+0x234/0xb14 [mac80211])
[80527.423946] [<bf1872e0>] (ieee80211_prepare_and_rx_handle+0x234/0xb14 [mac80211]) from [<bf187eb8>] (ieee80211_rx+0x2f8/0x7ec [mac80211])
[80527.424283] [<bf187eb8>] (ieee80211_rx+0x2f8/0x7ec [mac80211]) from [<bf28848c>] (ath9k_rx_tasklet+0x3b0/0x68c [ath9k_htc])
[80527.424347] [<bf28848c>] (ath9k_rx_tasklet+0x3b0/0x68c [ath9k_htc]) from [<c002a94c>] (tasklet_action+0x5c/0xa8)
[80527.424377] [<c002a94c>] (tasklet_action+0x5c/0xa8) from [<c002a0b8>] (__do_softirq+0xcc/0x278)
[80527.424402] [<c002a0b8>] (__do_softirq+0xcc/0x278) from [<c002a290>] (run_ksoftirqd+0x2c/0x48)
[80527.424437] [<c002a290>] (run_ksoftirqd+0x2c/0x48) from [<c004b74c>] (smpboot_thread_fn+0x15c/0x208)
[80527.424475] [<c004b74c>] (smpboot_thread_fn+0x15c/0x208) from [<c0043d70>] (kthread+0xa4/0xb0)
[80527.424510] [<c0043d70>] (kthread+0xa4/0xb0) from [<c000dc18>] (ret_from_fork+0x14/0x3c)
Some more information:
W-LAN Chipset: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n [Atheros AR7010+AR9287]
Kernel: Linux pi1 3.10.27-2-ARCH #1 PREEMPT Tue Jan 21 00:42:16 MST 2014 armv6l GNU/Linux
Any suggestion?
Many thanks in advance.
Flo
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
2014-01-23 18:30 [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302 mail at fuerstflorian.de
@ 2014-01-23 19:44 ` Oleksij Rempel
2014-01-23 22:03 ` Antonio Quartulli
0 siblings, 1 reply; 10+ messages in thread
From: Oleksij Rempel @ 2014-01-23 19:44 UTC (permalink / raw)
To: ath9k-devel
Hi Antonio,
You probably know more about this issue then me.
Insight of this mutex are some WMI commands, which are incredible slow
on some USB 2.0 devices.
Am 23.01.2014 19:30, schrieb mail at fuerstflorian.de:
> Hello all,
>
> my Raspberry Pi crashes about once a day with the following kernel message:
>
> [80526.425663] wlan0: AP xx:xx:xx:xx:xx:xx changed bandwidth, new config is 2462 MHz, width 1 (2462/0 MHz)
> [80527.347296] wlan0: AP xx:xx:xx:xx:xx:xx changed bandwidth, new config is 2462 MHz, width 2 (2452/0 MHz)
> [80527.347683] BUG: scheduling while atomic: ksoftirqd/0/3/0x00000302
> [80527.421904] Modules linked in: arc4 ath9k_htc ath9k_common ath9k_hw ath mac80211 cfg80211 leds_gpio led_class spi_bcm2708 i2c_bcm2708 snd_bcm2835 snd_pcm snd_page_alloc snd_timer snd i2c_dev bcm2708_rng rng_core ipv6
> [80527.422023] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G W 3.10.26-1-ARCH #1
> [80527.422096] [<c0012da8>] (unwind_backtrace+0x0/0xf0) from [<c0010ca8>] (show_stack+0x10/0x14)
> [80527.422147] [<c0010ca8>] (show_stack+0x10/0x14) from [<c059ae08>] (__schedule_bug+0x44/0x5c)
> [80527.422182] [<c059ae08>] (__schedule_bug+0x44/0x5c) from [<c05a15f0>] (__schedule+0x54c/0x5c4)
> [80527.422213] [<c05a15f0>] (__schedule+0x54c/0x5c4) from [<c05a1d58>] (schedule_preempt_disabled+0x14/0x20)
> [80527.422242] [<c05a1d58>] (schedule_preempt_disabled+0x14/0x20) from [<c05a0994>] (__mutex_lock_slowpath+0x9c/0x12c)
> [80527.422337] [<c05a0994>] (__mutex_lock_slowpath+0x9c/0x12c) from [<bf2898cc>] (ath9k_htc_sta_rc_update+0x30/0x98 [ath9k_htc])
> [80527.422841] [<bf2898cc>] (ath9k_htc_sta_rc_update+0x30/0x98 [ath9k_htc]) from [<bf1863b0>] (ieee80211_rx_handlers+0x1994/0x24a4 [mac80211])
> [80527.423397] [<bf1863b0>] (ieee80211_rx_handlers+0x1994/0x24a4 [mac80211]) from [<bf1872e0>] (ieee80211_prepare_and_rx_handle+0x234/0xb14 [mac80211])
> [80527.423946] [<bf1872e0>] (ieee80211_prepare_and_rx_handle+0x234/0xb14 [mac80211]) from [<bf187eb8>] (ieee80211_rx+0x2f8/0x7ec [mac80211])
> [80527.424283] [<bf187eb8>] (ieee80211_rx+0x2f8/0x7ec [mac80211]) from [<bf28848c>] (ath9k_rx_tasklet+0x3b0/0x68c [ath9k_htc])
> [80527.424347] [<bf28848c>] (ath9k_rx_tasklet+0x3b0/0x68c [ath9k_htc]) from [<c002a94c>] (tasklet_action+0x5c/0xa8)
> [80527.424377] [<c002a94c>] (tasklet_action+0x5c/0xa8) from [<c002a0b8>] (__do_softirq+0xcc/0x278)
> [80527.424402] [<c002a0b8>] (__do_softirq+0xcc/0x278) from [<c002a290>] (run_ksoftirqd+0x2c/0x48)
> [80527.424437] [<c002a290>] (run_ksoftirqd+0x2c/0x48) from [<c004b74c>] (smpboot_thread_fn+0x15c/0x208)
> [80527.424475] [<c004b74c>] (smpboot_thread_fn+0x15c/0x208) from [<c0043d70>] (kthread+0xa4/0xb0)
> [80527.424510] [<c0043d70>] (kthread+0xa4/0xb0) from [<c000dc18>] (ret_from_fork+0x14/0x3c)
>
> Some more information:
> W-LAN Chipset: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n [Atheros AR7010+AR9287]
> Kernel: Linux pi1 3.10.27-2-ARCH #1 PREEMPT Tue Jan 21 00:42:16 MST 2014 armv6l GNU/Linux
>
> Any suggestion?
>
> Many thanks in advance.
> Flo
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
--
Regards,
Oleksij
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
2014-01-23 19:44 ` Oleksij Rempel
@ 2014-01-23 22:03 ` Antonio Quartulli
[not found] ` <trinity-14f555a0-3945-448b-a908-b12f1cb532e3-1390546291559@3capp-1and1-bs03>
0 siblings, 1 reply; 10+ messages in thread
From: Antonio Quartulli @ 2014-01-23 22:03 UTC (permalink / raw)
To: ath9k-devel
Hi all,
On 23/01/14 20:44, Oleksij Rempel wrote:
> Hi Antonio,
>
> You probably know more about this issue then me.
>
> Insight of this mutex are some WMI commands, which are incredible slow
> on some USB 2.0 devices.
>
I implemented the ath9k_htc_sta_rc_update() API but I don't really know
the internals of the ath9k_htc driver...therefore I don't know if these
WMI commands have any consequence on this..Could it be that this
slowness is triggering some reaction in the kernel (due to the fact that
this part of the code is executed while holding a lock)?
Sorry, but I can't really help.
Just as a generic suggestion, have you tried testing a slightly older
kernel versions to see if that makes any difference?
> Am 23.01.2014 19:30, schrieb mail at fuerstflorian.de:
>> Hello all,
>>
>> my Raspberry Pi crashes about once a day with the following kernel message:
>>
>> [80526.425663] wlan0: AP xx:xx:xx:xx:xx:xx changed bandwidth, new config is 2462 MHz, width 1 (2462/0 MHz)
>> [80527.347296] wlan0: AP xx:xx:xx:xx:xx:xx changed bandwidth, new config is 2462 MHz, width 2 (2452/0 MHz)
>> [80527.347683] BUG: scheduling while atomic: ksoftirqd/0/3/0x00000302
>> [80527.421904] Modules linked in: arc4 ath9k_htc ath9k_common ath9k_hw ath mac80211 cfg80211 leds_gpio led_class spi_bcm2708 i2c_bcm2708 snd_bcm2835 snd_pcm snd_page_alloc snd_timer snd i2c_dev bcm2708_rng rng_core ipv6
>> [80527.422023] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G W 3.10.26-1-ARCH #1
>> [80527.422096] [<c0012da8>] (unwind_backtrace+0x0/0xf0) from [<c0010ca8>] (show_stack+0x10/0x14)
>> [80527.422147] [<c0010ca8>] (show_stack+0x10/0x14) from [<c059ae08>] (__schedule_bug+0x44/0x5c)
>> [80527.422182] [<c059ae08>] (__schedule_bug+0x44/0x5c) from [<c05a15f0>] (__schedule+0x54c/0x5c4)
>> [80527.422213] [<c05a15f0>] (__schedule+0x54c/0x5c4) from [<c05a1d58>] (schedule_preempt_disabled+0x14/0x20)
>> [80527.422242] [<c05a1d58>] (schedule_preempt_disabled+0x14/0x20) from [<c05a0994>] (__mutex_lock_slowpath+0x9c/0x12c)
>> [80527.422337] [<c05a0994>] (__mutex_lock_slowpath+0x9c/0x12c) from [<bf2898cc>] (ath9k_htc_sta_rc_update+0x30/0x98 [ath9k_htc])
>> [80527.422841] [<bf2898cc>] (ath9k_htc_sta_rc_update+0x30/0x98 [ath9k_htc]) from [<bf1863b0>] (ieee80211_rx_handlers+0x1994/0x24a4 [mac80211])
>> [80527.423397] [<bf1863b0>] (ieee80211_rx_handlers+0x1994/0x24a4 [mac80211]) from [<bf1872e0>] (ieee80211_prepare_and_rx_handle+0x234/0xb14 [mac80211])
>> [80527.423946] [<bf1872e0>] (ieee80211_prepare_and_rx_handle+0x234/0xb14 [mac80211]) from [<bf187eb8>] (ieee80211_rx+0x2f8/0x7ec [mac80211])
>> [80527.424283] [<bf187eb8>] (ieee80211_rx+0x2f8/0x7ec [mac80211]) from [<bf28848c>] (ath9k_rx_tasklet+0x3b0/0x68c [ath9k_htc])
>> [80527.424347] [<bf28848c>] (ath9k_rx_tasklet+0x3b0/0x68c [ath9k_htc]) from [<c002a94c>] (tasklet_action+0x5c/0xa8)
>> [80527.424377] [<c002a94c>] (tasklet_action+0x5c/0xa8) from [<c002a0b8>] (__do_softirq+0xcc/0x278)
>> [80527.424402] [<c002a0b8>] (__do_softirq+0xcc/0x278) from [<c002a290>] (run_ksoftirqd+0x2c/0x48)
>> [80527.424437] [<c002a290>] (run_ksoftirqd+0x2c/0x48) from [<c004b74c>] (smpboot_thread_fn+0x15c/0x208)
>> [80527.424475] [<c004b74c>] (smpboot_thread_fn+0x15c/0x208) from [<c0043d70>] (kthread+0xa4/0xb0)
>> [80527.424510] [<c0043d70>] (kthread+0xa4/0xb0) from [<c000dc18>] (ret_from_fork+0x14/0x3c)
>>
>> Some more information:
>> W-LAN Chipset: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n [Atheros AR7010+AR9287]
>> Kernel: Linux pi1 3.10.27-2-ARCH #1 PREEMPT Tue Jan 21 00:42:16 MST 2014 armv6l GNU/Linux
>>
>> Any suggestion?
>>
>> Many thanks in advance.
>> Flo
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
>
--
Antonio Quartulli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140123/021d07a2/attachment.pgp
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
[not found] ` <trinity-14f555a0-3945-448b-a908-b12f1cb532e3-1390546291559@3capp-1and1-bs03>
@ 2014-01-24 6:55 ` mail at fuerstflorian.de
2014-01-27 19:02 ` Oleksij Rempel
0 siblings, 1 reply; 10+ messages in thread
From: mail at fuerstflorian.de @ 2014-01-24 6:55 UTC (permalink / raw)
To: ath9k-devel
Hello Antonio,
> Just as a generic suggestion, have you tried testing a slightly older
> kernel versions to see if that makes any difference?
Thanks for the suggestion. I will try to use a older kernel version, but it will take some days to be
sure if it works again (and I naturally will report about).
--
Flo
> On 23/01/14 23:03, Antonio Quartulli wrote:
> Von: "Antonio Quartulli" <antonio@meshcoding.com>
> An: "Oleksij Rempel" <linux@rempel-privat.de>, mail at fuerstflorian.de, ath9k-devel at lists.ath9k.org, "Antonio Quartulli" <ordex@autistici.org>
> Betreff: Re: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
>
> Hi all,
>
> On 23/01/14 20:44, Oleksij Rempel wrote:
> > Hi Antonio,
> >
> > You probably know more about this issue then me.
> >
> > Insight of this mutex are some WMI commands, which are incredible slow
> > on some USB 2.0 devices.
> >
>
> I implemented the ath9k_htc_sta_rc_update() API but I don't really know
> the internals of the ath9k_htc driver...therefore I don't know if these
> WMI commands have any consequence on this..Could it be that this
> slowness is triggering some reaction in the kernel (due to the fact that
> this part of the code is executed while holding a lock)?
>
> Sorry, but I can't really help.
>
> Just as a generic suggestion, have you tried testing a slightly older
> kernel versions to see if that makes any difference?
>
>
>
> --
> Antonio Quartulli
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
2014-01-24 6:55 ` mail at fuerstflorian.de
@ 2014-01-27 19:02 ` Oleksij Rempel
0 siblings, 0 replies; 10+ messages in thread
From: Oleksij Rempel @ 2014-01-27 19:02 UTC (permalink / raw)
To: ath9k-devel
Hi Johannes,
i found this bug report with your response:
https://bugzilla.redhat.com/show_bug.cgi?id=990955
"I don't think adding a workqueue is a good idea because that would
significantly delay the calls in many situations."
The problem on ath9k_htc is that the call is already dramatically
delayed. It will try to send WMI command over USB with delay of some
_msec_ not usec. There are two options right now, use workqueue or do
not support sta_rc_update.
Am 24.01.2014 07:55, schrieb mail at fuerstflorian.de:
> Hello Antonio,
>
>> Just as a generic suggestion, have you tried testing a slightly older
>> kernel versions to see if that makes any difference?
>
> Thanks for the suggestion. I will try to use a older kernel version, but it will take some days to be
> sure if it works again (and I naturally will report about).
>
> --
> Flo
>
>> On 23/01/14 23:03, Antonio Quartulli wrote:
>> Von: "Antonio Quartulli" <antonio@meshcoding.com>
>> An: "Oleksij Rempel" <linux@rempel-privat.de>, mail at fuerstflorian.de, ath9k-devel at lists.ath9k.org, "Antonio Quartulli" <ordex@autistici.org>
>> Betreff: Re: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
>>
>> Hi all,
>>
>> On 23/01/14 20:44, Oleksij Rempel wrote:
>>> Hi Antonio,
>>>
>>> You probably know more about this issue then me.
>>>
>>> Insight of this mutex are some WMI commands, which are incredible slow
>>> on some USB 2.0 devices.
>>>
>>
>> I implemented the ath9k_htc_sta_rc_update() API but I don't really know
>> the internals of the ath9k_htc driver...therefore I don't know if these
>> WMI commands have any consequence on this..Could it be that this
>> slowness is triggering some reaction in the kernel (due to the fact that
>> this part of the code is executed while holding a lock)?
>>
>> Sorry, but I can't really help.
>>
>> Just as a generic suggestion, have you tried testing a slightly older
>> kernel versions to see if that makes any difference?
>>
>>
>>
>> --
>> Antonio Quartulli
--
Regards,
Oleksij
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140127/714d3716/attachment.pgp
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
@ 2014-01-27 19:02 ` Oleksij Rempel
0 siblings, 0 replies; 10+ messages in thread
From: Oleksij Rempel @ 2014-01-27 19:02 UTC (permalink / raw)
To: mail, ath9k-devel, linux-wireless@vger.kernel.org, Johannes Berg
[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]
Hi Johannes,
i found this bug report with your response:
https://bugzilla.redhat.com/show_bug.cgi?id=990955
"I don't think adding a workqueue is a good idea because that would
significantly delay the calls in many situations."
The problem on ath9k_htc is that the call is already dramatically
delayed. It will try to send WMI command over USB with delay of some
_msec_ not usec. There are two options right now, use workqueue or do
not support sta_rc_update.
Am 24.01.2014 07:55, schrieb mail@fuerstflorian.de:
> Hello Antonio,
>
>> Just as a generic suggestion, have you tried testing a slightly older
>> kernel versions to see if that makes any difference?
>
> Thanks for the suggestion. I will try to use a older kernel version, but it will take some days to be
> sure if it works again (and I naturally will report about).
>
> --
> Flo
>
>> On 23/01/14 23:03, Antonio Quartulli wrote:
>> Von: "Antonio Quartulli" <antonio@meshcoding.com>
>> An: "Oleksij Rempel" <linux@rempel-privat.de>, mail@fuerstflorian.de, ath9k-devel@lists.ath9k.org, "Antonio Quartulli" <ordex@autistici.org>
>> Betreff: Re: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
>>
>> Hi all,
>>
>> On 23/01/14 20:44, Oleksij Rempel wrote:
>>> Hi Antonio,
>>>
>>> You probably know more about this issue then me.
>>>
>>> Insight of this mutex are some WMI commands, which are incredible slow
>>> on some USB 2.0 devices.
>>>
>>
>> I implemented the ath9k_htc_sta_rc_update() API but I don't really know
>> the internals of the ath9k_htc driver...therefore I don't know if these
>> WMI commands have any consequence on this..Could it be that this
>> slowness is triggering some reaction in the kernel (due to the fact that
>> this part of the code is executed while holding a lock)?
>>
>> Sorry, but I can't really help.
>>
>> Just as a generic suggestion, have you tried testing a slightly older
>> kernel versions to see if that makes any difference?
>>
>>
>>
>> --
>> Antonio Quartulli
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
2014-01-27 19:02 ` Oleksij Rempel
@ 2014-01-27 19:12 ` Antonio Quartulli
-1 siblings, 0 replies; 10+ messages in thread
From: Antonio Quartulli @ 2014-01-27 19:12 UTC (permalink / raw)
To: ath9k-devel
On 27/01/14 20:02, Oleksij Rempel wrote:
> Hi Johannes,
>
> i found this bug report with your response:
> https://bugzilla.redhat.com/show_bug.cgi?id=990955
> "I don't think adding a workqueue is a good idea because that would
> significantly delay the calls in many situations."
>
> The problem on ath9k_htc is that the call is already dramatically
> delayed. It will try to send WMI command over USB with delay of some
> _msec_ not usec. There are two options right now, use workqueue or do
> not support sta_rc_update.
>
Unfortunately not supporting sta_rc_update() means making adhoc mode
unusable.. :(
Cheers,
--
Antonio Quartulli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140127/548d35a1/attachment.pgp
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
@ 2014-01-27 19:12 ` Antonio Quartulli
0 siblings, 0 replies; 10+ messages in thread
From: Antonio Quartulli @ 2014-01-27 19:12 UTC (permalink / raw)
To: Oleksij Rempel, mail, ath9k-devel, linux-wireless@vger.kernel.org,
Johannes Berg
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On 27/01/14 20:02, Oleksij Rempel wrote:
> Hi Johannes,
>
> i found this bug report with your response:
> https://bugzilla.redhat.com/show_bug.cgi?id=990955
> "I don't think adding a workqueue is a good idea because that would
> significantly delay the calls in many situations."
>
> The problem on ath9k_htc is that the call is already dramatically
> delayed. It will try to send WMI command over USB with delay of some
> _msec_ not usec. There are two options right now, use workqueue or do
> not support sta_rc_update.
>
Unfortunately not supporting sta_rc_update() means making adhoc mode
unusable.. :(
Cheers,
--
Antonio Quartulli
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
2014-01-27 19:02 ` Oleksij Rempel
@ 2014-01-27 22:22 ` Johannes Berg
-1 siblings, 0 replies; 10+ messages in thread
From: Johannes Berg @ 2014-01-27 22:22 UTC (permalink / raw)
To: ath9k-devel
On Mon, 2014-01-27 at 20:02 +0100, Oleksij Rempel wrote:
> Hi Johannes,
>
> i found this bug report with your response:
> https://bugzilla.redhat.com/show_bug.cgi?id=990955
> "I don't think adding a workqueue is a good idea because that would
> significantly delay the calls in many situations."
>
> The problem on ath9k_htc
I don't care about ath9k_htc much, maybe it should just have a work item
for that. I don't like it in mac80211 though, since chips that want to
react quickly should be able to.
johannes
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302
@ 2014-01-27 22:22 ` Johannes Berg
0 siblings, 0 replies; 10+ messages in thread
From: Johannes Berg @ 2014-01-27 22:22 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: mail, ath9k-devel, linux-wireless@vger.kernel.org
On Mon, 2014-01-27 at 20:02 +0100, Oleksij Rempel wrote:
> Hi Johannes,
>
> i found this bug report with your response:
> https://bugzilla.redhat.com/show_bug.cgi?id=990955
> "I don't think adding a workqueue is a good idea because that would
> significantly delay the calls in many situations."
>
> The problem on ath9k_htc
I don't care about ath9k_htc much, maybe it should just have a work item
for that. I don't like it in mac80211 though, since chips that want to
react quickly should be able to.
johannes
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-01-27 22:22 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-23 18:30 [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302 mail at fuerstflorian.de
2014-01-23 19:44 ` Oleksij Rempel
2014-01-23 22:03 ` Antonio Quartulli
[not found] ` <trinity-14f555a0-3945-448b-a908-b12f1cb532e3-1390546291559@3capp-1and1-bs03>
2014-01-24 6:55 ` mail at fuerstflorian.de
2014-01-27 19:02 ` Oleksij Rempel
2014-01-27 19:02 ` Oleksij Rempel
2014-01-27 19:12 ` Antonio Quartulli
2014-01-27 19:12 ` Antonio Quartulli
2014-01-27 22:22 ` Johannes Berg
2014-01-27 22:22 ` Johannes Berg
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.