Hi ya'll,
Running v5 ..
I have 2 Linksys PCI cards running already without any problems. These were recognized by the system as ADMTek NC100 cards, per usual... they run on eth0 and eth2 ... have for months.... no problems.
I added a third Linksys PCI card to the mobo, fired the computer up, and it is not recognized at all. It has been many years since I had this problem of a network card not being automatically recognized, so I am a little rusty.
Can someone give me input on the steps needed to get this third NIC recognized please.
Thanks for your help.
Gary wrote:
Can someone give me input on the steps needed to get this third NIC recognized please.
run lspci to try to identify what network controller chip is on the third NIC. If that doesn't help then look at the chip on the physical card itself, and use google to try to match that up with a driver.
Linksys probably uses something shitty like Realtek chips or something, or worse(?)
nate
Hi John,
oh, boy...... will check on it early tomorrow... thanks.
On Tue, 09 Sep 2008 21:40:00 -0700 UTC (9/9/2008, 11:40 PM -0500 UTC my time), John R Pierce wrote:
Linksys probably uses something shitty like Realtek chips or something, or worse(?)
J> the same model name linksys card could potentially use a half dozen J> different chips depending on the version #, makes life real fun.
Hi Nate,
It is the same Linksys card that is already recognized. CentOS effectively uses the Linksys as ADMTek NC100 for Linksys immediately recognized with no problem. It just will not recognize this third card at all, not even seeing it using lspci, which shows no Ethernet controller for the same 3rd card ..
On Tue, 9 Sep 2008 21:21:46 -0700 (PDT) UTC (9/9/2008, 11:21 PM -0500 UTC my time), nate wrote:
Can someone give me input on the steps needed to get this third NIC recognized please.
n> run lspci to try to identify what network controller chip is on n> the third NIC. If that doesn't help then look at the chip on the n> physical card itself, and use google to try to match that up with n> a driver.
n> Linksys probably uses something shitty like Realtek chips or n> something, or worse(?)
Gary wrote:
Hi Nate,
It is the same Linksys card that is already recognized. CentOS effectively uses the Linksys as ADMTek NC100 for Linksys immediately recognized with no problem. It just will not recognize this third card at all, not even seeing it using lspci, which shows no Ethernet controller for the same 3rd card ..
does LSPCI not even show the 3rd card?!?
each PCI device has A) a bus/card/function # (determined by the motherboard slot and such), and B) a vendor/device ID # (hard coded on the card)
a typical system...
# lspci 00:00.0 Host bridge: Broadcom CMIC-WS Host Bridge (GC-LE chipset) (rev 13) 00:00.1 Host bridge: Broadcom CMIC-WS Host Bridge (GC-LE chipset) 00:00.2 Host bridge: Broadcom CMIC-LE 00:04.0 Class ff00: Dell Embedded Remote Access or ERA/O 00:04.1 Class ff00: Dell Remote Access Card III 00:04.2 IPMI SMIC interface: Dell Embedded Remote Access: BMC/SMIC device 00:0e.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 00:0f.0 Host bridge: Broadcom CSB5 South Bridge (rev 93) 00:0f.1 IDE interface: Broadcom CSB5 IDE Controller (rev 93) 00:0f.2 USB Controller: Broadcom OSB4/CSB5 OHCI USB Controller (rev 05) 00:0f.3 ISA bridge: Broadcom CSB5 LPC bridge 00:10.0 Host bridge: Broadcom CIOB-X2 PCI-X I/O Bridge (rev 03) 00:10.2 Host bridge: Broadcom CIOB-X2 PCI-X I/O Bridge (rev 03) 00:11.0 Host bridge: Broadcom CIOB-X2 PCI-X I/O Bridge (rev 03) 00:11.2 Host bridge: Broadcom CIOB-X2 PCI-X I/O Bridge (rev 03) 01:06.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07) 01:06.1 Input device controller: Creative Labs SB Live! Game Port (rev 07) 01:08.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07) 01:08.1 Input device controller: Creative Labs SB Live! Game Port (rev 07) 02:06.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07) 02:06.1 Input device controller: Creative Labs SB Live! Game Port (rev 07) 03:06.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15) 03:08.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15) 04:08.0 PCI bridge: Intel Corporation 80303 I/O Processor PCI-to-PCI Bridge (rev 01) 05:06.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 05:06.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)
the first field is the bus.slot.func number. on this particular server, bus 00, 03, 04, and 05 are on the mainboard, while busses 01 and 2 are actual PCI slots, this machine actually has 3 SB Live cards plugged into it as its a sound processor. bus 03 device 06 and 08 are the onboard broadcom ethernet controllers.
this i the same system shown in numeric form...
# lspci -n 00:00.0 0600: 1166:0012 (rev 13) 00:00.1 0600: 1166:0012 00:00.2 0600: 1166:0000 00:04.0 ff00: 1028:000c 00:04.1 ff00: 1028:0008 00:04.2 0c07: 1028:000d 00:0e.0 0300: 1002:4752 (rev 27) 00:0f.0 0600: 1166:0201 (rev 93) 00:0f.1 0101: 1166:0212 (rev 93) 00:0f.2 0c03: 1166:0220 (rev 05) 00:0f.3 0601: 1166:0225 00:10.0 0600: 1166:0101 (rev 03) 00:10.2 0600: 1166:0101 (rev 03) 00:11.0 0600: 1166:0101 (rev 03) 00:11.2 0600: 1166:0101 (rev 03) 01:06.0 0401: 1102:0002 (rev 07) 01:06.1 0980: 1102:7002 (rev 07) 01:08.0 0401: 1102:0002 (rev 07) 01:08.1 0980: 1102:7002 (rev 07) 02:06.0 0401: 1102:0002 (rev 07) 02:06.1 0980: 1102:7002 (rev 07) 03:06.0 0200: 14e4:1645 (rev 15) 03:08.0 0200: 14e4:1645 (rev 15) 04:08.0 0604: 8086:0309 (rev 01) 05:06.0 0100: 9005:00cf (rev 01) 05:06.1 0100: 9005:00cf (rev 01)
for an example, 14e4 is broadcom's vendor ID and 14e4:1645 is the broadcom bcm5701
these are what the OS actually works with, the vendor:device ID is matched up with the device driver database
I hope this helps.
Hi John,
On Tue, 09 Sep 2008 22:01:51 -0700 UTC (9/10/2008, 12:01 AM -0500 UTC my time), John R Pierce wrote:
It is the same Linksys card that is already recognized. CentOS effectively uses the Linksys as ADMTek NC100 for Linksys immediately recognized with no problem. It just will not recognize this third card at all, not even seeing it using lspci, which shows no Ethernet controller for the same 3rd card ..
J> does LSPCI not even show the 3rd card?!?
No, not at all...
in part
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12)
Drivers for the above mobo eth are not installed. I always have had problems eventually with Gigabit dropping packets, so I did not use this built in eth, just the Linksys PCI NICs.
05:01.0 Ethernet controller: ADMtek NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) 05:02.0 Ethernet controller: ADMtek NC100 Network Everywhere Fast Ethernet 10/100 (rev 11)
J> each PCI device has A) a bus/card/function # (determined by the J> motherboard slot and such), and B) a vendor/device ID # (hard coded on J> the card)
J> a typical system...
many thanks for this detailed explanation.
Gary wrote:
J> does LSPCI not even show the 3rd card?!?
No, not at all...
If the PCI bus doesn't see it there's no way to get it working in linux(or any other OS for that matter).
Perhaps there is an IRQ conflict, check the IRQs on the system, and try the NIC in a different PCI slot. Try disabling some on board features(parallel port, serial port etc if you don't need them) to free up IRQs.
Pull out the other NICs and just try that 3rd NIC to try to verify that the NIC itself is OK or not.
Many BIOSs print out the various PCI cards and their IRQs as part of the POST process, usually just before the boot loader kicks in, if yours does this make sure you see that 3rd NIC on there before linux boots up.
nate
Hi Nate,
On Tue, 9 Sep 2008 22:29:38 -0700 (PDT) UTC (9/10/2008, 12:29 AM -0500 UTC my time), nate wrote:
J> does LSPCI not even show the 3rd card?!?
No, not at all...
n> If the PCI bus doesn't see it there's no way to get it working n> in linux(or any other OS for that matter).
....... snip ......
All good ideas, thanks very much...
nate wrote:
Gary wrote:
J> does LSPCI not even show the 3rd card?!?
No, not at all...
If the PCI bus doesn't see it there's no way to get it working in linux(or any other OS for that matter).
Perhaps there is an IRQ conflict, check the IRQs on the system, and try the NIC in a different PCI slot. Try disabling some on board features(parallel port, serial port etc if you don't need them) to free up IRQs.
IRQ's are fully sharable on PCI, all PCI devices can use a single hardware IRQ with no problems.
Pull out the other NICs and just try that 3rd NIC to try to verify that the NIC itself is OK or not.
I'd suggest trying the NIC in a different slot.
Many BIOSs print out the various PCI cards and their IRQs as part of the POST process, usually just before the boot loader kicks in, if yours does this make sure you see that 3rd NIC on there before linux boots up.
and in fact, that display often shows the bus.slot.func too, which is the same info shown on lspci
John R Pierce wrote:
IRQ's are fully sharable on PCI, all PCI devices can use a single hardware IRQ with no problems.
In theory yes, in practice these days usually yes but it's by no means a guarantee it will work. It's been a few years since I had IRQ sharing issues, but when it did happen it was on the PCI bus. Perhaps broken devices, perhaps broken bios(s), who knows but it can happen. And when dealing with Linksys, I'm sure the possibility of 'broken devices' skyrockets pretty fast.
I'd suggest trying the NIC in a different slot.
Most often what happens in a different slot is a different IRQ is assigned. (Usually only a small range of IRQs are available for each PCI slot)
nate
nate wrote:
John R Pierce wrote:
IRQ's are fully sharable on PCI, all PCI devices can use a single hardware IRQ with no problems.
In theory yes, in practice these days usually yes but it's by no means a guarantee it will work. It's been a few years since I had IRQ sharing issues, but when it did happen it was on the PCI bus. Perhaps broken devices, perhaps broken bios(s), who knows but it can happen. And when dealing with Linksys, I'm sure the possibility of 'broken devices' skyrockets pretty fast.
IRQ problems wouldn't prevent LSPCI from enumerating the PCI devices
I'd suggest trying the NIC in a different slot.
Most often what happens in a different slot is a different IRQ is assigned. (Usually only a small range of IRQs are available for each PCI slot)
or the slot its in is broken. I've seen boards with bad PCI slots, typically a broken select, so the device plugged into that slot simply didn't show up.
or the card itself is broken, whereupon, well, replace it.
Hi John, Nate,
On Tue, 9 Sep 2008 23:49:27 -0700 (PDT) UTC (9/10/2008, 1:49 AM -0500 UTC my time), nate wrote:
IRQ's are fully sharable on PCI, all PCI devices can use a single hardware IRQ with no problems.
n> In theory yes, in practice these days usually yes but it's by no n> means a guarantee it will work. It's been a few years since I n> had IRQ sharing issues, but when it did happen it was on the n> PCI bus. Perhaps broken devices, perhaps broken bios(s), who n> knows but it can happen. And when dealing with Linksys, I'm n> sure the possibility of 'broken devices' skyrockets pretty n> fast.
ha, I removed the problematic 3rd Linksys, and put in an older DEC 21140. CentOS recognized it immediately. We are up and running.
Thanks guys for your help.
-
Gary -
John R Pierce -
nate