I'm fairly new to linux and have installed red hat 9 on a pentium III.

This is the first problem I have encountered in regards to red hat not recognizing hardware.

The nic uses realteks RTL8139D which is apparently supported. I installed the nic and manually set the IRQ in BIOS rebooted, the NIC was recognized during boot and I installed it. I then booted into gnome and had a look under network device control the card was listed but not activated when I clicked activate red hat couldn't find the card I got an error msg saying the device does not exsist.

The led on the card is green as is the one on the router....

I have read red hats documentation and it hasn't helped starting to get a little frustrated any help appreciated.

The driver for your card, I think would be 8139too ... not sure...

Anyway, why did you play around with the IRQs? What was wrong with them in the first place?

Change the PCI slot of your RTL lan card & reboot. Linux will detect the driver this time.

..amit..

I am wondering if the slot trick worked?

I, too, am having some challenges with a card using this chipset. I am using the current build of Debian testing, and while it recognizes the recognizes ethernet as well as this card, it assigns them both to INT 10 (I do not have the tools in my bios to tweak this, it seems). While I get a working eth0 and eth1, here's the weird part: sometimes the RTL card is eth0, and sometimes it is eth1.

I have tried another RTL card, same thing. I have tried another MB and another RTL card, same thing.

I will play with the slots to see what that does, but I pass this along so at least someone has heard of this problem, because this eth0/eth1 flip/flop is a new one on me.

check your BIOS settings, I'm not sure how moving the card around the slot would do any change. (then again, I might be wrong) The order that a module is loaded could maybe make a difference perhaps. Check the list of autoloading modules after playing with the settings randomly and see if there is any persistant relationship between the order of loading modules, the slot, and the eth number.

It should be a PNP card...set the bios to plug and play. Unless its an ancient ISA with jumpers

There is no pnp vs no pnp on either the nvideo motherboard board or the other new motherboard I am testing with, so I cannot tell if the pnp or no pnp setting changes this situation (both are award bios, recent versions). I have upgraded the BIOS to one which lets me separate the interrupts, and that also does not seem to significantly change the issue -- eth0 and eth1 still get confused some what randomly.

However, slots and interrupts do seem to have a relationship, at least in the devices I have been testing, though it is not a fix. I have also tried to tweak the modules load order, also, does not seem to help.

I did have lots of fun with insmod and modprobe as a result, to get things running again, after tweaking these int settings and messing with slots. But that said, the 8139 card(s) just were too weird with Debian testing and the AMD-64 (as well as AMD Semp x386 stuff) I have been using (a 2.12 type kern.).

However, use of a wholly different card, in the case I was testing, a Linksys 10/100 PCI card, completely addressed the problem, and now no more eth1/eth0 flip-flop. Note that this situation was and is re-producable with two different new motherboards, running different AMD devices, and different 8139 cards, and even another RTL card, all using PCI (modern 8139too-style) ethernet cards. No ISA (ugg).

Something odd seems to be afoot hear, and me thinks it may relate to pci probing, somehow. It seems to follow (though not perfectly) that it lines up one way on cold boots, and another on warm ones.

It even seemed to do it once during operations (I had a remote ping routine running) which really scared me. But this has not been reproduced.

I have a fix by junking the card, but it still bugs me.

I didn't quite get that you are using the same type of card, that's important to know. By changing one of the card, it's not the same module assigning the numbers anymore, there is a definite load order and numbers will stay constistant. Quite honestly, I didn't think that using two cards sharing the same module would produce two working cards.

Glad you got it fixed.