Hello,

I've spent about two hours online searching for this. I read all the fine manuals. If I missed a thread with the solution, I'll apologize in advance.

I have a Slackware 10 notebook running kernel 2.6.8.1 with a Broadcom Tigon3 NIC hardwired by the BIOS on PCI IRQ 11. I have a PRISM54 cardbus NIC that when inserted takes IRQ10. This results in the PRISM54 card taking eth0 away from the Tigon if I boot the box with the wireless card installed. This is bad. If the box is booted without the WiFi card, the tg3 takes eth0 and all is well. I want to nail this down and not let the device names wander around on their own. I have all the modules compiled in and everything works fine as long as I remember to pull the WiFi NIC before rebooting. Because I am an old fart I often forget to do that.

I have placed aliases in /etc/modprobe.conf and /etc/modules.conf:

alias eth0 tg3
alias eth1 prism54

This has no effect, the boot time detection routine always places the lower IRQ on eth0 and this always seems to trump modprobe. I solved this problem in Redhat using the various 'IFUP-ETHn" scripts in /etc/sysconfig, but Slackware uses inetd and /etc/rc/d. What to do? Editing the rc.inet1.conf file seems to have no effect. I can set the IP's, netmasks, and the gateway, but I can't control which physical interface gets which logical device name.

I have run into this issue at work as well. I have a simulation lab using a Linux router with 17 physical NIC ports - four four-port NIC cards and one normal NIC for the management channel. It is very important that those ports do not walk around if the IRQ's on the cards switch around, which in fact has happened on BIOS updates and EEPROM resets. Same thing on my Linux firewall - I sure don't want the inside and outside interfaces to trade places when something generates a plug-n-pray event.

Is there a way to force Slackware to bind the logical ethernet devices to specific physical ports, maybe using the MAC? I've seen a couple of threads in here but they all died without getting to a solution. I know next to nothing about shell scripting and don't relish having to go in and learn it to rewrite their network init scripts. Has anyone reached a solution for this class of problem?

DR

Oh yes, this has been discussed before.

One solution is to comment out the respective modprobe in /etc/rc.d/rc.modules

and insert the modprobe in the order you want in rc.local

I hope I am clear enough. Will search and put the link here later.

I think you can pass some options to the kernel when booting. You can do that by adding an "append="in your lilo.conf. See http://www.tldp.org/HOWTO/BootPrompt...11.html#ss11.1 for details.

Thank you both for your resopnses.

I tried the rc.local entries, no luck. The file does not seem to be the right place for an alias statement because it complains:

/etc/rc.d/rc.M: line 6: alias: eth0: not found
/etc/rc.d/rc.M: line 6: alias: tg3: not found
/etc/rc.d/rc.M: line 6: alias: eth1: not found
/etc/rc.d/rc.M: line 6: alias: prism54: not found

I tried reversing the order of the alias (alias tg3 eth0, etc.) but that just reverses the order of the error messages. It also seems to execute dead last in the initialization process, well after the unwanted configuration is decided upon. The errors above print out right after gpm is loaded and just before the login prompt.

The system does not have any uncommented modprobe lines for network cards in /etc/rc.d/rc.modules. Neither card is even listed as a possibility, yet the modules are being loaded. I'm not sure what mechanism they are using to load modules if it is not modprobe.conf, modules.conf, or rc.modules. Both modprobe.conf and modules.conf were installed as empty files. I used /sbin/generate-modprobe.conf to fill that file, and it correctly generated a list containing my modules in the correct order (from where I don't know), but again, it has no effect.

I will try passing the IRQ's to the kernel at boot, but the howto referenced seems to say that is for compiled-in drivers, not for modules. I'll try anyway, but that approach seems to me to be depending on the luck of the draw to guess which interface will be on IRQ 11 after the next reshuffle.

The documentation for Slackware is somewhat lacking in details on just how these things are being loaded. They certainly included the standard files, but they don't seem to be using them for anything since they are all empty or commented out.

I have read at least one explanation of the PCI IRQ arbitration scheme that stated that the closest slot to the processor loads first and therefore becomes eth0, but my firewall cards are ordered 3, 0, 2, 1, in their physical slots, proceeding away from the processor. If I reset the EEPROM and force a plug and pray (musical chairs?) event, they will reorder themselves. This has happened after the box got spiked (EMP) by a lightning bolt hitting a tree out in back. The comment about the firewall switching interfaces wasn't hypothetical. It completely reordered its 4 cards and literally turned itself inside out.

There must be a way to prevent this. When I get to work I'll dig more into an RHEL box I have there to see just what they are doing. It may not help much until I can identify just what mecahnism the Slackware guys are using to load the network modules.

