From: "Thomas Bächler" <thomas@archlinux.org>
To: Ming Lei <tom.leiming@gmail.com>
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Warning in ath9k after update from 2.6.33.1 to 2.6.33.2
Date: Sat, 10 Apr 2010 13:15:09 +0200 [thread overview]
Message-ID: <4BC05DBD.6070005@archlinux.org> (raw)
In-Reply-To: <w2vd82e647a1004092021nadf2e47fu7bf9ccd9e7f928d5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3947 bytes --]
Am 10.04.2010 05:21, schrieb Ming Lei:
>> ------------[ 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.
>>
>>
>
> 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.
> Thomas, could you enable lockdep to reproduce and see if any warning
> may be triggered?
Sorry, I don't know what that means.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2010-04-10 11:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-09 17:21 Warning in ath9k after update from 2.6.33.1 to 2.6.33.2 Thomas Bächler
2010-04-09 19:24 ` Pavel Roskin
2010-04-10 3:01 ` Ming Lei
2010-04-10 3:21 ` Ming Lei
2010-04-10 11:15 ` Thomas Bächler [this message]
2010-04-10 6:54 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BC05DBD.6070005@archlinux.org \
--to=thomas@archlinux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=tom.leiming@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).