Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Jan 2009 15:01:37 +0000
From:      "Bruce M. Simpson" <bms@FreeBSD.org>
To:        Yony Yossef <yonyossef.lists@gmail.com>
Cc:        Liran Liss <liranl@mellanox.co.il>, freebsd-net@freebsd.org, Oleg Kats <oleg@mellanox.co.il>, "'H.fazaeli'" <fazaeli@sepehrs.com>, Eitan Shefi <eitans@mellanox.co.il>, freebsd-questions@freebsd.org
Subject:   Re: howto determine network device unit number? device.hints?
Message-ID:  <496F4FD1.4080602@FreeBSD.org>
In-Reply-To: <496F34D2.7050605@FreeBSD.org>
References:  <20def4870901140009y1f007108y92797d5f79ffac08@mail.gmail.com>	<496E11B7.3010608@sepehrs.com>	<000b01c9768e$745aa160$220f000a@mtl.com>	<496EF30E.4010304@sepehrs.com>	<000c01c976ec$87e040b0$220f000a@mtl.com> <496F34D2.7050605@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Yony,

Bruce M. Simpson wrote:
>>
>> And how come the unit number is given an arbitrary value? Is there a 
>> good
>> reason for that?
>>   
> ...
>
> In your case I'm not sure why your two cards would flip order. Could 
> it be how your BIOS and hardware set up the PCI IDSEL lines at boot?

If this is the case on your system, then you really need to provide more 
data about your hardware, i.e. motherboard, BIOS, vendor information 
etc. as others point out.

Based on the data you've provided about the issue to date, my best guess 
is that something in the above is different on your system (which is why 
I mentioned IDSEL lines -- the mechanism PCI uses to actually assign bus 
numbers electrically).

Normally the behaviour of FreeBSD's bus probes is well known -- nexus is 
walked for child buses, then these buses are plumbed into NEWBUS, e.g. 
cpu0...cpuN on nexus itself, PCI buses, and PCI subordinate buses in 
that order.

* You mention you don't encounter the issue with Linux, but you may 
already be aware that udev can tie driver instance number(s) to specific 
MAC addresses, although this process isn't fully automatic and any given 
distro may or may not create the persistent udev rules on a first run -- 
so this is comparing apples with oranges.

* [PCI-Express is a special case though, and I've had to sit down and do 
some work with commercial clients to make sure their appliance was able 
to detect devices being in particular slot numbers. Again, though, it's 
just as subject to the PCI enumeration order further up on the bus 
hierarchy as non-PCI-Express drivers.]

So your issue may not be a simple matter of "this seems wrong, this 
doesn't work", though I am sorry to hear it isn't working for you right now.

There are a lot of dynamic factors in the overall picture of the system, 
and what seems to work as expected for many users, may not be working 
for you, and we really need basic hardware information, when folk see 
things like this happening, for any volunteer(s) out there to come up 
with the right solution, let alone the true picture of what's actually 
going on in your specific case.

thanks
BMS



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?496F4FD1.4080602>