howto determine network device unit number? device.hints?

Brooks Davis brooks at freebsd.org
Thu Jan 15 10:37:44 PST 2009


On Thu, Jan 15, 2009 at 08:07:35PM +0200, Yony Yossef wrote:
> > 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 loading.
> > >
> >
> > 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.
> >
> > with lemonade,
> > BMS
> 
> Sorry for risking the whole community with a massive heart attack Bruce :)
> Yes, I am writing a driver and yes, it still has a bug or two I guess..
> About sharing it with the rest of the class, that's something I wanted
> to ask you guys:  what's the procedure for a 10GigE driver to apply
> for the FreeBSD kernel?

Pretty much just get it working, make sure it's licensed under a BSD,
MIT, or ISC license (ideally, others are possible, but require more
approval), and then find someone to review and commit it or sponsor the
maintainer for a commit bit.  

> Mellanox has started porting it's products to FreeBSD about a year
> ago, hoping to see our 10GigE and InfiniBand drivers inbox next year.

Excellent.

-- Brooks

> 
> Yony
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090115/915111f5/attachment.pgp


More information about the freebsd-net mailing list