Bug 737424 - After resume from suspend wifi does not connect
Summary: After resume from suspend wifi does not connect
Alias: None
Product: Fedora
Classification: Fedora
Component: iwl1000-firmware
Version: 16
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-12 01:00 UTC by gene smith
Modified: 2012-01-09 19:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-01-09 19:03:24 UTC

Attachments (Terms of Use)
/var/log/messages from where sleep begins until red X appears after resume (18.46 KB, text/plain)
2011-09-12 01:00 UTC, gene smith
no flags Details

Description gene smith 2011-09-12 01:00:30 UTC
Created attachment 522638 [details]
/var/log/messages from where sleep begins until red X appears after resume

Description of problem:
Wifi works fine on system after boot-up. After system suspend (select it with software or close laptop lid) all comes back OK but wifi never connects. In KDE, icon in tray indicates "configuring network" for a while then indicates "waiting for authorization". Eventually a "key" icon appears over the normal wireless icon and after a few minutes a red X appears. In gnome, which I run less often, a dialog pops up with my WEP key filled in correctly. If I click OK the dialog comes back after a few seconds. After doing this a few times it too indicates that the wireless connection is not possible.

Version-Release number of selected component (if applicable):
Wireless hardware:
Sep  6 00:10:04 nhpl kernel: [ 9767.128618] iwlagn 0000:0d:00.0: Detected Intel(R) Centrino(R) Wireless-N 1000 BGN, REV=0x6C

Sep  6 00:10:04 nhpl kernel: [ 9767.152465] iwlagn 0000:0d:00.0: loaded firmware version build 35138

Linux nhpl #1 SMP Tue Aug 30 14:38:32 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

How reproducible:

Steps to Reproduce:
1. All running well (KDE).  Close laptop lid
2. Allow laptop to suspend
3. Open lid
4. Enter password
5. Laptop resumes OK but wifi tries to connect for several minutes
6. Eventually gives up and red X appears instead of wifi icon 
Actual results:
All seems OK after resume except wifi will not connect. Must do a re-boot for wife to come back.

Expected results:
Wifi should quickly reconnect after resume.

Additional info:
After resume, can plug in Ethernet and it connects and works fine.
Laptop is new HP Pavilion dv7-6195us
Message in log when wifi connection attempts fail seems to be related to authentication of the secret key as indicated by this message:
Sep 11 19:58:52 nphl NetworkManager[853]: <info> (wlan0): device state change: need-auth -> failed (reason 'no-secrets') [60 120 7]

Comment 1 gene smith 2011-10-19 03:23:06 UTC
Am now also running (K)ubuntu 11.04 on the laptop which has no problem with wifi resuming after suspend. 
Several updates, including the kernel, have occurred on F15 over the last 1+ month since reporting this bug and same problem exists.

Comment 2 gene smith 2011-10-26 04:01:14 UTC
Note: After upgrade to (K)ubuntu 11.10 on the same laptop, the same bug now occurs there. It seems to be purely kernel related. When booting 11.10 with the previous 11.04 kernel, 4.6.38, instead of new, 3.0.0, wifi resumes OK. Also Ubuntu launchpad support had me try new kernel 3.1-rc10 and it did not help the problem.
See bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/880648

Comment 3 gene smith 2011-12-15 04:06:57 UTC
Same problem occurs on f16.

However fix for issue described in this lkml thread:

Specific fix presented  here (from wwguy):

I created a new file called iwlagn.conf under /etc/modprobe.d containing a single line that causes the bt (bluetooth I assume) coexistence flag to be set false at startup in the iwlagn kernel module:

options iwlagn bt_coex_active=N

My laptop does not have bluetooth capability so possibly having this flag on, which is default, causes problems.

I don't know is this an ultimate fix or just a temporary workaround, but it definitely fixes the problem for me. Now wifi resumes after wake from sleep.

Comment 4 gene smith 2012-01-01 23:18:37 UTC
Unfortunately the latest f16 kernel, 3.1.6-1.fc16.x86_64, renders this fix ineffective and again cannot resume wifi after a sleep and must reboot.
Therefore must stay with older kernels for this to work and for wifi to resume after sleep:
3.1.5-6 is still OK
3.1.5-2 is still OK.

Comment 5 John W. Linville 2012-01-06 19:41:25 UTC
Wey-yi, the kernel that breaks here is the first one to include the compat-wireless-3.2-rc6 snapshot.  Any idea why this code would break the bt_coex_active=0 work-around?

Comment 6 wey-yi.w.guy 2012-01-06 20:10:33 UTC

don't see any reason why bt_coex_active will not works.

Please set the debug flag to 0x01:
sudo modprobe iwlwifi debug=0x01

it should tell us is BT coex disable or active.


Comment 7 gene smith 2012-01-07 05:23:22 UTC
With latest f16 kernel 3.1.6-1.fc16.x86_64 the module iwlagn no longer exists and seems to be replace with iwlwifi. Since I was setting the bt_coex_active parameter using the /etc/modprobe.d/iwlagn.conf file, it was not being set for the new iwlwifi. So adding a iwlwifi.conf file containing this fixed the problem:

options iwlwifi bt_coex_active=0

Now can resume after sleep again with the latest f16 kernel. 

By the way, I can use the "debug=0x01" parameter with iwlagn module with the previous kernel. But I get an error when I try to use the debug parameter with iwlwifi with the latest kernel. "modinfo iwlwifi" also does not list a "debug" parameter.

Comment 8 wey-yi.w.guy 2012-01-08 22:58:02 UTC
did you compile with CONFIG_IWLWIFI_DEBUG enabled?


Comment 9 gene smith 2012-01-09 06:30:07 UTC
I didn't compile the module (or kernel). It is the stock module (and kernel) from fedora 16 updates now at 3.1.7-1.fc16.x86_64.


Comment 10 wey-yi.w.guy 2012-01-09 06:39:22 UTC
I am not familiar with stock fedora, but my guess is CONFIG_IWLWIFI_DEBUG is not enabled by default.


Comment 11 John W. Linville 2012-01-09 19:03:24 UTC
Closing on the basis of comment 7...the "debug=" thing is a side issue, and not really relevant here.

Note You need to log in before you can comment on or make changes to this bug.