Bug 217059

Summary: 3c59x fails to start at boot
Product: [Fedora] Fedora Reporter: Pierre Thibaudeau <prt3>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: jonstanley, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-08 04:26:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 427887    

Description Pierre Thibaudeau 2006-11-23 15:24:37 UTC
Right after a boot, "ifconfig -a" gives the following in lieu of eth0

__tmp1804289383 Link encap:Ethernet  HWaddr 00:B0:D0:14:A7:14  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interruption:3 Adresse de base:0xac00 

Because of this the "network" service will not start correctly.

If I do "modprobe -r eth0; modprobe eth0", the 3c59x module is reloaded
(correctly) and eth0 shows normally in "ifconfig -a". The "network" service can
then start normally.

It looks like this device need extra time at power on.

As a workaround, I have included a "modprobe -r eth0" at the start of
/etc/init.d/network it starts all right.

Same thing with kernel 2.6.18-1.2798.fc and 2.6.18-1.2849.fc6.

Note that I did not have this issue whith 2.6.17-1.2142_FC4.

For information, here's a lspci output for the offending interface:

02:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
        Subsystem: Dell Unknown device 00c7
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 3
        Region 0: I/O ports at ec00 [size=128]
        Region 1: Memory at ff2fec00 (32-bit, non-prefetchable) [size=128]
        Expansion ROM at 54000000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-

Comment 1 Patrick C. F. Ernzer 2007-11-25 15:02:25 UTC
this bug is still present in RHEL 5.1 (2.6.18-53.el5) and the described dirty
hack still works

Comment 2 Jon Stanley 2008-01-08 01:53:34 UTC
(This is a mass-update to all current FC6 kernel bugs in NEW state)

Hello,

I'm reviewing this bug list as part of the kernel bug triage project, an attempt
to isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug, however this version of Fedora is no longer
maintained.

Please attempt to reproduce this bug with a current version of Fedora (presently
Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a
few days if there is no further information lodged.

Thanks for using Fedora!

Comment 3 Jon Stanley 2008-02-08 04:26:29 UTC
Per the previous comment in this bug, I am closing it as INSUFFICIENT_DATA,
since no information has been lodged for over 30 days.

Please re-open this bug or file a new one if you can provide the requested data,
and thanks for filing the original report!