Hide Forgot
Description of problem: updated from 2.6.22.1-27.fc7, after booting to the new kernel version, none of the network connections would acquire an address, I tried connecting it to a different router and even by wireless but the problem was only solve when booted to the old Kernel. while the problem was going on, the computer would halt at boot waiting for an IP address and would only boot when disconnected from the LAN. knetworkmanager would be able to detect the cable being disconnected and could even see the difference between a 100 and a 1000 based network. after a while, the wired interface would assign itself a 169.254.xxx.xxx address but no connectivity was gained. Version-Release number of selected component (if applicable): kernel version 2.6.22.1-33.fc7 How reproducible: Steps to Reproduce: 1. update system to kernel version 2.6.22.1-33.fc7 2. boot system using new kernel 3. Actual results: no connectivity Expected results: no connectivity Additional info: Motherboard: ASUS P5B Deluxe WIFI, running Fedora 7 32 Bit
I can confirm this, same thing happens to me on a Dell XPS M1210, both wireless (Intel 3945) and wired (Broadcom). Booting back to 2.6.22.1-27 makes the problem go away. Using tshark I can see the DHCPOFFER messages coming back into my interface, but somehow they get dropped/ignored. Also, when I manually assign an IP and set the default route, data transfers happen much slower than normally (around 65Kbit/s vs. the normal 10Mbit/s). "Something rotten in the state of Kernel" methinks. Cheers, Steven
I can confirm this too, I solved setting "allow users to enable this device" in system-config-network.
Mmmh, system-config-network offers me "allow ALL users to ...". I'm not sure I want to do that. Even so, it's a regression with respect to 2.6.22.1-27 and it does look like a bug to me. Also, when using this new kernel, my X session keeps giving me a warning that I was logged in for 0 seconds whenever I logout. Could well be a permission problem as well, but where is the difference with the previous kernel...?
Yeah, right, I've noticed that too... There are at least 3 regressions that could be somewhat related and were introduced by this kernel, the X bug (not sure someone has already filed that), the clock bug (250049) and this one. As for the network issue, maybe keeping -27 for now is the safest thing (I agree on multi-user machine is not really nice to allow everybody to control the devices), but for users that use NetworkManager (usually single user/family machines) this can be a good workaround if -33 is needed for some other reason.
There's a kernel mentioned in comment 13 of bug #249857 (250049 is a duplicate of that one) that fixes both that bug and this one for me. As for -33? Those bits have been de-gaused on my disk :-)
The latest kernel-2.6.22.1-41.fc7 solves the problem. Please reopen or create new bugreport if your problem persist. See bug #250003 for more info. *** This bug has been marked as a duplicate of 250003 ***