Bug 163353 - e1000 for ABIT IC7-G missing from pcitable, 0x8086 0x1075
e1000 for ABIT IC7-G missing from pcitable, 0x8086 0x1075
Status: CLOSED DUPLICATE of bug 166018
Product: Fedora
Classification: Fedora
Component: hwdata (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
Depends On:
  Show dependency treegraph
Reported: 2005-07-15 09:55 EDT by Carl-Johan Kjellander
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-14 10:14:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Carl-Johan Kjellander 2005-07-15 09:55:56 EDT
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:


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

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
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-

Here is a link to the motherboard:


 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 09:55:57 EDT
Created attachment 116798 [details]
A patch to pcitable to add the correct entry.
Comment 2 Bill Nottingham 2005-07-15 12:18:55 EDT
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 12:51:37 EDT
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 13:14:32 EDT
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 15:35:03 EDT
It should probably be assigned to havoc at least.
Comment 6 Bill Nottingham 2005-09-14 10:14:12 EDT

*** 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.