Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163353 - e1000 for ABIT IC7-G missing from pcitable, 0x8086 0x1075
Summary: e1000 for ABIT IC7-G missing from pcitable, 0x8086 0x1075
Keywords:
Status: CLOSED DUPLICATE of bug 166018
Alias: None
Product: Fedora
Classification: Fedora
Component: hwdata
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-15 13:55 UTC by Carl-Johan Kjellander
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-14 14:14:12 UTC


Attachments (Terms of Use)
A patch to pcitable to add the correct entry. (deleted)
2005-07-15 13:55 UTC, Carl-Johan Kjellander
no flags Details | Diff

Description Carl-Johan Kjellander 2005-07-15 13:55:56 UTC
Description of problem:
When trying out diskless stateless-linux 2 of our machines, two
of our machines failed to start the network card e1000 since
the vendor and device numbers are missing from:

/usr/share/hwdata/pcitable

Version-Release number of selected component (if applicable):
hwdata-0.145-1, kernel-smp-2.6.11-1.27_FC3
Allways

Steps to Reproduce:
1. Boot stateless linux with kernel-smp-2.6.11-1.27_FC3, and I would
imagine the latest kernel as well which I will try soon, in a diskless
mode via pxe, on an ABIT IC7-G motherboard.

  
Actual results:
It modprobes nfs but fails to modprobe e1000 so the kernel panics
trying to mount the root filesystem.

Expected results:
the initrd should contain a pcitable with the right numbers
so the kernel can load e1000 and boot.

Additional info:
I manually patched the initrd and added this line to pcitable:

0x8086  0x1075  "e1000"

After that it booted just fine.

I'll attach a patch to hwdata-0.145.

Here is the lspci -vvn info:

02:01.0 Class 0200: 8086:1075
        Subsystem: 147b:1014
        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: 0 (63750ns min), Cache Line Size 08
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=128K]
        Region 2: I/O ports at a000 [size=32]
        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=1 PME-

Here is a link to the motherboard:

http://www.abit-usa.com/products/mb/products.php?categories=1&model=4

 Intel PRO/1000 CT Desktop Connection Gigabit LAN on board

is what they call the network card.

Comment 1 Carl-Johan Kjellander 2005-07-15 13:55:57 UTC
Created attachment 116798 [details]
A patch to pcitable to add the correct entry.

Comment 2 Bill Nottingham 2005-07-15 16:18:55 UTC
It's in the modules.pcimap for the driver, so this shouldn't be needed; I'd
suspect the problem is elsewhere.

Is the module actually on your initrd?

Comment 3 Carl-Johan Kjellander 2005-07-15 16:51:37 UTC
Yes it is. The 'linuxrc' file in the initrd from stateless linux
uses pcitable. That's how I found the solution. Patching that
fixes the boot problems for diskless stateless linux on those
two machines we have.

Maybe stateless-linux is using an old and cumbersome way of
determining which modules if should load?

Comment 4 Bill Nottingham 2005-07-15 17:14:32 UTC
Yes; it should be using some combination of modules.pcimap/pcitable.

Not sure what component to move the bug to, though

Comment 5 Carl-Johan Kjellander 2005-07-15 19:35:03 UTC
It should probably be assigned to havoc at least.

Comment 6 Bill Nottingham 2005-09-14 14:14:12 UTC

*** This bug has been marked as a duplicate of 166018 ***


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