Red Hat Bugzilla – Bug 469399
[e1000] ifconfig down sometimes hardlocks
Last modified: 2009-12-18 01:42:50 EST
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:18.104.22.168) 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.
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 (22.214.171.124-79.fc9.i686) sometimes hang the machine when the ethernet cable is unplugged or when stopping NM.
# uname -r
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 126.96.36.199-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 188.8.131.52-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 184.108.40.206-134.fc10.i686
Sometimes hardlock, sometimes kernel stack trace.
Still hardlocks in recent 220.127.116.11-159.fc10.i686
Still hardlocks in 18.104.22.168-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
Linux 22.214.171.124-170.2.35.fc10.i686 #1 SMP Mon Feb 23 13:21:22 EST 2009 i686 i686 i386 GNU/Linux
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
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 126.96.36.199-170.2.56.fc10.i686, but the same was observed with 188.8.131.52-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 184.108.40.206-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:
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.