Re: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302

Re: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302

[Oleksij Rempel]

[-- 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 --]

Re: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302

[Antonio Quartulli]

[-- 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 --]

Re: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302

[Johannes Berg]

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