Does anyone know what that might be?

You are right, that is for compiled in drivers, I probably misunderstood your line:
But when you load the drivers as modules, it could be hotplug probing the drivers in wrong order for you. What you could do is adding both drivers to the hotplug blacklist file and uncomment or add the lines to rc.modules in the right order. The module that is loaded first will be eth0 I assume

Thank you.

You are correct - that was a typo on my part. I meant to say I have the modules compiled and they are loading.

I'll dig on this hotplug issue as a potential palliative fix for my laptop, but I am still seeking a way to eliminate luck from the equation by assigning a logical device name to a MAC vice an IRQ.

re: http://linux-hotplug.sourceforge.net/?selected=net

<SNIP>
The action taken when an interface is registered is normally to bring it up, using commands such as ifup $INTERFACE or bridging it to your LAN, perhaps after first making sure its name matches its MAC address by running a command such as nameif.
</SNIP>

Yes, it looks like hotplug is doing this. I grep'd the etc directory for instances of nameif in the files and it wasn't found, so it looks like the Slackware guys may have omitted any name to MAC mapping. I really have no shell scripting ability and I am still trying to parse the hotplug code. It looks enough like the languages I do know that I am not totally adrift, but the syntax is a bit opaque for me.

Of course, now that I know about nameif, I can run a script at login to fix it, but that's not going to help much on servers that may automatically reboot when no one is around to log in and fix the interfaces.

I'd still be very grateful to hear from anyone that has implemented nameif mapping as part of the hotplug process

Thanks to rotvogel for pointing me at the culprit. I haven't got 100% of what I wanted - hotplug isn't working out, but my cards stay where they are supposed to now. The solution is a total hack, but what can you expect from someone with four hours of shell scripting experience?

Solution:

1. Add tg3 and prism54 to /etc/hotplug/blacklist

2. Add alias lines to /etc/modprobe.conf

alias eth0 tg3
alias eth1 prism54

Be sure to align these values with the desired MAC placement in (3).

3. Add a config variable to /etc/rc.d/rc.inet1.conf :

# Config information for eth0:
IPADDR[0]=""
NETMASK[0]=""
USE_DHCP[0]="yes"
DHCP_HOSTNAME[0]=""
MACADDR[0]="00:08:02:EF:2C:53" # Add this line for each card. Put your MAC in here.

# Config information for eth1:
IPADDR[1]=""
NETMASK[1]=""
USE_DHCP[1]="yes"
DHCP_HOSTNAME[1]=""
MACADDR[1]="00:09:5B:792:C6"

# Config information for eth2:
IPADDR[1]=""
NETMASK[1]=""
USE_DHCP[1]=""
DHCP_HOSTNAME[1]=""
MACADDR[1]="" # use empty string for non-configured cards

4. Add some code to /etc/rc.d/rc.inet1 :

( I know, I should learn to use diff and patch - maybe tomorrow)

Position in original code:

if grep eth${1}: /proc/net/dev 1> /dev/null ; then # interface exists
if ! /sbin/ifconfig | grep -w "eth${1}" 1>/dev/null || \
! /sbin/ifconfig eth${1} | grep "inet addr" 1> /dev/null ; then # interface not up or not configured

New code goes in right after the lines above:
<NEW>
echo "/etc/rc.d/rc.inet1: /sbin/nameif eth${1} ${MACADDR[$1]}" | $LOGGER
if [ ! "${MACADDR[$1]}" = "" ]; then
/sbin/nameif eth${1} ${MACADDR[$1]}
fi
</NEW>

5. If you have wireless cards make sure to configure them in /etc/rc.d/rc.wireless.conf

This will probably break something else, but so far it seems to work OK for me. I have only tested the following use cases:

1. Boot machine w/o prism54 - tg3 gets eth0
2. Boot machine w/ prism54 - tg3 gets eth0, prism54 gets eth1
3. Restart network w/ tg3 only - tg3 gets eth0
4. Restart network w/ both - tg3 gets eth0, prism54 gets eth1

Switch the two lines noted below. No sense logging it if the test fails:

New code goes in right after the lines above:
<NEW>
echo "/etc/rc.d/rc.inet1: /sbin/nameif eth${1} ${MACADDR[$1]}" | $LOGGER
if [ ! "${MACADDR[$1]}" = "" ]; then
/sbin/nameif eth${1} ${MACADDR[$1]}
f i
</NEW>

change to :
<NEW>
if [ ! "${MACADDR[$1]}" = "" ]; then
echo "/etc/rc.d/rc.inet1: /sbin/nameif eth${1} ${MACADDR[$1]}" | $LOGGER
/sbin/nameif eth${1} ${MACADDR[$1]}
</NEW>