User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3 When stopping NetworkManager, either via popup menu of nm-applet or via rc-script, the system freezes just 2 sec later. Need to power cycle. Reproducible: Always Steps to Reproduce: 1. stop NetworkManager: "/etc/init.d/NetworkManager stop" 2. wait 2 sec. 3. system freezes, power cycle required
Freezes are kernel bugs. Can you provide the output of /sbin/lspci and /sbin/lsusb ? What exact kernel version is installed, and what brand/model of machine is this? For example, current kernels for F9 (2.6.26.6-79.fc9.i686) sometimes hang the machine when the ethernet cable is unplugged or when stopping NM.
Kernel is: # uname -r 2.6.26.6-79.fc9.i686 will attach PCI and USB device list.
Created attachment 322111 [details] PCI and USB Devices
exactly my configuration; do you have a Thinkpad T42 perhaps? in any case, this is a kernel bug with e1000 I'm pretty sure, since I sometimes get it when doing 'ifconfig eth0 down' when NM hasn't been running.
you're right, it's a T42p do you know if there's a workaround?
just upgraded to 2.6.27.5-37.fc9.i686 - but the problem persists. Meanwhile i use the e1000 driver v8.0.6 from http://sourceforge.net/projects/e1000 . This one works without hardlock.
jet another kernel update from fedora. with latest 2.6.27.5-41.fc9.i686 the kernel does not hardlock anymore when taking down eth0 (e.g. stopping NetworkMananger), but prints out a stack trace. I will attach dmesg output from both, before and after NM stop.
Created attachment 324167 [details] dmesg before taking down eth0
Created attachment 324168 [details] dmesg after taking down eth0
Upgraded to F10, but the problem still exists, even with recent F10 kernel update to 2.6.27.7-134.fc10.i686 Sometimes hardlock, sometimes kernel stack trace.
Still hardlocks in recent 2.6.27.9-159.fc10.i686
Still hardlocks in 2.6.27.19-170.2.35.fc10.i686 Are there any chances to get this fixed. The v8.0.6 driver from sourceforge.net works fine, but it's really annoying to replace the e1000 module every time the kernel package gets updated.
Happens to me with every download of a new kernel via yum on Fedora 10. Complete freeze following ifconfig eth0 down. The old 7.* driver is being shipped with the kernel so I updated to 8.0.9 from intel.com (8.0.6 appears to be the one shipped from the Sourceforge hosted project). I just re-make and install the e1000 driver with my latest kernel and the problem does not repeat until the next kernel update. I'll post here when the next one occurs. Current setup on an IBM Thinkpad T40 uname -srvmpio Linux 2.6.27.19-170.2.35.fc10.i686 #1 SMP Mon Feb 23 13:21:22 EST 2009 i686 i686 i386 GNU/Linux lspci 00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] 02:00.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) 02:00.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01) 02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) 02:02.0 Network controller: AIRONET Wireless Communications Cisco Aironet Wireless 802.11b lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 004: ID 046d:0840 Logitech, Inc. QuickCam Express Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Similar situation here on F10: ifdown of eth0 (using e1000) crashes the system (makes it unresponsive) or (with kernel option "noirqdebug") makes it unusable. It looks like my ethernet controller shares the same interrupt with the IDE controller (see attached output of lspci). Without any kernel options, upon disabling eth0 I get "Disabling IRQ#17" followed by a "irq17: nobody cared" and a stack trace; from that point on the system seems hosed (probably because of the rug pulled form under the IDE controller). With "irqpoll", upon disabling eth0 I get "Disabling IRQ#17", and everything hangs like before, but without the stack trace. With "noirqdebug", I can disable the interface (ifdown) and reenable it (ifup), but in between everything but very slow keyboard input misses characters. I am currently using kernel 2.6.27.21-170.2.56.fc10.i686, but the same was observed with 2.6.27.9-159.fc10.i686. The machine has an Athlon 64: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 4 model name : AMD Athlon(tm) 64 Processor 3400+ stepping : 10 cpu MHz : 1800.000 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow up bogomips : 3616.76 clflush size : 64 power management: ts fid vid ttp
Created attachment 338446 [details] Output of lspci -v
(In reply to comment #12) > Still hardlocks in 2.6.27.19-170.2.35.fc10.i686 > Are there any chances to get this fixed. The v8.0.6 driver from sourceforge.net > works fine, but it's really annoying to replace the e1000 module every time the > kernel package gets updated. Can anyone indicate if this fas been fixed in Fedora11? Are there any plans to fix it in Fedora11? Should this ticket be moved to Fedora11?
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.