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): kernel-2.6.6-1.427 How reproducible: Always 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 3. Actual Results: Network is non-functional Expected Results: functional network Additional info: 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, I'm getting: 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 acpi=off.
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 http://www.redhat.com/archives/fedora-test-list/2004-June/msg00344.html about a certain ehci-hcd patch being applied or not, it seems to me this is really the same bug as http://bugzilla.kernel.org/show_bug.cgi?id=2846 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 forcedeth. 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. Andrew
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 http://www.gossamer-threads.com/lists/linux/kernel/401146 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 items are CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y 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. Andrew
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. See http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.7-bk13.log 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.