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 [email protected]:
> 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" <[email protected]>
>> An: "Oleksij Rempel" <[email protected]>, [email protected], [email protected], "Antonio Quartulli" <[email protected]>
>> 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
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
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