* [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
[parent not found: <trinity-14f555a0-3945-448b-a908-b12f1cb532e3-1390546291559@3capp-1and1-bs03>]
* [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.