Re: CPU load after killing iwlagn with RF kill switch

Re: CPU load after killing iwlagn with RF kill switch

[Mirco Tischler]

[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]

On Fri, 15 Aug 2008 23:50:10 +0300, Leonid Podolny wrote:
> Hi,
> With a new iwlagn driver and 2.6.27-rc3, if I turn off the wireless 
> (intel 4965ag) by RF kill switch, the CPU utilization of ksoftirqd 
> process raises to 100% and stays there until I rmmod the module.
> Please let me know what further information I can provide.

Hi

Same on my machine with same chip and same kernel.
If I use the switch on the side of my laptop to turn off wlan, ksoftirqd eats
up one core of my cpu til I switch it on again or rmmod the iwlagn module. But
when I switch it on before the device loses connection and then off a second
time, I now get a (the) second ksoftirqd process eating up the other core too.
This only happens if a connection is established, though.
I'm not sure if this problem existed in 2.6.26 but I doubt it. (Will check if I
find the time).

My dmesg shows me this:

[48067.257539] iwlagn: Radio Frequency Kill Switch is On:
[48067.257539] Kill switch must be turned off for wireless networking to work.
[48071.295154] wlan0: No ProbeResp from current AP 00:c0:a8:e5:e5:a5 - assume
out of range 
[48072.099173] iwlagn: Error sending REPLY_ADD_STA: enqueue_hcmd failed: -5 
[48072.099260] mac80211-phy1: failed to remove key (0, 00:c0:a8:e5:e5:a5) from
hardware (-5) 
[48072.206028] iwlagn: Error sending REPLY_ADD_STA: enqueue_hcmd failed: -5 
[48072.206028] mac80211-phy1: failed to remove key (1, ff:ff:ff:ff:ff:ff) from
hardware (-5)

The probably interesting parts of my config look like that:

CONFIG_IWLWIFI=m
CONFIG_IWLCORE=m
CONFIG_IWLWIFI_LEDS=y
CONFIG_IWLWIFI_RFKILL=y
# CONFIG_IWLWIFI_DEBUG is not set
CONFIG_IWLAGN=m
CONFIG_IWLAGN_SPECTRUM_MEASUREMENT=y
CONFIG_IWLAGN_LEDS=y
CONFIG_IWL4965=y
# CONFIG_IWL5000 is not set
# CONFIG_IWL3945 is not set

CONFIG_RFKILL=m
# CONFIG_RFKILL_INPUT is not set
CONFIG_RFKILL_LEDS=y
CONFIG_IWLWIFI_RFKILL=y

I can recompile with debug options set if this helps. Just haven't found the
time.

Thanks
Mirco

P.S.: added some cc's for iwlwifi and rfkill.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: CPU load after killing iwlagn with RF kill switch

[Tomas Winkler]

