Skip to contentSkip to conversation

Warning in ath9k after update from 2.6.33.1 to 2.6.33.2

DISCUSSION Thomas Bächler 4 participants 6 messages Apr 9, 2010 – Apr 10, 2010

lore
Share & tools
lore
#0 lore raw

Since I upgraded from 2.6.33.1 to .2, I get the following warning sometimes, related to wireless:

------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x82/0xb0()
Hardware name: TECRA A11
Modules linked in: ipv6 rfcomm sco bnep l2cap bridge stp llc

cpufreq_ondemand tun ext3 jbd btusb bluetooth uvcvideo videodev snd_seq_dummy v4l1_compat arc4 snd_seq_oss ecb v4l2_compat_ioctl32 snd_seq_midi_event snd_hda_codec_intelhdmi snd_seq snd_seq_device tpm_infineon snd_hda_codec_realtek ath9k snd_pcm_oss ath9k_common snd_mixer_oss snd_hda_intel snd_hda_codec mac80211 snd_hwdep snd_pcm snd_timer ath9k_hw snd joydev soundcore ath sdhci_pci kvm_intel snd_page_alloc ehci_hcd iTCO_wdt evdev sdhci iTCO_vendor_support kvm usbcore mmc_core e1000e psmouse tpm_tis cfg80211 tpm toshiba_acpi acpi_cpufreq led_class tpm_bios rfkill toshiba_bluetooth serio_raw pcspkr sr_mod thermal cdrom battery sg ac freq_table processor rtc_cmos rtc_core rtc_lib fpu aesni_intel cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod sd_mod ahci libata scsi_mod ext4 mbcache jbd2 crc16 i915 drm_kms_helper drm i2c_algo_bit button i2c_core video output intel_agp [last unloaded: microcode]
Pid: 2571, comm: wpa_supplicant Not tainted 2.6.33-ARCH #1

