howto determine network device unit number? device.hints?
Bruce M. Simpson
bms at FreeBSD.org
Thu Jan 15 09:48:56 PST 2009
Eygene Ryabinkin wrote:
> I wanted to stress only one point: simple 'kldunload <driver>' and
> 'kldload <driver>' makes devices to flip for Yony's case. This means
> that unless some PCI hotplug stuff is here (which I don't believe to be
> present, because no physical cards are touched and there is actually a
> small amount of PCI hotplug support in FreeBSD), no physical PCI devices
> get added or removed from the PCI child tree. It looks like that
> something goes wrong during the PCI tree reprobe on the driver module
BTW: Thanks for looking further at the software layer first.
VIM is a wee bit easier to use than a bus analyzer.
Most motherboards don't support PCI geographical addressing, so... I
wager it's the network driver code which may be the source of the
problem, based on your analysis!
If this code just doing a blind bump of an instance count and using that
as a "unit number"... well, that's OK and expected for software virtual
devices, but is counter-intuitive for something like hardware.
But I don't have any mtnic source, so this is pure speculation on my part.
> Correct me if I am wrong, but pci_driver_added from /sys/pci/pci.c will
> invoke device_get_children() to get the list of the attached devices,
> and for PCI case the list should be static.
Yup, that's right.
> I guess that when Yony will enable verbose boot and will show us kernel
> messages from two successive kldunload/kldload sequences, we will get
> some additional information about what's going on.
Hopefully he will chime in...
[bms does some google searching *before* he thinks about throwing his
toys out of the pram at the Orignal.Poster.]
ding :-) [a light bulb above bms' head]
So... Yony. you're writing a driver.
Maybe there's a bug in it?
That's cool, dude.
Hope it's a nice card and you plan on sharing the sweets with the rest
of the class. ;-)
But seriously, please mention that you are writing a driver in general
questions you might ask about the whole system, otherwise, FreeBSD
volunteers will run around going "Is core code broken?" and that's not
so good for community stress levels as a whole.
More information about the freebsd-questions