None of this blabber of yours solves the problem, so why waste everyone's time? Explaining why its broken is kind of like your mechanic telling you why your brakes sqeak. I dont care why they sqeak, i want them to stop sqeaking. What code needs to be changed to fix it? Im sure Im not the only one who'd like to know. dennis At 06:23 PM 7/20/00 +1200, you wrote: >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 > - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu
