Linux wireless drivers development
 help / color / mirror / Atom feed
From: "Ken D'Ambrosio" <ken@jots.org>
To: <linux-wireless@vger.kernel.org>
Subject: Followup with dmesg WARNING (was Bug report: can't maintain WiFi connectivity in recent kernels.)
Date: Tue, 29 Nov 2011 09:18:40 -0500	[thread overview]
Message-ID: <a562bb7bd5c895756114c38e0de891de@www.jots.org> (raw)

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






             reply	other threads:[~2011-11-29 14:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29 14:18 Ken D'Ambrosio [this message]
2011-11-29 16:37 ` Followup with dmesg WARNING (was Bug report: can't maintain WiFi connectivity in recent kernels.) Ken D'Ambrosio
2011-11-29 16:51 ` wwguy

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=a562bb7bd5c895756114c38e0de891de@www.jots.org \
    --to=ken@jots.org \
    --cc=linux-wireless@vger.kernel.org \
    /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