Date: Tue, 22 Aug 2000 11:08:26 -0500 (CDT) From: Chris Dillon <cdillon@wolves.k12.mo.us> To: Fred Clift <fred@clift.org> Cc: Dermot McNally <dermot@traveldev.com>, freebsd-stable@FreeBSD.ORG Subject: Re: Numbering of fxp devices Message-ID: <Pine.BSF.4.21.0008221105470.59457-100000@mail.wolves.k12.mo.us> In-Reply-To: <Pine.BSF.4.21.0008220849200.5116-100000@vespa.orem.iserver.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Aug 2000, Fred Clift wrote: > > other way around. The order stayed this way for a couple of weeks during > > which I tracked -stable and made world frequently, but after one > > upgrade, the box came up with the on-board card claiming to be fxp0. > > However, not long afterwards, it reverted to the original behaviour. > > > > Now, obviously the numbering doesn't matter all that much. What _does_ > > matter is if the numbering is unpredictable at boot time (worst case) or > > if it may be reversed after a remote upgrade. Is this down to pure fluke > > or can I lock down the order in some way? > > > I am not directly aware of what recent changes would have caused > the change in probe order, but I can give you some ideas about > where to look and then offer my comments about what I belive would > be ideal. > > in FreeBSD <= 3.X it appears that all pci-to-pci busses were > probed first, and then devices on them were probed in some fixed > order. > > In FreeBSD >= 4.0 the 'newbus' code replaced a lot of the old bus > code including probing and now the buses are probed kind of in a > depth-first fashion, finding all devices on a particular bus and > then moving on to another. Aparently, from your results, the > order that the busses are probed has been changed or something > similar. > > I pitty the guy with whom I exchanged emails a while back that is > running a 6 or 8 port 'router' all with fxp cards. He was running > 3.4 last I knew and was planning on waiting a LONG time before > upgrading to 4.X because of the relative difficulty of figuring > out which cards when where. That would be me, probably. :-) 7 NICs, one of which is dual-port, for a total of 8 ports. I recently moved all of those NICs from a Compaq Proliant 3000 running 3.4-STABLE into a new Proliant ML530 running 4.1-STABLE. The card order is definately weird, but that isn't so much FreeBSD's fault. Compaq was nice enough to label primary, secondary, and tertiary PCI bus slots on the back of the machine, but they aren't in order anyway. What I ended up doing was booting the system with all the cards installed, noting the MAC address of each interface, and then comparing that to physical slot locations. Not as nice as the sequential ordering in the Proliant 3000, but not a big deal either, as long as it doesn't change on me in the future without some warning. :-) > What I would find to be the best of all possible worlds is if you could > wire-down pci-card instances to particular instances of a driver - ie I > want the first card on bus 2 to be fxp0 and the second card on bus 1 to be > fxp1, etc... Of course this would depend on finding the busses in the > right order, but... This would be nice. But, if bus or device ordering changes, you'd still be up the same creek. You'd have to wire things down in a card-specific way and not a bus/slot-specific way. > Unfortunately, I'm, uh, somewhat unexperience in this (and most of the > rest) of the code and when I looked at it, all I got was a headache. How > hard would it be to either provide a consistent mapping or to allow the > hard-wiring of devices to drivers? -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0008221105470.59457-100000>