What a great issue... As a service technician; - I *hate* onboard adapters that won't disable. Instead of solving a dead onboard resource by plugging in an adapter card, I gotta either go get the replacement motherboard, at $$$, or toss the whole system. $$$ either way. - I *hate* software that can't figure out which resource is first. And I hate software that just makes up its mind, leaving me no real choice in the matter. In other words, the developers are damned if they do and damned if they don't. If I can go in and config the system to choose my way, fine. Ever try running linuxconf on a system with a bad primary video adapter? Life is too short. Sometimes, I just take the drive out and put in something that's working, edit away, and reinstall it. Yeah. wait till it reverts and some poor bugger has to deal with it. I hate myself, too. Mr. Becker has a good point. If an adapter appears, it should be assumed that it's there to take over for the built-in resource. Let the user force the choice, if they want to. Dennis has a good point too. It's nonintuitive for the built-in resource to be secondary. So, if logical is the rule of the day, much else is broken too. I know this sounds like the ravings of a madman. Us blades of grass just thought you elephants might be humored at our confusion. The debate is fascinating. Now I know why I'm not a programmer. Rick At 7/19/00 09:50 PM, Dennis 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. > >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? > > > >>There is a simple solution. Configure your adapters to match the detection >>order. > >thats not a solution. This is not a "make it work" issue. Its an issue that >makes linux unsuitable as is for a rather common application > >> >>There is *no* semantic signifcance to the "eth0" name. It is just a name. >>Names are used to simplify the identification. In one of our old >>configurations, we used the Ethernet address to look up the IP address in >>/etc/ethers. With this approach the interface could be name "eth0" or >>"fizbot23", it just didn't matter. The downside is that doing this makes >>configuration *much* more obscure for the common single-interface >>configuration. > >Try to sell a modular product with that philosophy..... > >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...... > >is this a driver or OS issue? > >Dennis > >- >: 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
