From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleksij Rempel Date: Mon, 27 Jan 2014 20:02:52 +0100 Subject: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302 In-Reply-To: References: <52E1712B.70202@rempel-privat.de>, <52E191B3.2070601@meshcoding.com>, Message-ID: <52E6AD5C.3020005@rempel-privat.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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" >> An: "Oleksij Rempel" , mail at fuerstflorian.de, ath9k-devel at lists.ath9k.org, "Antonio Quartulli" >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mout.gmx.net ([212.227.15.15]:50768 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753903AbaA0TDI (ORCPT ); Mon, 27 Jan 2014 14:03:08 -0500 Received: from [192.168.1.221] ([93.196.93.204]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MSdNs-1VgOPW1NfY-00RdEU for ; Mon, 27 Jan 2014 20:03:06 +0100 Message-ID: <52E6AD5C.3020005@rempel-privat.de> (sfid-20140127_200312_613171_5D44AB4A) Date: Mon, 27 Jan 2014 20:02:52 +0100 From: Oleksij Rempel MIME-Version: 1.0 To: mail@fuerstflorian.de, ath9k-devel@lists.ath9k.org, "linux-wireless@vger.kernel.org" , Johannes Berg Subject: Re: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling while atomic: ksoftirqd/0/3/0x00000302 References: <52E1712B.70202@rempel-privat.de>, <52E191B3.2070601@meshcoding.com>, In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4NdC4C7MrXOAroPap8N17dmWXSIh5dG7p" Sender: linux-wireless-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4NdC4C7MrXOAroPap8N17dmWXSIh5dG7p Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Johannes, i found this bug report with your response: https://bugzilla.redhat.com/show_bug.cgi?id=3D990955 "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,=20 > =20 >> Just as a generic suggestion, have you tried testing a slightly older >> kernel versions to see if that makes any difference? >=20 > Thanks for the suggestion. I will try to use a older kernel version, bu= t it will take some days to be > sure if it works again (and I naturally will report about).=20 > =20 > -- > Flo >=20 >> On 23/01/14 23:03, Antonio Quartulli wrote: >> Von: "Antonio Quartulli" >> An: "Oleksij Rempel" , mail@fuerstflorian.de, = ath9k-devel@lists.ath9k.org, "Antonio Quartulli" >> Betreff: Re: [ath9k-devel] [BUG] Atheros AR7010+AR9287: Scheduling whi= le 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 slo= w >>> on some USB 2.0 devices. >>> >> >> I implemented the ath9k_htc_sta_rc_update() API but I don't really kno= w >> the internals of the ath9k_htc driver...therefore I don't know if thes= e >> WMI commands have any consequence on this..Could it be that this >> slowness is triggering some reaction in the kernel (due to the fact th= at >> 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? >> >> >> >> --=20 >> Antonio Quartulli --=20 Regards, Oleksij --4NdC4C7MrXOAroPap8N17dmWXSIh5dG7p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLmrV8ACgkQHwImuRkmbWmYNAD/TXYjvAwVaZ+pvDkfiT0xRY9j WSMbypxli3o4sva8+s4A/10nmhscYCyBHs78i6Dz5md3iGtnrGgTRLCZyLEFV1az =NG1I -----END PGP SIGNATURE----- --4NdC4C7MrXOAroPap8N17dmWXSIh5dG7p--