At 09:50 PM 19/07/00 -0400, you wrote: >At 06:05 PM 7/19/00 -0400, Donald Becker wrote: >>On Wed, 19 Jul 2000, Dennis wrote: >> >>> With an intel 810E MB with on onboard Intel Controller, using a 1 slot >>> riser card with an eepro100 card in the slot, Linux detects the card in the >>> pci slot as eth0 and the onboard LAN controller as eth1 (clearly not what >>> you want).....other O/Ss properly detect the onboard controller first. >> >>This *is* what you want. And an O/S that detect the on-motherboard >>interface first is backwards. >> >>This is the same situation as a PCI video card. A plugged-in video card >>should be used in preference to the built-in one. > > >I whole-heartedly disagree. With no cards in the box, the on-board port is >port 0. With a card in, it changes, which makes it wrong. Adding a device >should not change the port designation of the first device. The folks at >'BSD and windoze disagree with you also. Really ? I presume you mean the same Microsoft who decided that drives should be numbered using letters of the alphabet and that adding a second hard drive should bump the CD-ROM drive letter from D to E, or that when you have a first hard drive with primary and secondary partitions C and D, and you add a second hard drive with a primary partition that the new drive should become D bumping the second partition of the first drive to E. Or perhaps you mean the Microsoft that decided that LPT ports would always be counted from LPT1 regardless of what address they were set to - so adding a port at 3BC bumps along the "standard" LPT1 on 378 to LPT2. I consider the drive lettering issue a *MAJOR* hassle, with the LPT port numbering a minor irritation which sometimes means relabeling the printer port sockets. I consider the numbering of ethernet interface names in linux as similar to the labeling of LPT ports - slightly irritating when it catches you out, but hardly a big issue. >its pretty difficult to label an enclosure when the port changes depending >on what cards you have in the box. > >How can the behavior be modified? >[........] >With an SBC system, Linux detects the on-board controller first, and then >the card. However with this MB, it detects the card first. Inconsitency is >worse than doing it wrong all the time...... But its not inconsistant - theres nothing random about the detection order of ethernet cards, it just may not happen to be quite what you or I would like. While it probably seems obvious on the surface that the onboard controller should be first, I can see two reasons why it might not be. Firstly its a matter of preference, some people may think that an add in interface should take priority, which I agree with in most cases, for example, a video card or sound card which is overriding onboard video or sound. Theres nothing more annoying than having a machine where you cant replace or substitute some onboard feature with a card. The second point is I'd say its probably not always *possible* to tell what hardware is onboard and what has been added as a card. An onboard network "card" looks like a normal PCI device to the operating system, so how is it to know the difference ? Or how about another case - you have a single PCI network card installed, as eth0, then you add another identical one. The same instance of the driver detects and supports both cards. Is the new card to become eth0 or eth1 ? How does the OS know which is the "new" card ? (In fact, it doesnt) Obviously we cant have the order chosen randomly each time we boot, so there has to be some deterministic way of deciding which card is first with a given hardware combination. For identical PCI network cards the driver simply uses the PCI bus numbering of the card - so it depends on the physical order of the cards. The problem here is that although the ordering is consistent on a given motherboard, some motherboards reverse the order of the PCI slots. So even then you cant always win. See the problem ? Regards, Simon - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu
