Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Jan 2009 20:07:35 +0200
From:      "Yony Yossef" <>
To:        "Bruce M. Simpson" <>
Cc:        Liran Liss <>,, Oleg Kats <>, "H.fazaeli" <>, Eitan Shefi <>,,
Subject:   Re: howto determine network device unit number? device.hints?
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <000b01c9768e$745aa160$> <> <000c01c976ec$87e040b0$> <> <> <+b/MqS4l8z9bOD9y4AZP70mtFL0@kjaK+/sQ5DW5981v71UogZJPf/0> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
> 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,

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?

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


Want to link to this message? Use this URL: <>