Hi guys, Gamedev probably isn't the correct place for this, but I'm sure one of you will know. First things first, there are 3 network cards, (A) which is a 3com gigabit ethernet card, (B) which is a 3com 100Mb card, and (C) which is a belkin 100Mb card. I recently installed a gigabit ethernet controller to my server, in place of the previous (B) 100Mb one. I figured that I wouldn't have to actually do anything, that linux would sort itself out. Ha! Well, firstly linux stopped recognising the other network card (C) in the machine, which isn't much use. So, I replaced (C) with (B). Now linux could see both cards, but didn't want to use either of them. (Oh, where the cards mapped to, eth0 and eth1, kept changing aswell - rather annoying). So, I put (C) into another spare PCI slot, hoping that I could pick and choose what controllers were actually working. In effect, this worked. (C) became eth1, and (A) eth0. Great. Unfortunately, (B) is nolonger being recognised in the system, for some bizarre reason. At least, I don't think it is. I never saw it on the dmesg output at all. I have also it seems appeared to have gained two new interfaces, eth1_temp and sit0. I did some googling, and it appears that sit0 is a tunnelling interface, or something like that, and has always been there since kernel version 2.6. Must have missed it. It's eth1_temp that's confusing the fuck out of me, I never see it being configured in dmesg, or, well, ever. It hasn't been brought up either, looking at the ifconfig output. Any idea what the hell is going on here?

Quote: Original post by python_regious
Any idea what the hell is going on here?

(1) Is it possible you have an IRQ or other hardware resource conflict between (B) and (C)?

(2) Are you sure you're modprobing all the relevant drivers (Linux is just like Windows, you need drivers for hardware. It's just that Linux users are usually spoiled by having most drivers bundled with the system and automatically installed instead of having to hunt them down and install them separately).

(3) Have you configured which device is used for what, likely through /etc/network/interfaces, depending on you distro?

(4) Have you checked the hardware information in your Control Centre or equivalent (again, depending on your distro)?

Quote: Original post by Bregma

Quote: Original post by python_regious
Any idea what the hell is going on here?

(1) Is it possible you have an IRQ or other hardware resource conflict between (B) and (C)?

(2) Are you sure you're modprobing all the relevant drivers (Linux is just like Windows, you need drivers for hardware. It's just that Linux users are usually spoiled by having most drivers bundled with the system and automatically installed instead of having to hunt them down and install them separately).

(3) Have you configured which device is used for what, likely through /etc/network/interfaces, depending on you distro?

(4) Have you checked the hardware information in your Control Centre or equivalent (again, depending on your distro)?

(1) Well, the cards did have a problem with being in the #2 PCI slot, as it was conflicting with the IRQ of the onboard ATA controller.

(2) Yes, the correct drivers are being installed. Given that card (B) was recognised perfectly before, and not anymore is what's bizarre.

(3) Yes, the interfaces config is correct.

(4) Control Centre? I'm just using Debian, no form of X or window manager is installed.

Quote: Original post by python_regious

(2) Yes, the correct drivers are being installed. Given that card (B) was recognised perfectly before, and not anymore is what's bizarre.

Sure you have all the drivers, but perhaps that's why you're having problems? Driver conflicts between two different brands?

EDIT: Similar problems occur when switching between video cards of nVidia & ATi. You'd need to completely delete old drivers that might be confliciting with video cards. The difference is, you're trying to use both at the same time. Therefore, you can't simply delete the old drivers, 'cause then one of the the brands will completely stop working. All the drivers need a way to be accessed at the same time without any conflicts..hmm.

Have you tried different forums like BitTech.net or AnandTech?

Quote: Original post by D Shankar

Quote: Original post by python_regious

(2) Yes, the correct drivers are being installed. Given that card (B) was recognised perfectly before, and not anymore is what's bizarre.

Sure you have all the drivers, but perhaps that's why you're having problems? Driver conflicts between two different brands?

