Since a few days (the 4th of march), my ethernet card is not working anymore My card is a Broadcom one (extract from lspcidrake ) : e1000e : Intel Corporation|82567LM Gigabit Network Connection [NETWORK_ETHERNET] (rev: 03) In /var/log/messages, I have plenty of lines like : Mar 6 09:55:31 bleuet kernel: ehci_hcd 0000:00:1a.7: PCI INT C disabled Mar 6 09:55:31 bleuet kernel: ehci_hcd 0000:00:1d.7: BAR 0: set to [mem 0xfed1c000-0xfed1c3ff] (PCI address [0xfed1c000-0xfed1c3ff]) Mar 6 09:55:31 bleuet kernel: ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20 Mar 6 09:55:31 bleuet kernel: ehci_hcd 0000:00:1d.7: PCI INT A disabled Mar 6 09:55:31 bleuet kernel: ehci_hcd 0000:00:1a.7: BAR 0: set to [mem 0xfed1c400-0xfed1c7ff] (PCI address [0xfed1c400-0xfed1c7ff]) Mar 6 09:55:31 bleuet kernel: ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 22 (level, low) -> IRQ 22 Mar 6 09:55:31 bleuet kernel: ehci_hcd 0000:00:1a.7: PCI INT C disabled Mar 6 09:55:32 bleuet kernel: ehci_hcd 0000:00:1d.7: BAR 0: set to [mem 0xfed1c000-0xfed1c3ff] (PCI address [0xfed1c000-0xfed1c3ff]) Mar 6 09:55:32 bleuet kernel: ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20 Mar 6 09:55:32 bleuet kernel: ehci_hcd 0000:00:1d.7: PCI INT A disabled Mar 6 09:55:32 bleuet kernel: ehci_hcd 0000:00:1a.7: BAR 0: set to [mem 0xfed1c400-0xfed1c7ff] (PCI address [0xfed1c400-0xfed1c7ff]) Mar 6 09:55:32 bleuet kernel: ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 22 (level, low) -> IRQ 22 Mar 6 09:55:32 bleuet kernel: ehci_hcd 0000:00:1a.7: PCI INT C disabled I have try to unload the kernel module, it stop the log filing but, of course, no chance the card work without it. Removing lines in /etc/udev/rules.d/70-persistent-net.rules had solve the problem one time but, at reboot, it fails again Please ask if you need more trace, more information (eth work on windows, so it's not an hardware problem) Reproducible: Steps to Reproduce:
CC: (none) => marianne
CC: (none) => thierry.vignaudSource RPM: (none) => udev
does rmmod/modprobe works? Could you __attach__ (not paste) your whole dmesg?
Assignee: bugsquad => dmorganec
which lines did you removed in /etc/udev/rules.d/70-persistent-net.rules ? can you please test with udev 166 ?
Created attachment 130 [details] dmesg outup Dmesg output as asked
I remove all lines who were not commentary in /etc/udev/rules.d/70-persistent-net.rules rmmod / modprode the module used by the ethernet card is not working I'm actually using udev 165 but I will test with the 166 [jehane@bleuet ~]$ rpm -qa | grep udev lib64gudev1.0_0-165-1.mga1 udev-165-1.mga1 lib64udev0-165-1.mga1
Problem is the same with udev 166 [jehane@bleuet ~]$ rpm -qa | grep udev lib64udev0-166-1.mga1 lib64gudev1.0_0-166-1.mga1 udev-166-1.mga1 Did you need dmesg output ?
as root can you do : udevadm control --log-priority=debug and then attach the logs from /var/log/syslog from udev when doing for ex a service network restart thanks. if you do not remove the udev rule file and do rmmod / modprode what happens ?
A rmmod / modprode has no effect.
Created attachment 156 [details] /var/log/messages extract Here is an extract for the /var/log/messages after running the udevadm command and doing restart of the network service
I have the same issue on my laptop (same ethernet card): e1000e : Intel Corporation|82567LM Gigabit Network Connection [NETWORK_ETHERNET] (rev: 03) The problem for me is: - no paquets are sent or received (according ifconfig and tcpdump) - ethtool is unable to locate the interface (like it doesn't exists but ifconfig show it) - rmmod/modprobe e1000e does nothing, only reboot seems to fix But: - card works fine when booting at init 1 - card stop to work at init 5 - in init 1, starting haldaemon make the interface stop to work But disabling haldaemon with chkconfig allow me to reach init 5, starting haldaemon after didn't make the interface stop to work. Hope this help.
CC: (none) => nanardon
Same problem for me. If I disabled ACPI and start at level 1, I can turn on the ethernet card but as soon as haldeamon is startded it crach.
CC: (none) => saveurlinux
Priority: Normal => release_blocker
According to testing I am doing with Olivier, it seems to be related to acpid, disabling it solved the issue. So now, we need to find interaction between them.
CC: (none) => misc
After test, in my case the issue come from laptop-mode-tools. Removing the package fixes all issue about e1000e card not working anymore (eg when any acpi event occurs or when pm-suspend is called). I was unable to reproduce by calling laptop-mode script by hand.
Summary: eth0 not working anymore => eth0 not working anymore (e100e vs laptop-mode-tools)
Any new imput on that subject?
CC: (none) => ennael1, tmb
Same behaviour than Olivier. Removing laptop-mode-tools make my ethernet card work again
AFAICS, pm-utils and laptop-mode-utils should definitely conflict: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614024 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612710 they can be installed at the same time, i.e. there's no file conflict, but their functionalities overlap.
Assignee: dmorganec => bugsquadSource RPM: udev => laptop-mode-utils
OK, pm-utils now conflicts with laptop-mode-tools, according to upstream: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612710#59
Status: NEW => RESOLVEDResolution: (none) => FIXED
I've the same problem, after an upgrade from mandriva 2010.2. pm-utils now conflicts with laptop-mode-tools so I removed laptop-mode-tools, but it doesn't wolve the issue.
CC: (none) => olivier
So the problem is different, please open a new bug report.
Yes, already done in bug 1742.