Bug 125839 - (ACPI) Eth0 won't activate using forcedeth driver
(ACPI) Eth0 won't activate using forcedeth driver
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Depends On:
  Show dependency treegraph
Reported: 2004-06-12 00:37 EDT by Karen Spearel
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-07 07:21:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output from the dmesg showing forcedeth not handling irq11 (13.03 KB, text/plain)
2004-06-17 21:31 EDT, Andrew Duggan
no flags Details
dmesg from 441 (14.36 KB, text/plain)
2004-06-21 21:54 EDT, Andrew Duggan
no flags Details
dmsg of 448 with onboard usb disabled and a working forcedeth (11.00 KB, text/plain)
2004-06-23 22:52 EDT, Andrew Duggan
no flags Details
dmsg of custom459 - ehci and forcedeth work with config options UP LOCAL-APIC and IO-APIC (15.01 KB, text/plain)
2004-06-30 22:23 EDT, Andrew Duggan
no flags Details

  None (edit)
Description Karen Spearel 2004-06-12 00:37:38 EDT
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 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

Version-Release number of selected component (if applicable):

How reproducible:

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

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.
Comment 1 Joshua Jensen 2004-06-12 11:00:06 EDT
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).
Comment 2 vadim tarassov 2004-06-12 16:02:22 EDT
Same here with forcedeth driver and nvidia mobo.
Comment 3 Jason Salaz 2004-06-12 18:59:44 EDT
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
Comment 4 Daniel Vallstrom 2004-06-14 04:51:39 EDT
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.
Comment 5 Karen Spearel 2004-06-14 16:44:02 EDT
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. 
Comment 6 Yaron Minsky 2004-06-15 09:59:05 EDT
Same thing occurs on an Aslab marquis k118, which has an  ASUS A7N8X.
Comment 7 Andrew Duggan 2004-06-17 21:31:24 EDT
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.
Comment 8 Andrew Duggan 2004-06-17 22:42:10 EDT
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

Comment 9 Alan Cox 2004-06-19 07:19:00 EDT
Probably ACPI not forcedeth breakage
Comment 10 Karen Spearel 2004-06-19 11:46:57 EDT
using acpi=off doesn't make any difference on this system with either
.435 or .437...network interface still doesn't work.
Comment 11 Andrew Duggan 2004-06-21 21:54:26 EDT
Created attachment 101321 [details]
dmesg from 441 

ACPI output was more verbose, so I thought it might help
Comment 12 Andrew Duggan 2004-06-23 22:52:56 EDT
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.

Comment 13 Karen Spearel 2004-06-25 14:13:42 EDT
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.
Comment 14 Andrew Duggan 2004-06-30 22:23:56 EDT
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
items are
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.

Comment 15 Andrew Duggan 2004-06-30 22:56:35 EDT
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 
Comment 16 Andrew Duggan 2004-07-03 23:28:34 EDT
Good news - I just tried 2.6.7-1469, and everything works
"out-of-the-box" forcedeth, ehci.
Comment 17 Karen Spearel 2004-07-04 02:23:13 EDT
2.6.7-1.469 resolves the bug as originally reported.

Note You need to log in before you can comment on or make changes to this bug.