EDIT: Similar problems occur when switching between video cards of nVidia & ATi. You'd need to completely delete old drivers that might be confliciting with video cards. The difference is, you're trying to use both at the same time. Therefore, you can't simply delete the old drivers, 'cause then one of the the brands will completely stop working. All the drivers need a way to be accessed at the same time without any conflicts..hmm.

Have you tried different forums like BitTech.net or AnandTech?

Hmmm... Yeah, I see your point. Well, I'll double check that the correct drivers are being used. I don't think there's a conflict between (B) and (C) or (A) and (C), but rather (A) and (B), as I have (A) and (C) working together now, and I had (B) and (C) working together earlier. I also 'un'modprobed the driver and it didn't affect (A) at all. Odd thing is that (A) and (B) are both 3Com cards, so you'd think that they would be able to work together...

I may look into those other forums, thank you.

Ok, things have taken an even more bizarre turn. I recently reorganised my entertainment system, and needed to use the multiplug thingy that was running my server, so I shut the system down while I changed the power arrangements. I switched the server back on, only to find that my net didn't work anymore. It appeared that linux decided to recognise all three network interfaces now, (and once again changed their names, hence why the net didn't work). That sid0 interface has now gone, eth1_temp has gone, and has been replaced with eth2. Well, sort of. Looking at the output of dmesg, (C) has been named to eth2, (B) to eth1 and (A) to eth0. What's odd is that I can't actually use eth2. I try to get it to dhcp an IP from my cable modem, but it just doesn't like it, all it says is "cannot bring up eth2". So, I'm now having to use (A) and (B), and while eth2 is being recognised, I can't actually use it. So, it appears my computer is housing some phantom being, as I never reconfigured it at all, it just randomly changed...

Ok, so I managed to get (A) and (C) working, without (B) in the system, and the network is now running at about 300Kbs. [sad].

Quote: Original post by python_regious
Ok, so I managed to get (A) and (C) working, without (B) in the system, and the network is now running at about 300Kbs. [sad].

Well, I can't explain what's going on in your machine, but I've run into the device renaming thing a few times. I asked around at the office (I work at a Linux distro, we have some experts on the subject here), and they point out that the network devices are enumerated in the order in which the corresponding kernel modules are loaded (ie eth0 is the first NIC found by the system and so on). It turns out the order of modules being loaded is effectively numerically ascending by inode number, or something wacky like that. If you replaced a driver for whatever reason, then the order of loading the modules may have been switched and suddenly the naming of the devices gets switched around.

The PCI slot determines the naming of the devices only if they're driven by the same driver.

Anyways, good luck with that.

Quote: Original post by Bregma

Quote: Original post by python_regious
Ok, so I managed to get (A) and (C) working, without (B) in the system, and the network is now running at about 300Kbs. [sad].

Well, I can't explain what's going on in your machine, but I've run into the device renaming thing a few times. I asked around at the office (I work at a Linux distro, we have some experts on the subject here), and they point out that the network devices are enumerated in the order in which the corresponding kernel modules are loaded (ie eth0 is the first NIC found by the system and so on). It turns out the order of modules being loaded is effectively numerically ascending by inode number, or something wacky like that. If you replaced a driver for whatever reason, then the order of loading the modules may have been switched and suddenly the naming of the devices gets switched around.

The PCI slot determines the naming of the devices only if they're driven by the same driver.

Anyways, good luck with that.

Ah, that makes more sense. I decided to just rip out the gigabit card and stick with 100Mb. Everything instantly went back to working perfectly. I googled the skge driver which was being used, and apparently a lot of people have been having trouble with it. I'll try 3Coms one whenever I get the chance (only just found it existed).

I had the same problem.

If you are using a kernel 2.6.xx and have "udev" running, I may have a hint.

Have a look into /etc/udev/rules.d/z25_persistent-net.rules

There is a mapping of MAC-Addresses to the names of interfaces. Rules entered in this file break rules entered in /etc/modules.d/aliases or elswhere. If you find double entries delete the redundant ones. Edit the names of the interfaces as you need. If entries are missing clone a entry and modify MAC-address and name.

Have fun.
Moritz