Michael West <[EMAIL PROTECTED]> writes:
>
> I tried passing kernel parameters
>
> ether=11,0x2000,eth0 ether=10,0x4000,eth1 ether=9,0x6000,eth2
Actually, if I read the source right, these aren't having any effect.
They certainly aren't doing what you want them to do: they aren't
determining which physical card gets assigned to which logical
device.
> Now I can only ping all three addresses if eth0 is connected by cable.
> eth1 and eth2 no longer respond though ifconfig output has not changed.
Maybe check again---I believe the machine will behave the same whether
you include that kernel setup string or not. If it's a genuine
effect, see if there's any difference in the kernel log messages
between the two cases.
The behaviour can---in theory---vary from driver to driver, but here's
the way it should work for the eepro100 driver and most other PCI
drivers. Whether the eepro100 driver is loaded as a module or
compiled into the kernel, at some point its initialization function
will be called. The initialization function uses the standard kernel
"pci_module_init()" function which, ultimately, enumerates the PCI
devices in bus/device/function order, the same order you see the
devices if you do a "cat /proc/pci".
At this point, the behaviour can differ from driver to driver, but the
eepro100 driver allocates the next "eth%d" device, binds it to that
card, and overwrites the irq and I/O port base with the correct values
for the card, completely ignoring the values you supplied in the setup
string.
The order *is* deterministic, you just can't determine it using the
kernel setup string---eth0 through eth2 will always be assigned in
bus/device/function order, which means they'll be assigned in order
according to the physical PCI slot.
I believe the person who said most drivers probe in MAC-address order
was mistaken. According to an old mailing list post by Donald Becker:
http://beowulf.es.embnet.org/listarchives/linux-tulip/1999/04/0048.html
the 3c509 driver is unique in activating multiple cards in MAC address
order. The PCI drivers all (?) detect them in PCI bus/device/function
order.
This gets much more complicated if you have PCI cards of multiple
types (they are enumerated in bus/device/function order *within* each
driver, but the order the driver initialization functions are called
depends on the order they're compiled into the kernel, more or less).
If you have (E)ISA legacy cards or certain motherboard chipsets, it's
complicated even further.
> Also if I bring the interfaces down and backup I get an error both
> ways on the last interface. The order of the interfaces does not
> matter.
[ . . . ]
> ifup eth1
> ifup eth0
> ifup eth2
> SIOCADDRT: File exists
You can see which command is generating this by running "ifup" with
the "-v" option. "ifup" implicitly does a:
route add default gw 10.0.1.3 eth0 (or eth1 or eth2)
for each "ifup" with a "gateway 10.0.1.3" line, and I assume that's
the culprit. I don't know why it's working twice but failing the
third time. Again, the "-v" flag might help.
--
Kevin <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
