CPU load after killing iwlagn with RF kill switch

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.

Quoted 5 lines · Leonid Podolny

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.

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.

Quoted 3 lines · Tomas Winkler

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)?

Quoted 6 lines · John W. Linville

Quoted 3 lines · Tomas Winkler

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.

Quoted 3 lines

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.

Quoted 12 lines · Tomas Winkler

Quoted 9 lines · John W. Linville

Quoted 3 lines · Tomas Winkler

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)?

Quoted 4 lines

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...

Quoted 1 line

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

Thanks!

John
--
John W. Linville
[email protected]

Quoted 13 lines · John W. Linville

Quoted 12 lines · Tomas Winkler

Quoted 9 lines · John W. Linville

Quoted 3 lines · Tomas Winkler

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)?

Quoted 8 lines

Quoted 4 lines

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.