softmac_destroy() is being passed a dip for a device that doesn't exist
in the softmac_hash:
[1]> $c
...
softmac`softmac_destroy+0x8c(7b23f000, b, 70177c00, 7b23f000, b, 7b23f000)
net_dacf`net_predetach+0x20(600108fb158, 0, 0, 130bc00, 0, 300052a8848)
...
The 1st arg to softmac destroy is incorrect in that output, and we can
extract what was actually passed to it from the dacf_infohdl_t (which is
actually a "struct ddi_minor_data") passed to net_predetach():
[1]> 600108fb158::print "struct ddi_minor_data" dip | ::print "struct
dev_info"
...
devi_instance = 0x2
devi_ops = bge`bge_dev_ops
...
devi_instance is 2, so this is the dip for "bge2". The only node in the
softmac_hash is bge0, not bge2, so it's no wonder that
softmac_destroy()'s call to mod_hash_find() on "bge2" failed:
[1]> *softmac_hash::walk modent | ::modent -v | ::print softmac_head_t
sh_devnam
e
sh_devname = [ "bge0" ]
I still don't know why "bge2" isn't in softmac_hash, but "bge0" still
is... According to dls and mac, both links are still there and registered:
[1]> 30004f04380::walk modent | ::modent -v | ::print dls_link_t dl_name
dl_name = [ "bge0" ]
dl_name = [ "bge2" ]
[1]> 30004f053c0::walk modent | ::modent -v | ::print mac_impl_t mi_name
mi_name = [ "bge0" ]
mi_name = [ "bge2" ]
The only thing I can think of at the moment is that "bge2" was somehow
never added to the softmac_hash to begin with.
-Seb
