Bug 125923 - Bringing up eth0 RTL8139 nic fails with kernel version 457
Summary: Bringing up eth0 RTL8139 nic fails with kernel version 457
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 2
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-06-14 06:41 UTC by Brent Hills
Modified: 2015-01-04 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-11-19 06:32:12 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Brent Hills 2004-06-14 06:41:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
Bootup with kernel version 427 fails to bringup the network interface
but works consistently under version 358.

Excerpts from /var/log/messages are below for both versions:

Related messages in the log attempting to boot 427:
Jun 13 22:50:18 localhost kernel: 8139too Fast Ethernet driver 0.9.27
Jun 13 22:50:18 localhost kernel: eth0: RealTek RTL8139 at 0xc800,
00:0d:61:01:6a:6a, IRQ 11
Jun 13 22:50:18 localhost kernel: eth0: link up, 100Mbps, full-duplex,
lpa 0x45E1
Jun 13 22:50:18 localhost kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jun 13 22:50:18 localhost kernel: eth0: link up, 100Mbps, full-duplex,
lpa 0x45E1
Jun 13 22:50:18 localhost kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jun 13 22:50:18 localhost kernel: eth0: link up, 100Mbps, full-duplex,
lpa 0x45E1

Jun 13 22:50:18 localhost kernel: eth0: link up, 100Mbps, full-duplex,
lpa 0x45E1
Jun 13 22:50:18 localhost netfs: Mounting other filesystems:  succeeded
Jun 13 22:50:18 localhost autofs: automount startup succeeded
(smartd entries removed)
Jun 13 22:50:17 localhost ifup:  failed.


Under 358 the interface comes up:
Jun 13 22:57:10 unixtop kernel: 8139too Fast Ethernet driver 0.9.27
Jun 13 22:57:10 unixtop kernel: eth0: RealTek RTL8139 at 0xc800,
00:0d:61:01:6a:6a, IRQ 11
Jun 13 22:57:10 unixtop kernel: eth0: link up, 100Mbps, full-duplex,
lpa 0x45E1 
(removed unrelated messages)
Jun 13 22:57:09 unixtop ifup:  done.
Jun 13 22:57:09 unixtop network: Bringing up interface eth0:  succeeded


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

How reproducible:
Always

Steps to Reproduce:
1. Reboot and select kernel version 427

    

Actual Results:  Bringing up the network interface fails for eth0

Expected Results:  Bring up the interface and acquire an IP by DHCP

Additional info:

Comment 1 Brent Hills 2004-06-15 05:05:23 UTC
Continues to fail with kernel version 435

Comment 2 Dave Jones 2004-06-15 10:29:32 UTC
does it work if you boot with acpi=off ?


Comment 3 Brent Hills 2004-06-16 04:42:25 UTC
Continues to fail with or without acpi=off in kernels 435 and 427.  It
works in 358 which I boot without any acpi options (just defaults).

Manually setting a static address and routing without using dhclient
also fails to create a working network connection.

'ethtool' reports the same information when booted to a working kernel
as when booted to a non-functioning kernel as does 'mii-tool'.

Comment 4 Brent Hills 2004-06-16 21:46:41 UTC
Going through messages repeatedly, I found some additional messages
that are most likely meaningful.  It registers the ehci_hcd to irq 11.
 Immediately after the "new USB bus registered assigned bus number 1".
 An irq 11: nobody cared! (screaming interrupt?)
 Stack pointer is garbage, not printing trace
 handlers:
 [<02216a58>] (usb_hcd_irq+0x0/0x4b)
 Disabling IRQ #11

The irq 11 nobody cared and related messages only occurs when booting
with 435 and 427.  The nic is also assigned to IRQ 11 later in
messages and fails as described previously. 

My appologies for not noting this or providing the full log initially.

Comment 5 Dave Jones 2004-11-19 03:55:03 UTC
is this still a problem in the latest errata kernels ?


Comment 6 Brent Hills 2004-11-19 06:32:12 UTC
I can confirm I no longer have this issue with kernel-2.6.9-1.667 on
Fedora Core 3.


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