Bug 854069
Summary: | Computer freezes during Bootup when Wireless NIC is hardware-disabled | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Aram Agajanian <agajan> |
Component: | kernel | Assignee: | John Greene <jogreene> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | alex.g.muir, collura, danw, dcbw, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mlabarge, redhat, sgruszka |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-01-24 22:38:28 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Aram Agajanian
2012-09-03 22:07:40 UTC
My laptop will toggle a hardware enablement/disablement of the Wireless NIC when the Fn-F2 key combination is pressed. It turns out that starting the NetworkManager service will freeze my laptop if the Wireless NIC is hardware disabled. The NetworkManager service starts up normally if the Wireless NIC is hardware enabled. I have noticed that when I installed updates on September 1, I hadn't booted a new kernel since August 9 (kernel-3.4.4-5). So, this problem seems likely to be in kernel version 3.5. This is on BCM4313 wlan adapter. Aram, please install kernel-debug and try to reproduce the problem, does debug kernel print information showing reason of the freeze? Sorry about the delayed response. I have tested booting this computer with kernel-debug-3.6.7-4.fc17.x86_64. I don't see any new information displayed at the time of the freeze. I have noticed a change in behavior with current updates. Now, the startup of NetworkManager does not seem to cause the computer to freeze. In particular, starting NetworkManager after boot with the wireless NIC hardware-disabled doesn't cause the computer to freeze. The computer now freezes on boot whether the NetworkManager service is enabled or disabled. Fortunately, I can hardware-enable the wireless NIC during the boot process by pressing the Fn-F2 key combination. As long as it is enabled at the end of end of the boot process (when the mouse pointer first appears), the computer will boot. I did some additional testing of this freeze today (with the latest updates) and found the following: - If I boot to runlevel 1 with the wireless NIC hardware disabled, the computer doesn't freeze. - If I boot to runlevel 1 with the wireless NIC hardware disabled and then start the NetworkManager service, the computer will freeze. - If I do the following: = boot runlevel 5 with the wireless NIC hardware enabled = hardware disable the wireless NIC by pressing Fn-F2 = restart the NetworkManager service then the computer will not freeze. There is a possible fix for this in Linux 3.7. https://lkml.org/lkml/2012/11/18/128 *** Bug 872968 has been marked as a duplicate of this bug. *** Seems the patch queued for 3.7 was never submitted to stable. F17 will be moving to 3.7 within the next 2 weeks or so. I'll see how difficult a backport would be in the meantime. *** Bug 877545 has been marked as a duplicate of this bug. *** *** Bug 883476 has been marked as a duplicate of this bug. *** kernel-3.7.3-101.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/FEDORA-2013-1025/kernel-3.7.3-101.fc17 I installed F18 on my laptop over the weekend. The kernel currently installed is 3.7.2-201.fc18. There is no problem booting with the wireless NIC hardware-disabled. kernel-3.7.3-101.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. Upgrading to the 3.7 series kernel from F17 fixes my equivalent bug (877545 marked duplicate above) here, very satisfying to see this working at least before I have to hand the laptop back. Thanks to Aram for figuring out what the exact problem was and spotting the relevant patch going into Linux. |