Description of problem: I have Sony laptop (Smolt profile here: http://www.smolts.org/client/show/pub_05498d62-bc87-4c2d-9639-7de896fa8f3f ). Before I was using F12, but recently made a clean reinstall and changed to F14. What I have found is that after waking up from a suspend mode, wifi device is turned off and can not be switched on. GNOME NetworkManager applet shows it as disabled and Gnome applet is not allowing to enable it. I am not sure if that is caused by some kernel module or by NetworkManager. There is no such problem with hibernate. The problem happens almost everytime but in some rare cases wifi device is resuming properly, unfortunately, I have not yet found the rule. I have checked the logs. wpa_supplicant log contains a lot of records ´Failed to initiate AP scan´. Version-Release number of selected component (if applicable): 2.6.35.11-83.fc14.i686 #1 SMP Mon Feb 7 07:04:18 UTC 2011 i686 i686 i386 GNU/Linux How reproducible: While in Gnome session, put the laptop in suspend mode (either by closing lid or through system menu in Gnome). Wait some time, switch the laptop back on. NetwokManager applet is not even trying to find the home wifi network. Apllet shows Wifi is disabled. ifconfig shows there are no active network interfaces available (only lo in output, even Ethernet is not shown). Network applet is not able to enable wifi device, no matter what I tried. Steps to Reproduce: Actual results: Wifi device is disabled and can´t be enabled by standard Gnome network applet. Expected results: Normal resume of the wifi device after suspend and connection to the network. Additional info:
In addition: the case looks very similar to these 2 bugs: https://bugzilla.redhat.com/show_bug.cgi?id=628088 https://bugzilla.redhat.com/show_bug.cgi?id=632910
More info: messages log contains records records like follows after the fail: Mar 6 21:05:39 fz11mr kernel: [ 8005.158210] iwl3945 0000:06:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF Mar 6 21:05:39 fz11mr kernel: [ 8005.179062] iwl3945 0000:06:00.0: BSM uCode verification failed at addr 0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020 Mar 6 21:05:39 fz11mr kernel: [ 8005.179066] iwl3945 0000:06:00.0: Unable to set up bootstrap uCode: -5 Mar 6 21:05:39 fz11mr kernel: [ 8005.180055] iwl3945 0000:06:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
You can try workaround this problem by reloading modules at suspend/resume $ echo 'SUSPEND_MODULES="iwl3945 iwlcore"' > /etc/pm/config.d/iwlwifi but I'm not sure if that would work. Since this is F12->F14 regression, perhaps you could install upstream kernel from git tree and perform bisection?
Vážený pane Stanislaw, I am honestly speaking not the most advanced Fedora user ;( I will be glad to follow your advice if you could tutor me a while. Is that possible ?
Regarding workaround, is enough to create /etc/pm/config.d/iwlwifi file as described above. Do suspend/resume and check if that works, dmesg should show you if driver was unloaded during suspend and loaded during resume. Removing file will remove workaround. Regarding bisection, that is kinda hard. I wrote some description here: https://bugzilla.redhat.com/show_bug.cgi?id=640612#c37 Is bug 100% reproducible, i.e happens all the time you suspend?
Will try to follow the recipes in weekend and report. The bug is not reproducible, sometimes it happens, sometimes not. I was not able to find any obvious dependency. The only thing I am sure it doesn't happen when I recover from hibernation (suspend-to-disk).
In case problem is not reproducible, bisection would be rather hard, because you have to compile kernel, then mark it as good or bad. Since problem happens randomly, telling if kernel have bug or not would be problematic. I plan to revert bunch of iwl 3945 changes that was made in 2.6.35, because they are know to cause many troubles, and actually are not needed. Perhaps such revert, will also help in that case. Reverting will take some time thought. On the meanwhile please attach full dmesg output when problem happens, of course you could also try to bisect.
Created attachment 489480 [details] Screenshot 1
Created attachment 489481 [details] Screenshot 2
Created attachment 489482 [details] dmesg log
Created attachment 489483 [details] wpa supplicant log
My attempt to build the vanilla kernel was not successful. Everything was good until I did ´make modules_install´. The output is: $ make modules_install mkdir: cannot create directory `/lib/modules/2.6.39-rc1+': Permission denied make: *** [_modinst_] Error 1 I also have found a page in the Fedora wiki: https://fedoraproject.org/wiki/Building_a_custom_kernel Instruction there is more complicated than yours but I wonder why not follow it ?
You need root permissions to install kernel modules and kernel, try $ su -c 'make modules_install' $ su -c 'make install' I just remember myself that we change suspend/resume operations on iwlwifi to use generic pci code. There is a chance that commit: commit f60dc0138aa19769bf8bab9f93b043235428b66f Author: John W. Linville <linville> Date: Mon Oct 25 16:12:37 2010 -0400 iwlwifi: Convert to new PCI PM framework fix this bug. So installing current upstream kernel is good decision. If you fail with unstable 2.6.39-rc1, you can try 2.6.38 which contains above commit.
Hi, I'm having the exact same problem on Laptop running Fedora 15 beta. Have you been able to fix it, Andrey?
The Problem still persits with the latest Kernel (2.6.40-4.fc15.i686). I tried to restart the NetworkManager, because I read similar bug reports where this helped, but I doesnt help for me. Is there going to be a fix, or are there too few people affected. I would hate to reinstall my System.
Did you try workaround from comment 3 ?
Florian, do you have also this? "iwl3945 0000:06:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF" This mean that device is probably detached from pcie bus. Again since this is regression the best way to fix this problem would be perform bisection, but that's kinda hard. I'm not able to reproduce this problem, so could not bisect by my own. You may try pcie_aspm=off or pcie_apsm=force kernel boot parameters and see if that helps. If not I'll ask you for verbose debug logs.
Florian, Stanislaw, sorry for not answering so long. So, I have fresh installed (not upgraded from F14 but installed) F15 on this laptop now and... the problem is still here. And yes, I have this magic 'MAC is in deep sleep!' message in logs.
We had quite similar problem upstream: https://lkml.org/lkml/2011/12/27/65 At the end of the day, we find out that it was PCI subsystem problem, which does not enable PCI bridge. That give some new opportunity for searching where the problem is. Can you provide output of "lspci -tnnv" so I could see the PCI topology in your system?
The problem Stanislaw mentions in comment #19 should have been fixed in 3.2-rc7. F15 is on 3.2.7 now, so it should contain the fix. I'm going to close this report out. If you are still seeing this issue, please reopen.