Call Trace:
 [<ffffffff81052a08>] warn_slowpath_common+0x78/0xb0
 [<ffffffff81052a4f>] warn_slowpath_null+0xf/0x20
 [<ffffffff81059682>] local_bh_enable_ip+0x82/0xb0
 [<ffffffff8135d42f>] _raw_spin_unlock_bh+0x1f/0x30
 [<ffffffffa04018ed>] ath_tx_node_cleanup+0x19d/0x1c0 [ath9k]
 [<ffffffffa03fc607>] ath9k_sta_notify+0x57/0xb0 [ath9k]
 [<ffffffffa039bbc4>] __sta_info_unlink+0x174/0x220 [mac80211]
 [<ffffffffa039bca8>] sta_info_unlink+0x38/0x60 [mac80211]
 [<ffffffffa03a2639>] ieee80211_set_disassoc+0x1e9/0x290 [mac80211]
 [<ffffffffa03a2e89>] ieee80211_mgd_deauth+0x159/0x160 [mac80211]
 [<ffffffff8104d700>] ? default_wake_function+0x0/0x10
 [<ffffffffa03a9b69>] ieee80211_deauth+0x19/0x20 [mac80211]
 [<ffffffffa02426de>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
 [<ffffffff8135baad>] ? __mutex_lock_slowpath+0x26d/0x370
 [<ffffffffa0246839>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
 [<ffffffffa0248f9c>] cfg80211_wext_siwmlme+0x8c/0xa0 [cfg80211]
 [<ffffffff8133e6b7>] ioctl_standard_iw_point+0x207/0x3a0
 [<ffffffffa0248f10>] ? cfg80211_wext_siwmlme+0x0/0xa0 [cfg80211]
 [<ffffffff8133e850>] ? ioctl_standard_call+0x0/0xd0
 [<ffffffff8133e8e9>] ioctl_standard_call+0x99/0xd0
 [<ffffffff812b2660>] ? __dev_get_by_name+0xa0/0xc0
 [<ffffffff8133dce7>] wext_ioctl_dispatch+0x1f7/0x210
 [<ffffffff8133f330>] ? ioctl_private_call+0x0/0xa0
 [<ffffffff8133de91>] wext_handle_ioctl+0x41/0x90
 [<ffffffff812b8299>] dev_ioctl+0x679/0x850
 [<ffffffff812a0522>] sock_ioctl+0xe2/0x290
 [<ffffffff812a369d>] ? sys_recvfrom+0x13d/0x160
 [<ffffffff811324c8>] vfs_ioctl+0x38/0xd0
 [<ffffffff81132670>] do_vfs_ioctl+0x80/0x560
 [<ffffffff81132bd1>] sys_ioctl+0x81/0xa0
 [<ffffffff8100b1f9>] ? do_device_not_available+0x9/0x10
 [<ffffffff81009fc2>] system_call_fastpath+0x16/0x1b
---[ end trace 8dbf12cb72787a6d ]---

This machine is an Intel Core i5-520M running x86_64, wireless is ath9k.

#1 lore raw
Quoted 6 lines · Thomas Bächler

Since I upgraded from 2.6.33.1 to .2, I get the following warning sometimes, related to wireless:

------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x82/0xb0()
Hardware name: TECRA A11

...

Quoted 3 lines
 [<ffffffff8135d42f>] _raw_spin_unlock_bh+0x1f/0x30
 [<ffffffffa04018ed>] ath_tx_node_cleanup+0x19d/0x1c0 [ath9k]
 [<ffffffffa03fc607>] ath9k_sta_notify+0x57/0xb0 [ath9k]

Indeed, the patch between 2.6.32.1 and 2.6.32.2 replaces spin_lock with spin_lock_bh and spin_unlock with spin_unlock_bh. The exact commit is 0524bcfa80f1fffb4e1fe18a0a28900869a58a7c by Ming Lei.

It's the unlock that gives the warning. Line 143 in kernel/softirq.c is:

WARN_ON_ONCE(in_irq() || irqs_disabled());

As I understand, the warning would be emitted when softirqs are enabled while hardirqs are disabled. Hardirqs have a higher priority, so it would create a priority inversion.

Quoted 19 lines
 [<ffffffffa039bbc4>] __sta_info_unlink+0x174/0x220 [mac80211]
 [<ffffffffa039bca8>] sta_info_unlink+0x38/0x60 [mac80211]
 [<ffffffffa03a2639>] ieee80211_set_disassoc+0x1e9/0x290 [mac80211]
 [<ffffffffa03a2e89>] ieee80211_mgd_deauth+0x159/0x160 [mac80211]
 [<ffffffff8104d700>] ? default_wake_function+0x0/0x10
 [<ffffffffa03a9b69>] ieee80211_deauth+0x19/0x20 [mac80211]
 [<ffffffffa02426de>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
 [<ffffffff8135baad>] ? __mutex_lock_slowpath+0x26d/0x370
 [<ffffffffa0246839>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
 [<ffffffffa0248f9c>] cfg80211_wext_siwmlme+0x8c/0xa0 [cfg80211]
 [<ffffffff8133e6b7>] ioctl_standard_iw_point+0x207/0x3a0
 [<ffffffffa0248f10>] ? cfg80211_wext_siwmlme+0x0/0xa0 [cfg80211]
 [<ffffffff8133e850>] ? ioctl_standard_call+0x0/0xd0
 [<ffffffff8133e8e9>] ioctl_standard_call+0x99/0xd0
 [<ffffffff812b2660>] ? __dev_get_by_name+0xa0/0xc0
 [<ffffffff8133dce7>] wext_ioctl_dispatch+0x1f7/0x210
 [<ffffffff8133f330>] ? ioctl_private_call+0x0/0xa0
 [<ffffffff8133de91>] wext_handle_ioctl+0x41/0x90
 [<ffffffff812b8299>] dev_ioctl+0x679/0x850
Quoted 8 lines
 [<ffffffff812a0522>] sock_ioctl+0xe2/0x290
 [<ffffffff812a369d>] ? sys_recvfrom+0x13d/0x160
 [<ffffffff811324c8>] vfs_ioctl+0x38/0xd0
 [<ffffffff81132670>] do_vfs_ioctl+0x80/0x560
 [<ffffffff81132bd1>] sys_ioctl+0x81/0xa0
 [<ffffffff8100b1f9>] ? do_device_not_available+0x9/0x10
 [<ffffffff81009fc2>] system_call_fastpath+0x16/0x1b
---[ end trace 8dbf12cb72787a6d ]---

This looks like a call initiated by userspace through wireless extensions. I don't see where hardirqs are disabled.

A simple fix would be to use spin_lock_irqsave/spin_unlock_irqrestore, but I would prefer to understand what is going on.

It's a regression in stable series, so it should be taken very seriously.

Signature · 2 lines
Regards,
Pavel Roskin
#2 lore raw

2010/4/10 Pavel Roskin <[email protected]>:

Quoted 7 lines · Thomas Bächler
Quoted 6 lines

Since I upgraded from 2.6.33.1 to .2, I get the following warning sometimes, related to wireless:

------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x82/0xb0()
Hardware name: TECRA A11
Quoted 8 lines

...

Quoted 3 lines
 [<ffffffff8135d42f>] _raw_spin_unlock_bh+0x1f/0x30
 [<ffffffffa04018ed>] ath_tx_node_cleanup+0x19d/0x1c0 [ath9k]
 [<ffffffffa03fc607>] ath9k_sta_notify+0x57/0xb0 [ath9k]

Indeed, the patch between 2.6.32.1 and 2.6.32.2 replaces spin_lock with spin_lock_bh and spin_unlock with spin_unlock_bh.  The exact commit is 0524bcfa80f1fffb4e1fe18a0a28900869a58a7c by Ming Lei.

The commit does fix a lockdep warning.

Thomas, could you enable lockdep to reproduce and see if any warning may be triggered?

Thanks,

Quoted 51 lines

It's the unlock that gives the warning.  Line 143 in kernel/softirq.c is:

WARN_ON_ONCE(in_irq() || irqs_disabled());

As I understand, the warning would be emitted when softirqs are enabled while hardirqs are disabled.  Hardirqs have a higher priority, so it would create a priority inversion.

Quoted 19 lines
 [<ffffffffa039bbc4>] __sta_info_unlink+0x174/0x220 [mac80211]
 [<ffffffffa039bca8>] sta_info_unlink+0x38/0x60 [mac80211]
 [<ffffffffa03a2639>] ieee80211_set_disassoc+0x1e9/0x290 [mac80211]
 [<ffffffffa03a2e89>] ieee80211_mgd_deauth+0x159/0x160 [mac80211]
 [<ffffffff8104d700>] ? default_wake_function+0x0/0x10
 [<ffffffffa03a9b69>] ieee80211_deauth+0x19/0x20 [mac80211]
 [<ffffffffa02426de>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
 [<ffffffff8135baad>] ? __mutex_lock_slowpath+0x26d/0x370
 [<ffffffffa0246839>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
 [<ffffffffa0248f9c>] cfg80211_wext_siwmlme+0x8c/0xa0 [cfg80211]
 [<ffffffff8133e6b7>] ioctl_standard_iw_point+0x207/0x3a0
 [<ffffffffa0248f10>] ? cfg80211_wext_siwmlme+0x0/0xa0 [cfg80211]
 [<ffffffff8133e850>] ? ioctl_standard_call+0x0/0xd0
 [<ffffffff8133e8e9>] ioctl_standard_call+0x99/0xd0
 [<ffffffff812b2660>] ? __dev_get_by_name+0xa0/0xc0
 [<ffffffff8133dce7>] wext_ioctl_dispatch+0x1f7/0x210
 [<ffffffff8133f330>] ? ioctl_private_call+0x0/0xa0
 [<ffffffff8133de91>] wext_handle_ioctl+0x41/0x90
 [<ffffffff812b8299>] dev_ioctl+0x679/0x850
Quoted 8 lines
 [<ffffffff812a0522>] sock_ioctl+0xe2/0x290
 [<ffffffff812a369d>] ? sys_recvfrom+0x13d/0x160
 [<ffffffff811324c8>] vfs_ioctl+0x38/0xd0
 [<ffffffff81132670>] do_vfs_ioctl+0x80/0x560
 [<ffffffff81132bd1>] sys_ioctl+0x81/0xa0
 [<ffffffff8100b1f9>] ? do_device_not_available+0x9/0x10
 [<ffffffff81009fc2>] system_call_fastpath+0x16/0x1b
---[ end trace 8dbf12cb72787a6d ]---

This looks like a call initiated by userspace through wireless extensions.  I don't see where hardirqs are disabled.

A simple fix would be to use spin_lock_irqsave/spin_unlock_irqrestore, but I would prefer to understand what is going on.

It's a regression in stable series, so it should be taken very seriously.

--
Regards,
Pavel Roskin

Signature · 1 line
Lei Ming
#3 lore raw
In reply to Thomas Bächler

2010/4/10 Thomas Bächler <[email protected]>:

Quoted 57 lines

Since I upgraded from 2.6.33.1 to .2, I get the following warning sometimes, related to wireless:

------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x82/0xb0()
Hardware name: TECRA A11
Modules linked in: ipv6 rfcomm sco bnep l2cap bridge stp llc

cpufreq_ondemand tun ext3 jbd btusb bluetooth uvcvideo videodev snd_seq_dummy v4l1_compat arc4 snd_seq_oss ecb v4l2_compat_ioctl32 snd_seq_midi_event snd_hda_codec_intelhdmi snd_seq snd_seq_device tpm_infineon snd_hda_codec_realtek ath9k snd_pcm_oss ath9k_common snd_mixer_oss snd_hda_intel snd_hda_codec mac80211 snd_hwdep snd_pcm snd_timer ath9k_hw snd joydev soundcore ath sdhci_pci kvm_intel snd_page_alloc ehci_hcd iTCO_wdt evdev sdhci iTCO_vendor_support kvm usbcore mmc_core e1000e psmouse tpm_tis cfg80211 tpm toshiba_acpi acpi_cpufreq led_class tpm_bios rfkill toshiba_bluetooth serio_raw pcspkr sr_mod thermal cdrom battery sg ac freq_table processor rtc_cmos rtc_core rtc_lib fpu aesni_intel cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod sd_mod ahci libata scsi_mod ext4 mbcache jbd2 crc16 i915 drm_kms_helper drm i2c_algo_bit button i2c_core video output intel_agp [last unloaded: microcode]
Pid: 2571, comm: wpa_supplicant Not tainted 2.6.33-ARCH #1

Call Trace:
 [<ffffffff81052a08>] warn_slowpath_common+0x78/0xb0
 [<ffffffff81052a4f>] warn_slowpath_null+0xf/0x20
 [<ffffffff81059682>] local_bh_enable_ip+0x82/0xb0
 [<ffffffff8135d42f>] _raw_spin_unlock_bh+0x1f/0x30
 [<ffffffffa04018ed>] ath_tx_node_cleanup+0x19d/0x1c0 [ath9k]
 [<ffffffffa03fc607>] ath9k_sta_notify+0x57/0xb0 [ath9k]
 [<ffffffffa039bbc4>] __sta_info_unlink+0x174/0x220 [mac80211]
 [<ffffffffa039bca8>] sta_info_unlink+0x38/0x60 [mac80211]
 [<ffffffffa03a2639>] ieee80211_set_disassoc+0x1e9/0x290 [mac80211]
 [<ffffffffa03a2e89>] ieee80211_mgd_deauth+0x159/0x160 [mac80211]
 [<ffffffff8104d700>] ? default_wake_function+0x0/0x10
 [<ffffffffa03a9b69>] ieee80211_deauth+0x19/0x20 [mac80211]
 [<ffffffffa02426de>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
 [<ffffffff8135baad>] ? __mutex_lock_slowpath+0x26d/0x370
 [<ffffffffa0246839>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
 [<ffffffffa0248f9c>] cfg80211_wext_siwmlme+0x8c/0xa0 [cfg80211]
 [<ffffffff8133e6b7>] ioctl_standard_iw_point+0x207/0x3a0
 [<ffffffffa0248f10>] ? cfg80211_wext_siwmlme+0x0/0xa0 [cfg80211]
 [<ffffffff8133e850>] ? ioctl_standard_call+0x0/0xd0
 [<ffffffff8133e8e9>] ioctl_standard_call+0x99/0xd0
 [<ffffffff812b2660>] ? __dev_get_by_name+0xa0/0xc0
 [<ffffffff8133dce7>] wext_ioctl_dispatch+0x1f7/0x210
 [<ffffffff8133f330>] ? ioctl_private_call+0x0/0xa0
 [<ffffffff8133de91>] wext_handle_ioctl+0x41/0x90
 [<ffffffff812b8299>] dev_ioctl+0x679/0x850
 [<ffffffff812a0522>] sock_ioctl+0xe2/0x290
 [<ffffffff812a369d>] ? sys_recvfrom+0x13d/0x160
 [<ffffffff811324c8>] vfs_ioctl+0x38/0xd0
 [<ffffffff81132670>] do_vfs_ioctl+0x80/0x560
 [<ffffffff81132bd1>] sys_ioctl+0x81/0xa0
 [<ffffffff8100b1f9>] ? do_device_not_available+0x9/0x10
 [<ffffffff81009fc2>] system_call_fastpath+0x16/0x1b
---[ end trace 8dbf12cb72787a6d ]---
Quoted 3 lines

This machine is an Intel Core i5-520M running x86_64, wireless is ath9k.

I does not find the issue on 2.6.34-rc3-wireless-next, using wext and trigger a disassociation.

How do you reproduce the warning?

Thanks,

Signature · 1 line
Lei Ming
#4 lore raw

Am 10.04.2010 05:21, schrieb Ming Lei:

Quoted 54 lines
Quoted 54 lines
------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x82/0xb0()
Hardware name: TECRA A11
Modules linked in: ipv6 rfcomm sco bnep l2cap bridge stp llc

cpufreq_ondemand tun ext3 jbd btusb bluetooth uvcvideo videodev snd_seq_dummy v4l1_compat arc4 snd_seq_oss ecb v4l2_compat_ioctl32 snd_seq_midi_event snd_hda_codec_intelhdmi snd_seq snd_seq_device tpm_infineon snd_hda_codec_realtek ath9k snd_pcm_oss ath9k_common snd_mixer_oss snd_hda_intel snd_hda_codec mac80211 snd_hwdep snd_pcm snd_timer ath9k_hw snd joydev soundcore ath sdhci_pci kvm_intel snd_page_alloc ehci_hcd iTCO_wdt evdev sdhci iTCO_vendor_support kvm usbcore mmc_core e1000e psmouse tpm_tis cfg80211 tpm toshiba_acpi acpi_cpufreq led_class tpm_bios rfkill toshiba_bluetooth serio_raw pcspkr sr_mod thermal cdrom battery sg ac freq_table processor rtc_cmos rtc_core rtc_lib fpu aesni_intel cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod sd_mod ahci libata scsi_mod ext4 mbcache jbd2 crc16 i915 drm_kms_helper drm i2c_algo_bit button i2c_core video output intel_agp [last unloaded: microcode]
Pid: 2571, comm: wpa_supplicant Not tainted 2.6.33-ARCH #1

Call Trace:
 [<ffffffff81052a08>] warn_slowpath_common+0x78/0xb0
 [<ffffffff81052a4f>] warn_slowpath_null+0xf/0x20
 [<ffffffff81059682>] local_bh_enable_ip+0x82/0xb0
 [<ffffffff8135d42f>] _raw_spin_unlock_bh+0x1f/0x30
 [<ffffffffa04018ed>] ath_tx_node_cleanup+0x19d/0x1c0 [ath9k]
 [<ffffffffa03fc607>] ath9k_sta_notify+0x57/0xb0 [ath9k]
 [<ffffffffa039bbc4>] __sta_info_unlink+0x174/0x220 [mac80211]
 [<ffffffffa039bca8>] sta_info_unlink+0x38/0x60 [mac80211]
 [<ffffffffa03a2639>] ieee80211_set_disassoc+0x1e9/0x290 [mac80211]
 [<ffffffffa03a2e89>] ieee80211_mgd_deauth+0x159/0x160 [mac80211]
 [<ffffffff8104d700>] ? default_wake_function+0x0/0x10
 [<ffffffffa03a9b69>] ieee80211_deauth+0x19/0x20 [mac80211]
 [<ffffffffa02426de>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
 [<ffffffff8135baad>] ? __mutex_lock_slowpath+0x26d/0x370
 [<ffffffffa0246839>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
 [<ffffffffa0248f9c>] cfg80211_wext_siwmlme+0x8c/0xa0 [cfg80211]
 [<ffffffff8133e6b7>] ioctl_standard_iw_point+0x207/0x3a0
 [<ffffffffa0248f10>] ? cfg80211_wext_siwmlme+0x0/0xa0 [cfg80211]
 [<ffffffff8133e850>] ? ioctl_standard_call+0x0/0xd0
 [<ffffffff8133e8e9>] ioctl_standard_call+0x99/0xd0
 [<ffffffff812b2660>] ? __dev_get_by_name+0xa0/0xc0
 [<ffffffff8133dce7>] wext_ioctl_dispatch+0x1f7/0x210
 [<ffffffff8133f330>] ? ioctl_private_call+0x0/0xa0
 [<ffffffff8133de91>] wext_handle_ioctl+0x41/0x90
 [<ffffffff812b8299>] dev_ioctl+0x679/0x850
 [<ffffffff812a0522>] sock_ioctl+0xe2/0x290
 [<ffffffff812a369d>] ? sys_recvfrom+0x13d/0x160
 [<ffffffff811324c8>] vfs_ioctl+0x38/0xd0
 [<ffffffff81132670>] do_vfs_ioctl+0x80/0x560
 [<ffffffff81132bd1>] sys_ioctl+0x81/0xa0
 [<ffffffff8100b1f9>] ? do_device_not_available+0x9/0x10
 [<ffffffff81009fc2>] system_call_fastpath+0x16/0x1b
---[ end trace 8dbf12cb72787a6d ]---
Quoted 8 lines
Quoted 3 lines

This machine is an Intel Core i5-520M running x86_64, wireless is ath9k.

I does not find the issue on 2.6.34-rc3-wireless-next, using wext and trigger a disassociation.

How do you reproduce the warning?

I am not entirely sure. At first it only happened when disassociating from the AP at work. The above trace actually appeared when associating to my home AP.

I have no exact means of reproducing this, it "just happens" during normal usage, but always during association or disassociation so far. Sorry that I cannot be more precise.

Quoted 2 lines

Thomas, could you enable lockdep to reproduce and see if any warning may be triggered?

Sorry, I don't know what that means.

#5 lore raw
In reply to Thomas Bächler
Quoted 48 lines · Thomas Bächler

Since I upgraded from 2.6.33.1 to .2, I get the following warning sometimes, related to wireless:

------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x82/0xb0()
Hardware name: TECRA A11
Modules linked in: ipv6 rfcomm sco bnep l2cap bridge stp llc

cpufreq_ondemand tun ext3 jbd btusb bluetooth uvcvideo videodev snd_seq_dummy v4l1_compat arc4 snd_seq_oss ecb v4l2_compat_ioctl32 snd_seq_midi_event snd_hda_codec_intelhdmi snd_seq snd_seq_device tpm_infineon snd_hda_codec_realtek ath9k snd_pcm_oss ath9k_common snd_mixer_oss snd_hda_intel snd_hda_codec mac80211 snd_hwdep snd_pcm snd_timer ath9k_hw snd joydev soundcore ath sdhci_pci kvm_intel snd_page_alloc ehci_hcd iTCO_wdt evdev sdhci iTCO_vendor_support kvm usbcore mmc_core e1000e psmouse tpm_tis cfg80211 tpm toshiba_acpi acpi_cpufreq led_class tpm_bios rfkill toshiba_bluetooth serio_raw pcspkr sr_mod thermal cdrom battery sg ac freq_table processor rtc_cmos rtc_core rtc_lib fpu aesni_intel cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod sd_mod ahci libata scsi_mod ext4 mbcache jbd2 crc16 i915 drm_kms_helper drm i2c_algo_bit button i2c_core video output intel_agp [last unloaded: microcode]
Pid: 2571, comm: wpa_supplicant Not tainted 2.6.33-ARCH #1

Call Trace:
 [<ffffffff81052a08>] warn_slowpath_common+0x78/0xb0
 [<ffffffff81052a4f>] warn_slowpath_null+0xf/0x20
 [<ffffffff81059682>] local_bh_enable_ip+0x82/0xb0
 [<ffffffff8135d42f>] _raw_spin_unlock_bh+0x1f/0x30
 [<ffffffffa04018ed>] ath_tx_node_cleanup+0x19d/0x1c0 [ath9k]
 [<ffffffffa03fc607>] ath9k_sta_notify+0x57/0xb0 [ath9k]
 [<ffffffffa039bbc4>] __sta_info_unlink+0x174/0x220 [mac80211]
 [<ffffffffa039bca8>] sta_info_unlink+0x38/0x60 [mac80211]
 [<ffffffffa03a2639>] ieee80211_set_disassoc+0x1e9/0x290 [mac80211]
 [<ffffffffa03a2e89>] ieee80211_mgd_deauth+0x159/0x160 [mac80211]
 [<ffffffff8104d700>] ? default_wake_function+0x0/0x10
 [<ffffffffa03a9b69>] ieee80211_deauth+0x19/0x20 [mac80211]
 [<ffffffffa02426de>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
 [<ffffffff8135baad>] ? __mutex_lock_slowpath+0x26d/0x370
 [<ffffffffa0246839>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
 [<ffffffffa0248f9c>] cfg80211_wext_siwmlme+0x8c/0xa0 [cfg80211]
 [<ffffffff8133e6b7>] ioctl_standard_iw_point+0x207/0x3a0
 [<ffffffffa0248f10>] ? cfg80211_wext_siwmlme+0x0/0xa0 [cfg80211]
 [<ffffffff8133e850>] ? ioctl_standard_call+0x0/0xd0
 [<ffffffff8133e8e9>] ioctl_standard_call+0x99/0xd0
 [<ffffffff812b2660>] ? __dev_get_by_name+0xa0/0xc0
 [<ffffffff8133dce7>] wext_ioctl_dispatch+0x1f7/0x210
 [<ffffffff8133f330>] ? ioctl_private_call+0x0/0xa0
 [<ffffffff8133de91>] wext_handle_ioctl+0x41/0x90
 [<ffffffff812b8299>] dev_ioctl+0x679/0x850
Quoted 8 lines
 [<ffffffff812a0522>] sock_ioctl+0xe2/0x290
 [<ffffffff812a369d>] ? sys_recvfrom+0x13d/0x160
 [<ffffffff811324c8>] vfs_ioctl+0x38/0xd0
 [<ffffffff81132670>] do_vfs_ioctl+0x80/0x560
 [<ffffffff81132bd1>] sys_ioctl+0x81/0xa0
 [<ffffffff8100b1f9>] ? do_device_not_available+0x9/0x10
 [<ffffffff81009fc2>] system_call_fastpath+0x16/0x1b
---[ end trace 8dbf12cb72787a6d ]---

I think the problem is that the locking for sta_notify changed, and a patch that was written for the new locking was backported to the old, irq-disabled, locking.

johannes