On Sun, Aug 17, 2008 at 4:59 AM, Mirco Tischler <mt-ml@gmx.de> wrote:
> On Fri, 15 Aug 2008 23:50:10 +0300, Leonid Podolny wrote:
>> Hi,
>> With a new iwlagn driver and 2.6.27-rc3, if I turn off the wireless
>> (intel 4965ag) by RF kill switch, the CPU utilization of ksoftirqd
>> process raises to 100% and stays there until I rmmod the module.
>> Please let me know what further information I can provide.
>
> Hi
>
> Same on my machine with same chip and same kernel.
> If I use the switch on the side of my laptop to turn off wlan, ksoftirqd eats
> up one core of my cpu til I switch it on again or rmmod the iwlagn module. But
> when I switch it on before the device loses connection and then off a second
> time, I now get a (the) second ksoftirqd process eating up the other core too.
> This only happens if a connection is established, though.
> I'm not sure if this problem existed in 2.6.26 but I doubt it. (Will check if I
> find the time).
>
> My dmesg shows me this:
>
> [48067.257539] iwlagn: Radio Frequency Kill Switch is On:
> [48067.257539] Kill switch must be turned off for wireless networking to work.
> [48071.295154] wlan0: No ProbeResp from current AP 00:c0:a8:e5:e5:a5 - assume
> out of range
> [48072.099173] iwlagn: Error sending REPLY_ADD_STA: enqueue_hcmd failed: -5
> [48072.099260] mac80211-phy1: failed to remove key (0, 00:c0:a8:e5:e5:a5) from
> hardware (-5)
> [48072.206028] iwlagn: Error sending REPLY_ADD_STA: enqueue_hcmd failed: -5
> [48072.206028] mac80211-phy1: failed to remove key (1, ff:ff:ff:ff:ff:ff) from
> hardware (-5)
>
> The probably interesting parts of my config look like that:
>
> CONFIG_IWLWIFI=m
> CONFIG_IWLCORE=m
> CONFIG_IWLWIFI_LEDS=y
> CONFIG_IWLWIFI_RFKILL=y
> # CONFIG_IWLWIFI_DEBUG is not set
> CONFIG_IWLAGN=m
> CONFIG_IWLAGN_SPECTRUM_MEASUREMENT=y
> CONFIG_IWLAGN_LEDS=y
> CONFIG_IWL4965=y
> # CONFIG_IWL5000 is not set
> # CONFIG_IWL3945 is not set
>
> CONFIG_RFKILL=m
> # CONFIG_RFKILL_INPUT is not set
> CONFIG_RFKILL_LEDS=y
> CONFIG_IWLWIFI_RFKILL=y
>
> I can recompile with debug options set if this helps. Just haven't found the
> time.

There is gap in current rfkill implementation that we didn't close
yet.  There were also few patches that were not signed by Intel and
are apparently wrong.
Tomas.


> Thanks
> Mirco
>
> P.S.: added some cc's for iwlwifi and rfkill.
>

Re: CPU load after killing iwlagn with RF kill switch

[John W. Linville]

On Sun, Aug 17, 2008 at 10:04:12AM +0300, Tomas Winkler wrote:

> There is gap in current rfkill implementation that we didn't close
> yet.  There were also few patches that were not signed by Intel and
> are apparently wrong.

