So I've done some more digging.
Turns out that the problem is now that the dld_str_open() is returning
back ENOENT for the 2nd port on my card. I've tracked this down (I
think) to
dev = makedevice(dsp->ds_major, (minor_t)ppa + 1);
if ((err = dls_devnet_hold_by_dev(dev, &ddp)) != 0)
goto failed;
(in dld_str.c).
which ultimately winds up doing:
rw_enter(&i_dls_devnet_lock, RW_WRITER);
if ((err = mod_hash_find(i_dls_devnet_hash,
(mod_hash_key_t)name, (mod_hash_val_t *)&ddp)) != 0) {
ASSERT(err == MH_ERR_NOTFOUND);
rw_exit(&i_dls_devnet_lock);
softmac_rele_device(ddh);
return (ENOENT);
}
What's weird is that it would *appear* that the name is well formed, and
the mac handle looks properly initialized. But it appears that the
i_dls_devnet_hash table doesn't contain my particular device. Now it
looks like Clearview/UV and the softmac are implicated. Is anymore more
familiar with this code?
-- Garret
Nicolas Droux wrote:
Sebastien Roy wrote:
On Tue, 2009-09-08 at 16:03 -0700, Garrett D'Amore wrote:
Before I go off traipsing into the Nemo code, I thought I'd ask
around. Is there any other driver that uses multiple PPAs for a
single dev_info_t?
Yes: aggr and vnic (and the soon to be integrated iptun) all do that.
These have only one instance of a pseudo driver registering multiple
MAC instances, specifying a m_instance of -1 (except for the
aggregation key values for backward compatibility.)
These pseudo drivers then call dls_devnet_create() to tie-in the MAC
instance created with the data link id for the new data link.
What Garrett is doing here seems to be different, i.e. potentially
multiple dev_info_t registering multiple MAC instances, specifying a
non-zero m_instances. In this case the framework is most likely not
tying-in all the new MAC instances with data links.
Nicolas.
Is this a known bug?
Not that I'm aware of.
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
