Created attachment 26028 [details] dmesg_wifi_output After reboot everything is back in normal, but this shouldn't happend.
I forgot some information: Laptop MSI GX620X-061CZ with Intel Intel Wireless 5100. Installed 64 bit Gentoo. A top of kernel is only circa 2 Nouveau upstream patches, which not interact with this issue. Laptop was cca six times suspended before this issue appeared.
What kernel version are you using?
2.6.34-rc4 from git (from 15.4.2010)
(In reply to comment #0) > Created an attachment (id=26028) [details] > dmesg_wifi_output > > After reboot everything is back in normal, but this shouldn't happend. (Ignoring that warning for a moment and focusing on the problems before it) I see the following from the logs after the last resume: [18801.803589] wlan0: associate with 00:1c:10:b8:e6:18 (try 1) [18801.806040] wlan0: RX AssocResp from 00:1c:10:b8:e6:18 (capab=0x401 status=0 aid=2) [18801.806043] wlan0: associated Association successful. Looks good so far. [18823.950266] [drm] nouveau 0000:08:00.0: Allocating FIFO number 2 [18823.955952] [drm] nouveau 0000:08:00.0: nouveau_channel_alloc: initialised FIFO 2 [18823.974037] [drm] nouveau 0000:08:00.0: Allocating FIFO number 3 [18823.979681] [drm] nouveau 0000:08:00.0: nouveau_channel_alloc: initialised FIFO 3 [18874.204086] No probe response from AP 00:1c:10:b8:e6:18 after 500ms, disconnecting. Unable to receive data from AP, so disconnecting. [18874.208577] cfg80211: Calling CRDA to update world regulatory domain [18952.831869] wlan0: authenticate with 00:1c:10:b8:e6:18 (try 1) [18953.031085] wlan0: authenticate with 00:1c:10:b8:e6:18 (try 2) [18953.231024] wlan0: authenticate with 00:1c:10:b8:e6:18 (try 3) [18953.432026] wlan0: authentication with 00:1c:10:b8:e6:18 timed out Unable to connect to same AP again. [18967.466320] wlan0: authenticate with 00:1c:10:b8:e3:ea (try 1) [18967.469098] wlan0: authenticated [18967.472527] wlan0: associate with 00:1c:10:b8:e3:ea (try 1) [18967.472585] wlan0: deauthenticating from 00:1c:10:b8:e3:ea by local choice (reason=3) Started to associate to a different AP, but userspace told it to disconnect. What are you using to configure your wireless? Is it possible to check its logs why it is requesting a disconnect here? I think ideal will be if you run wpa_supplicant directly without networkmanager or wicd or what you are using ... with a "-dddt" command line parameter. [18967.672057] wlan0: associate with 00:1c:10:b8:e3:ea (try 2) [18967.872357] wlan0: associate with 00:1c:10:b8:e3:ea (try 3) [18968.072960] wlan0: association with 00:1c:10:b8:e3:ea timed out This association should really not proceed here ... and is probably why the warning appears. Perhaps somebody familiar with mac80211 can take a look at this part. [18968.076890] ------------[ cut here ]------------ [18968.076898] WARNING: at net/wireless/mlme.c:341 cfg80211_send_assoc_timeout+0xa8/0x140() [18968.076900] Hardware name: GX628······ [18968.076924] Pid: 1408, comm: phy0 Not tainted 2.6.34-rc4-00082-g250541f-dirty #3 [18968.076926] Call Trace: [18968.076931] [<ffffffff8103459e>] ? warn_slowpath_common+0x6e/0xb0 [18968.076934] [<ffffffff8157c2d8>] ? cfg80211_send_assoc_timeout+0xa8/0x140 [18968.076937] [<ffffffff8103ff8b>] ? mod_timer+0x10b/0x180 [18968.076940] [<ffffffff8158f0fc>] ? ieee80211_assoc_done+0xbc/0xc0 [18968.076943] [<ffffffff81590d53>] ? ieee80211_work_work+0x553/0x11c0 [18968.076945] [<ffffffff8102d931>] ? finish_task_switch+0x41/0xb0 [18968.076948] [<ffffffff81590800>] ? ieee80211_work_work+0x0/0x11c0 [18968.076951] [<ffffffff810476fb>] ? worker_thread+0x13b/0x210 [18968.076954] [<ffffffff8104b6b0>] ? autoremove_wake_function+0x0/0x30 [18968.076956] [<ffffffff810475c0>] ? worker_thread+0x0/0x210 [18968.076959] [<ffffffff8104b21e>] ? kthread+0x8e/0xa0 [18968.076962] [<ffffffff810031f4>] ? kernel_thread_helper+0x4/0x10 [18968.076964] [<ffffffff8104b190>] ? kthread+0x0/0xa0 [18968.076966] [<ffffffff810031f0>] ? kernel_thread_helper+0x0/0x10 [18968.076968] ---[ end trace 8aa6265f4b1adfe0 ]---
Created attachment 26073 [details] wifi_connect.sh I think I used that script after suspend.
(In reply to comment #5) > Created an attachment (id=26073) [details] > wifi_connect.sh > > I think I used that script after suspend. I assume you mean resume. If I understand correctly this script explains the first successful association (to 00:1c:10:b8:e6:18) since the communication is lost with this AP more than a minute after association. "Something" initiated a new association attempt with this AP ... did you run this script again? ... and then during this second association attempt "something" requested a disconnect. Are you running any other wireless management applications? Maybe wpa_supplicant or network manager or ... that could explain this?
it's possible I used CTRL-C and run it again (WiFi had low signal or something). I don't have wpa_supplicant or NM installed.
Interesting script ... why not use wpa_supplicant instead?
Created attachment 26101 [details] Do not continue assoc process after deauth From your logs I see two things going on: - the userspace you are using is triggering deauthentications for some reason, which does not seem to be what you want. To address this I would like to propose that you use something like wpa_supplicant as a userspace app - since it is requested deauth so frequently it exposed a race inside the kernel which should be addressed by attached patch. This will take care of the warning you see at the end of your log.
(In reply to comment #9) > Created an attachment (id=26101) [details] > Do not continue assoc process after deauth > > From your logs I see two things going on: > > - the userspace you are using is triggering deauthentications for some > reason, > which does not seem to be what you want. To address this I would like to > propose that you use something like wpa_supplicant as a userspace app > > - since it is requested deauth so frequently it exposed a race inside the > kernel which should be addressed by attached patch. This will take care of > the > warning you see at the end of your log. Any luck trying out this patch? It seems to be a real issue for which I'd like to push this patch upstream if it resolves the issue.
I'm afraid I wasn't able reproduce it again. If you want, I can just test it.
(In reply to comment #11) > I'm afraid I wasn't able reproduce it again. If you want, I can just test it. Sure - any testing will be welcome. I submitted the patch upstream for consideration so hopefully this will cover future encounters with this problem. Since you are not able to reproduce the issue, please close this bug ("Resolved Unreproducible". You can always open a new bug if you encounter an issue again.
See bug #15981 Problem not necesary with suspend. For my "Warning" with not connect to ESSDI
In #15981 ... notice the preceding events that lead up to the warning, they are different from this bug. I thus do not believe it is a duplicate and debugging should rather be restricted to #15981.
(In reply to comment #12) > (In reply to comment #11) > > I'm afraid I wasn't able reproduce it again. If you want, I can just test > it. > > Sure - any testing will be welcome. > > I submitted the patch upstream for consideration so hopefully this will cover > future encounters with this problem. > > Since you are not able to reproduce the issue, please close this bug > ("Resolved > Unreproducible". You can always open a new bug if you encounter an issue > again. Seems like this issue has not been reproducible for a while now. Even so, we are confident that the patch sent upstream does address the error you encountered.