Can you be more specific?  Do you know which patches are wrong (even
if you don't know how to fix them)?

John
-- 
John W. Linville
linville@tuxdriver.com

Re: CPU load after killing iwlagn with RF kill switch

[Tomas Winkler]

On Sun, Aug 17, 2008 at 6:02 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Sun, Aug 17, 2008 at 10:04:12AM +0300, Tomas Winkler wrote:
>
>> There is gap in current rfkill implementation that we didn't close
>> yet.  There were also few patches that were not signed by Intel and
>> are apparently wrong.
>
> Can you be more specific?  Do you know which patches are wrong (even
> if you don't know how to fix them)?
>

80fcc9e28cf3a209fbfb39a7bbddc313c59c7424
This one  is wrong and there are more then are not acked even though
they cause no problem. In general I would prefer that patches will be
acked by Yi or me.
I will try to rebase our rfkill fixes ASAP from iwlwifi-2.6. iwl5000 branch.

Thanks
Tomas

Re: CPU load after killing iwlagn with RF kill switch

[John W. Linville]

On Sun, Aug 17, 2008 at 07:20:54PM +0300, Tomas Winkler wrote:
> On Sun, Aug 17, 2008 at 6:02 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > On Sun, Aug 17, 2008 at 10:04:12AM +0300, Tomas Winkler wrote:
> >
> >> There is gap in current rfkill implementation that we didn't close
> >> yet.  There were also few patches that were not signed by Intel and
> >> are apparently wrong.
> >
> > Can you be more specific?  Do you know which patches are wrong (even
> > if you don't know how to fix them)?
> >
> 
> 80fcc9e28cf3a209fbfb39a7bbddc313c59c7424
> This one  is wrong and there are more then are not acked even though
> they cause no problem. In general I would prefer that patches will be
> acked by Yi or me.

And in general, they are.  In general I would prefer if you would
work upstream instead of working in iwlwifi-2.6 and periodically
dumping a dozen or more patches on me all at once.  C'est la vie...

> I will try to rebase our rfkill fixes ASAP from iwlwifi-2.6. iwl5000 branch.

Thanks!

John
-- 
John W. Linville
linville@tuxdriver.com

Re: CPU load after killing iwlagn with RF kill switch

[Tomas Winkler]

On Sun, Aug 17, 2008 at 8:07 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Sun, Aug 17, 2008 at 07:20:54PM +0300, Tomas Winkler wrote:
>> On Sun, Aug 17, 2008 at 6:02 PM, John W. Linville
>> <linville@tuxdriver.com> wrote:
>> > On Sun, Aug 17, 2008 at 10:04:12AM +0300, Tomas Winkler wrote:
>> >
>> >> There is gap in current rfkill implementation that we didn't close
>> >> yet.  There were also few patches that were not signed by Intel and
>> >> are apparently wrong.
>> >
>> > Can you be more specific?  Do you know which patches are wrong (even
>> > if you don't know how to fix them)?
>> >
>>
>> 80fcc9e28cf3a209fbfb39a7bbddc313c59c7424
>> This one  is wrong and there are more then are not acked even though
>> they cause no problem. In general I would prefer that patches will be
>> acked by Yi or me.
>
> And in general, they are.  In general I would prefer if you would
> work upstream instead of working in iwlwifi-2.6 and periodically
> dumping a dozen or more patches on me all at once.  C'est la vie...

We cannot because no OSV or OEM ships latest kernel and mac80211 is
periodically broken.  There is a reason why compat-wireless was
brought to life. The  innovation to stabilization and testing ratio is
not good. This is of course more complex than that and I didn't find
the golden way yet.

>> I will try to rebase our rfkill fixes ASAP from iwlwifi-2.6. iwl5000 branch.
>
> Thanks!
>
> John
> --
> John W. Linville
> linville@tuxdriver.com
>

Re: CPU load after killing iwlagn with RF kill switch

[Luis R. Rodriguez]

On Sun, Aug 17, 2008 at 11:01:26AM -0700, Tomas Winkler wrote:
> On Sun, Aug 17, 2008 at 8:07 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > On Sun, Aug 17, 2008 at 07:20:54PM +0300, Tomas Winkler wrote:
> >> On Sun, Aug 17, 2008 at 6:02 PM, John W. Linville
> >> <linville@tuxdriver.com> wrote:
> >> > On Sun, Aug 17, 2008 at 10:04:12AM +0300, Tomas Winkler wrote:
> >> >
> >> >> There is gap in current rfkill implementation that we didn't close
> >> >> yet.  There were also few patches that were not signed by Intel and
> >> >> are apparently wrong.
> >> >
> >> > Can you be more specific?  Do you know which patches are wrong (even
> >> > if you don't know how to fix them)?
> >> >
> >>
> >> 80fcc9e28cf3a209fbfb39a7bbddc313c59c7424
> >> This one  is wrong and there are more then are not acked even though
> >> they cause no problem. In general I would prefer that patches will be
> >> acked by Yi or me.
> >
> > And in general, they are.  In general I would prefer if you would
> > work upstream instead of working in iwlwifi-2.6 and periodically
> > dumping a dozen or more patches on me all at once.  C'est la vie...
> 
> We cannot because no OSV or OEM ships latest kernel and mac80211 is
> periodically broken.  There is a reason why compat-wireless was
> brought to life. The  innovation to stabilization and testing ratio is
> not good. This is of course more complex than that and I didn't find
> the golden way yet.

compat-wireless came to life to prevent alternative tree solutions, to
prevent patch hogging in separate trees and to try to help with backward
compatibility. That was my main motivation. If mac80211 is broken I see
no one but ourselves to blame.

OEMs should rely on stock kernels distributions pick. If patches are needed
on top of that then patch *fixes* should be supplied on top of the stable
kernel. Development work (cleanups, etc) can go onto wireless-testing
then.

  Luis