Red Hat Bugzilla – Bug 433296
NetworkManager freezes my system upon login
Last modified: 2008-08-23 23:42:38 EDT
Description of problem: Often, when I login to my laptop and NetworkManager tries to connect to a WEP-enabled wireless network, my system will totally freeze with blinking lights on the laptop. This only happens with WEP networks--if NetworkManager automatically connects to WPA or open networks on login, my system doesn't freeze. If I shutdown NetworkManager before logging in and then start it after my login has completed, then my system won't freeze. I have a Thinkpad T60 with Intel's 3945 wireless. Version-Release number of selected component (if applicable): NetworkManager-0.7.0-0.6.7.svn3235.fc8 How reproducible: Often Steps to Reproduce: 1. Set NetworkManager to associate with a WEP-enabled network and start at login 2. login 3. Actual results: system freezes Expected results: system works Additional info:
i386 or x86_64? I am currently using a T60 x86_64 with iwl3945 wireless connected to a WEP network with the same version of NetworkManager. "blinking lights" like a kernel panic? This might point toward a kernel bug. Do you have any kernel modules loaded that don't ship as part of Fedora's kernel?
Yes, blinking lights like a kernel panic--my caps lock and other status lights blink. I am running kernel-2.6.23.15-137.fc8. The only thing non-standard is the Cisco VPN Client. I'm using i386.
I tried disabling the Cisco VPN Client, but my system is still freezing upon login unless I disable NetworkManager.
Hmm; any chance you can quick switch to a VT and see the panic message?
I am not able to switch to a VT. Also, I am seeing different issues on a WPA network--I keep losing my network connection. And, when using VPNC, I keep dropping my VPN connection. When switching to RHEL 5, I have no issues on WPA.
Definitely sounds like kernel issues. I've had issues before with a few drivers disabling interrupts for too long, leaving the keyboard in an unresponsive state (mouse still works though). Might be what you're seeing here. We might be able to reproduce the issue without logging in if you can set up a WEP access point, then a new wireless connection through system-config-network, and then we can get the nm-system-settings service to provide that connection to NM before login, which might trigger the panic. Since s-c-n (really the ifcfg-* files) doesn't support WPA yet, we can't try with WPA though. Any chance you have a spare AP around?
These are the final messages before my crash (Fedora Core 9, 2.6.25.6-55.fc9.i686) Jun 18 02:55:49 sukrulaptop kernel: b43-phy1: Broadcom 4318 WLAN found Jun 18 02:55:49 sukrulaptop kernel: Broadcom 43xx driver loaded [ Features: PMLR, Firmware-ID: FW13 ] Jun 18 02:55:49 sukrulaptop NetworkManager: <info> wlan0: Device is fully-supported using driver 'b43-pci-bridge'. Jun 18 02:55:49 sukrulaptop NetworkManager: <info> wlan0: driver supports SSID scans (scan_capa 0x01). Jun 18 02:55:49 sukrulaptop NetworkManager: <info> Found new wireless (802.11) device 'wlan0'. Jun 18 02:55:49 sukrulaptop NetworkManager: <info> (wlan0): exported as /org/freedesktop/Hal/devices/net_00_14_a5_89_04_44_0 Jun 18 02:56:52 sukrulaptop kernel: imklog 3.14.1, log source = /proc/kmsg started. I don't know if this helps, but reverting to 2.6.25.4-30.fc9.i686 works perfectly.
I previously marked this as assigned - but realized the last comment wasn't providing the information requested. Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.