Red Hat Bugzilla – Bug 436680
Boot crashes bringing up rt61 wireless interface after upgrading to kernel 18.104.22.168-12
Last modified: 2008-03-14 10:01:44 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124) Gecko/20080208 Fedora/126.96.36.199-1.fc8 Firefox/188.8.131.52
Description of problem:
After upgrading from kernel-184.108.40.206-12.fc8 to kernel-220.127.116.11-137.fc8 and rebooting, wireless did not work. I re-configured the wireless adapter using system-config-network. Now the boot stalls / crashes at the line "Bringing up interface wlan0"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Upgrade from kernel-18.104.22.168-12.fc8 to kernel-22.214.171.124-137.fc8
2. Reboot -- wireless does not work at all
3. Use system-config-network to re-configure wireless adapter
5. Boot stalls at "Bringing up interface wlan0"
Machine will not boot -- stalls at "Bringing up interface wlan0"
Boot should have proceeded, interface should have come up and then obtained an address through dhclient. (Still works reliably under kernel-126.96.36.199-137.fc8).
May have something to do with setting Mode=Managed for the wireless card; on some reboots, the machine stalls after "Error for wireless request "Set Mode" (8B06) :"
Confirm this can be worked-around by downloading, building & installing a more
up-to-date version of the rt2x00 wireless modules (I used the
rt2x00-cvs-2008030906 snapshot). Download from rt2x00.serialmonkey.com. Could
updated rt2x00 wireless module be included in the next kernel update? Thanks,
The kernels here contain an update to rt2x00 version 2.1.4:
Could you give those kernels a try to see if they resolve this issue for you?
Thanks. I confirm updating to 188.8.131.52-34.fc8 resolves this problem for me.
Note: I do see the following during boot (which I had not seen before):
"Bringing up interface wlan0: Error for wireless request "Set Encode" (8B2A):
SET failed on device wlan0; No such file or directory."
This seems like an unrelated problem though, and doesn't seem to affect the
operation of wlan0, which now works fine.