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):
Steps to Reproduce:
1. Set NetworkManager to associate with a WEP-enabled network and start at login
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-22.214.171.124-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, 126.96.36.199-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)
Jun 18 02:55:49 sukrulaptop NetworkManager: <info> (wlan0): exported as
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 188.8.131.52-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.