| Summary: | [iwl3945] WiFi device fails to resume after suspend | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andrey <aakolov> | ||||||||||
| Component: | kernel | Assignee: | Stanislaw Gruszka <sgruszka> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 15 | CC: | florian, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, sgruszka | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | i686 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2012-02-27 18:15:14 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Attachments: |
|
||||||||||||
|
Description
Andrey
2011-03-06 10:17:28 UTC
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. |