no sure, there are some mac80211 race condition problem found and being address now. maybe you can try the patch from Nikolay and see if help. Wey On Tue, 2011-11-29 at 06:18 -0800, Ken D'Ambrosio wrote: > I hadn't sent this, because I'd thought I was only getting WARNINGs on my > Virtualbox-tainted kernel, but this happened untainted, so here you go. Hope > it helps! > > -Ken > > > [ 198.113130] wlan0: deauthenticating from 00:27:0d:98:d1:f1 by local choice > (reason=3) > [ 198.113277] ------------[ cut here ]------------ > [ 198.113313] WARNING: at net/wireless/mlme.c:309 > __cfg80211_auth_remove+0x56/0xa0 [cfg80211]() > [ 198.113317] Hardware name: EC14 Series > [ 198.113320] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat binfmt_misc > ppdev snd_hda_codec_hdmi snd_hda_codec_realtek joydev snd_hda_intel > snd_hda_codec arc4 snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm usb_storage > snd_seq_dummy uvcvideo videodev snd_seq_oss fbcon tileblit snd_seq_midi i915 > snd_rawmidi iwlwifi font bitblit snd_seq_midi_event softcursor snd_seq psmouse > snd_timer snd_seq_device serio_raw mac80211 drm_kms_helper acer_wmi drm > sparse_keymap atl1c i2c_algo_bit cfg80211 intel_agp snd intel_gtt agpgart > soundcore video snd_page_alloc lp parport > [ 198.113397] Pid: 44, comm: kworker/u:3 Not tainted 3.1.0+ #1 > [ 198.113401] Call Trace: > [ 198.113412] [<c068e057>] ? printk+0x1d/0x1f > [ 198.113423] [<c01562b2>] warn_slowpath_common+0x72/0xa0 > [ 198.113439] [<f8cbc1e6>] ? __cfg80211_auth_remove+0x56/0xa0 [cfg80211] > [ 198.113454] [<f8cbc1e6>] ? __cfg80211_auth_remove+0x56/0xa0 [cfg80211] > [ 198.113461] [<c0156302>] warn_slowpath_null+0x22/0x30 > [ 198.113480] [<f8cbc1e6>] __cfg80211_auth_remove+0x56/0xa0 [cfg80211] > [ 198.113496] [<f8cbc2ae>] cfg80211_send_auth_timeout+0x5e/0xc0 [cfg80211] > [ 198.113518] [<f868f796>] ieee80211_probe_auth_done+0xe6/0xf0 [mac80211] > [ 198.113525] [<c014f614>] ? wake_up_process+0x14/0x20 > [ 198.113532] [<c06976ec>] ? __mutex_unlock_slowpath+0x3c/0x50 > [ 198.113552] [<f86929bb>] ieee80211_work_work+0x47b/0x12d0 [mac80211] > [ 198.113559] [<c0134c58>] ? default_spin_lock_flags+0x8/0x10 > [ 198.113566] [<c0698701>] ? _raw_spin_trylock_bh+0x1/0x30 > [ 198.113575] [<c017043e>] process_one_work+0xfe/0x3a0 > [ 198.113580] [<c014f614>] ? wake_up_process+0x14/0x20 > [ 198.113586] [<c016dfe5>] ? start_worker+0x25/0x30 > [ 198.113605] [<f8692540>] ? free_work+0x20/0x20 [mac80211] > [ 198.113612] [<c0170f74>] worker_thread+0x124/0x2d0 > [ 198.113618] [<c0170e50>] ? manage_workers.isra.28+0x1e0/0x1e0 > [ 198.113624] [<c0174ced>] kthread+0x6d/0x80 > [ 198.113630] [<c0174c80>] ? flush_kthread_worker+0x80/0x80 > [ 198.113637] [<c069fb06>] kernel_thread_helper+0x6/0x10 > [ 198.113642] ---[ end trace 04bdbdc199f6d75f ]--- > > > > Hi. For reasons pertaining to btrfs, I'm running 3.1+ kernels, and the wifi > on my system now flakes out sporadically, but reliably. It can sometimes run > for a couple days, but other days (like, say, yesterday) it'll fail upwards of > 30 times. Simply attempting to re-acquire a connection via Network Manager > fails 100%. I need to rmmod and modprobe the iwlwifi module, and then am able > to immediately connect, 100% of the time -- albeit, briefly. Rebooting under > these circumstances seems to have as much affect as reloading the module. (I > wonder if there's something that changes on the WAP side that triggers this? > That would explain the occasional doses of extended uptime, followed by days of > misery, regardless of reboots and module playing.) > > While the behavior, sadly, *is* sporadic, when > > - it's not a problem on older (distribution-supplied) kernels, and > - reloading -- and only reloading -- the module fixes it, however briefly, > > it seems to me it's probably a problem with the module. > > > Here's some additional information: > > * Happens on multiple WAPs (home, hotel, work, etc.) > > * 02:00.0 Network controller: Intel Corporation WiFi Link 1000 Series > > * The system *thinks* everything is fine -- NetworkManager happily shows all > the WAPs, etc. -- but I'm unable to re-acquire them until I reload the module. > > * kernel 3.1.0+, untainted (Chris Mason's btrfs git pull from three weeks ago; > also experienced with slightly older, post 3.x kernels) > > * Seems to fail most quickly under load (e.g., streaming); can push an hour if > doing relatively little > > * I'm unsure which kernel rev. was the tipping point, but Ubuntu 10.04 > generally "just worked," and is what I'm booted to now off of USB -- 2.6.32. > > I'd give you dmesg messages, but I'm -- catch-22 -- Ubuntu 10.04 won't mount my > btrfs partition, but runs WiFi flawlessly. If you need those messages, just > let me know, and I'll pull them off. > > If there's anything else I can help out with, please don't hesitate to let me > know. > > Thanks! > > -Ken > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
