Red Hat Bugzilla – Bug 125839
(ACPI) Eth0 won't activate using forcedeth driver
Last modified: 2007-11-30 17:10:44 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
I cannot get the NVidia forcedeth driver (the later nForce2
chipset...see below) to activate under 2.6.6-1.427 using my router's
dhcp server. Eth0 won't come up and the network is unusable. This
driver activates normally under 2.6.5-1.358 and the same dhcp server.
Assigning a static address of 192.168.2.10 allows the driver to come
up but it will not access any external addresses including accessing
the router nor will it access anything through the router's gateway
address of 192.168.2.1.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.boot FC2 using 2.6.6-1.427 kernel with nothing other than std
parameters minus rhgb and quiet which have been removed
2.note that bringing up eth0 fails
Actual Results: Network is non-functional
Expected Results: functional network
Everything works fine under 2.6.5-1.358.
NOTE: I am a little at a loss about where this bug really should be
filed. The error is on a MSI K7N2 Delta ILSR motherboard which uses
the later nForce2 chipset (Vendor ID 10de Deviceid 0066 SubVendorId
1462 subDeviceID 570c). I have an Epox 8RDA+ (earlier nForce2 chipset
same Vendor and Device Ids subVendorID 1695 subDeviceId 1000) that is
running 2.6.6-1.427 connected to the same router that is functioning
just fine. Cables have been switched to verify that it isn't a
cabling problem. BIOS assigns a bogus MAC to the interface...changing
it to some random valid value didn't help at all. Both systems have
been updated from Core and Released Updates only...ie no Rawhide.
Doing nothing other than booting .358 causes the problem to go away on
the MSI system. The problem does *not* exist on the Epox system with
.427 or .358. The forcedeth driver had been working fine on both
systems since FC2T1.
I'm having the same problem... on the "Nforce Ultra 2" 400 MHz FSB
hardware. I'm not using the built in ethernet port at all... I've got
a tg3 based 10/100 PCI card that works perfectly under 2.6.6-1.358 but
just stops working under 2.6.6-1.427. When it isn't working, I see
the tg3 module loaded in memory, I see an IP address assigned, but no
actual traffic (even tcpdump -n shows that it isn't seeing anything).
Same here with forcedeth driver and nvidia mobo.
Seeing same issue on an MSI K7N2 Delta-L mobo with NForce2 chipset
under 2.6.6-227. Everything runs fine under 2.6.5-1.358. However,
Determining IP information for eth0...PING xx.xx.xxx.x (xx.xx.xxx.x)
56(84) bytes of data.
--- xx.xx.xxx.x ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time
1999ms, pipe 4 failed.
(IP addy concealed for privacy reasons)
Then it dies. IP addy info is detected under 2.6.5-1.358, otherwise
network is not contactable under .427
I have similar problem with an ASUS A7N8X-E Deluxe.
Things worked with 2.6.5-1.358 and stopped working with 2.6.6-1.427.
Just tried .435...no changes here...works on NForce 2, doesn't on
NForce2 Ultra chipset. Ping message mentioned above wasn't seen this
time though. When trying to connect to the Internet, all that is seen
with Ethereal are outgoing ARP requests. There is nothing related in
the logs. When loading kernel, the message said Eth0 loaded OK but
the NTP server connection failed shortly thereafter.
Same thing occurs on an Aslab marquis k118, which has an ASUS A7N8X.
Created attachment 101234 [details]
output from the dmesg showing forcedeth not handling irq11
Attached is dmesg output from 2.6.7-1.437 where it not working. An ifconfig as
well states the IRQ is 11 and the dmesg complains that noone cared about an
interrupt on IRQ 11.
Sorry for the 2nd post -- I didn't think of this before posting the
above, but 2 more pieces of info: Its broken as far back as
2.6.6-1.368 -- I just tried that. Also forcedeth works in 437 with
Probably ACPI not forcedeth breakage
using acpi=off doesn't make any difference on this system with either
.435 or .437...network interface still doesn't work.
Created attachment 101321 [details]
dmesg from 441
ACPI output was more verbose, so I thought it might help
Created attachment 101368 [details]
dmsg of 448 with onboard usb disabled and a working forcedeth
After seeing question from
about a certain ehci-hcd patch being applied or not, it seems to me this is
really the same bug as
at least for me. In my config both usb (ehci_hcd) and eth0 (forcedeth) were
using IRQ #11.
Try turning off the onboard USB from BIOS and see if the network then works.
FWIW I had kudzu do nothing on boot, so I could easily go back to usb+eth0 via
358. I am right now running 448 with USB disabled and a very working
Since that patch (plus a whole lot more) to ehci-hcd.c are present included
patches in the .448.src.rpm -- it seems like it just doesn't fix the problem.
The only references in the change log for 2.6.7-bk6 for ehci-hcd are
ChangeSet@1.1722.99.77, 2004-06-17 15:21:44-07:00, *****-*@*******.net
[PATCH] proper bios handoff in ehci-hcd
(which was the day after 2.6.7) so looks like at least I will be waiting on
another patch to ehci-hcd.
I checked 2.6.7-1.456 to see if this had been resolved...still broken
here. Since doing without USB isn't a viable option on this system, I
have not looked into the disabling USB workaround.
Created attachment 101552 [details]
dmsg of custom459 - ehci and forcedeth work with config options UP LOCAL-APIC and IO-APIC
This is the dmesg of the custom kernel of 459 I just built with 2 other config
options. I found a thread at
which discusses our problem -- or at least mine :-) Anyway, post #23 in the
thread said to use these two options (UP LOCAL-APIC and IO-APIC). The .config
I now have a working ehci and forcedeth with a 2.6.7 kernel and no screaming
interrupts. Try building a custom kernel with these two options. If you do,
these options are in the "Processor type and features" section of a make
menuconfig. Of course your MMV, but I've tested just about everything I can
think of and its all good.
One more thing I used gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7), which
is older. I'm going to upgrade that now and try again -- just to make sure
there is no gcc version issues as well.
I don't know emperically what the impact on other 686 HW configs might be, but
I would ask if these could be added to the 686 config. Since I am only looking
at .0001% of the picture I can accept, (without any whining) (that's not aimed
at anyone here) that might not happen. Either way I can deal. Thanks.
I should have checked the kernel.org change log before posting the
above. Sorry for being an idiot.
Y'all might want to wait and see if this patch (see below) that has
been accepted will be the fix.
for full details.
ChangeSet@1.1760.26.5, 2004-06-24 10:21:05-07:00, *****-*@*******.net
[PATCH] USB: EHCI IRQ tweaks
Various tweaks to EHCI IRQ handling, these may affact some systems.
- Delays enabling IRQs until the root hub is more fully set up, so
any "resume detect" IRQs can be handled properly. (Craig Nadler)
- Power down ports on driver shutdown. (Craig Nadler)
- Remove some duplicate irq-sharing logic that somehow crept in; check
only once, and return IRQ_NONE to detect IRQ storms better (db)
- Minor comment fix re integrated TTs. (db)
From: Craig Nadler
Signed-off-by: David Brownell
Signed-off-by: Greg Kroah-Hartman
Good news - I just tried 2.6.7-1469, and everything works
"out-of-the-box" forcedeth, ehci.
2.6.7-1.469 resolves the bug as originally reported.