Ok, I'm fairly new to linux, so please bare with me!

I'm currently attempting to setup a IBM ThinkCentre M50 with an Installation of Red Hat 9.0. Most things appear to be setup correctly via the setup routine minus the ethernet controller. The machine has a Intel 865G motherboard with inbuilt Intel Pro 1000MT Desktop Ethernet.

Once Red Hat is installed, I've tried running 'kudzu' to setup
this device, but this appears to fail. 'kudzu -p' shows the following;

class: NETWORK
bus: PCI
detached: 0
device: eth
driver: unknown
desc: "Intel Corp.|unknown device 8086:1013"
vendorId:8086
deviceId: 1013
subVendorID: 1014
subDeviceUD: 0285
pciType: 1

So in my limited experience it appears to recognise that the device is there and a Ethernet device, but it doesn't appear to know exactly 'what' it is so it can proceed to use the correct drivers (modules?) to iniate the device.

Could someone help me out on what steps need to be taken to resolve this issue. Many thanks.

I should also probably add that I tried following the guide to setting up the required e1000 modules here;

http://support.intel.com/support/net...1000/e1000.htm

whilst this appears to work correctly, as soon as I try to insmod e1000 it comes back telling me something along the lines of no device can be found.

Just to add alittle more info;

modprobe e1000

/lib/modules/2.4.20-8smp/kernel/drivers/net/e1000.o: No such device
Hint: ismod errors can be caused by incorrect module parameters, including invaild IO of IRQ paramaters
You may find more information in the syslog or the output from dmesg. . .

using lspci -v

Ethernet controller: Intel Corp: Unknown device 1013
Subsystem: IBM: Unknow device 0285
Flags: bus master, 66mhz, medium devsel, latency 52, IRQ 16
Memory at d8100000 (32 bit, non prefetchable) [size=128K]
I/O ports at 2000 [size=64]
. . . then some capanbilities . .

it appears the controller (ethernet adapter) is using IRQ=16 and lists IO ports at 2000 (size=64)??

using dmesg it shows that APIC appears to be loading up. It's been suggested that this can cause issues?? Additionally when looking through dmesg I see the lines;

Intel)R) PRO/1000 Network Driver - version 4.3.15
Copyright (c) 1999-2002 Intel Corporation
. .

listed six times at the end of dmesg which I assume was me trying to load the module six times?

Hoping someone can help me out.

. . .anyone?

nevermind. .

Did you ever get anywhere with this? I'm having the exact same problem. Mine is occurring on a SuperMicro motherboard X5DPA-GG - dual Xeon 2.4G with integrated dual Intel 1000 GLAN. I happen to have two such servers, both running RedHat 9.0 and one machine WORKS FINE, but the other does not; they are hardware-identical systems down to the RAM selection. Naturally, this is quite baffling.

Also tried downloading and compiling the e1000 driver available on SuperMicro's FTP server with no improvement: "No such device" whenever you try to insmod e1000.

Got it nailed. I phoned up support for the motherboard manufacturer to ask them if there are any known problems and it turns out there are: Intel's most recent GLAN chipset apparently has some flaw in it preventing it from operating properly under Linux. Their solution is to have me send in the motherboard so that they can replace the GLAN chips, but I'm going to opt to swap out the board for yet another machine which is running XP and should be impervious to the problem. The other system that I have which works bears an older revision of the chipset which does not exhibit the problem.

From the sound of things the problem with this chipset extends beyond this one motherboard that I have and probably well into the PCI adapter boards, so in all likelihood it is the same problem you are experiencing.

This is how the device appears in /etc/sysconfig/hwconf on the machine that works correctly (2 adapters integrated on the motherboard):
It's possible that the only problem is with the subVendorId and subDeviceId mis-matching. I'll check the e1000.c later tonight for this. If manually patching the driver fixes it, then we could be all set.

On the machine that exhibits the problem, it looks like this:
So the subDeviceId though it looks abnormal on the second device, it appears fine on the first one. And it doesn't come anywhere near to matching the subVendorId and subDeviceId on your system, so I'm inclined to think that the root of the problem lies beyond the reach of this simplistic solution I've proposed.

Problem solved: e1000-5.2.20.tar.gz

Get it from Intel directly. Copy that filename above into the search box on the linked page there and you'll find Intel has corrected the driver.