Joachim Worringen wrote:
which it now does. But I think there should be no difference, as the
differentiation between misc and driver module is within the "ops"
entry, right?
Also, it typically does unload, but just sometimes refuses to do so.
I'll check if the behaviour changes now.
O.k., got this problem again with the described patch again.
dtracing modunload command gives:
....
0 <- devfs_clean 1096389rc = 0x0 (0)
0 -> modunrload 3
0 -> mod_hold_by_id 4
0 -> mod_circdep 5
0 <- mod_circdep 211rc = 0x0 (0)
0 -> mod_hold_by_modctl 5
0 <- mod_hold_by_modctl 236rc = 0x0 (0)
0 <- mod_hold_by_id 35934rc =
0xffffff0151b19140 (-1093846068928)
0 -> moduninstall 4
0 <- moduninstall 10rc =
0x10 (16)
0 -> mod_release_mod 4
0 -> mod_release 5
0 <- mod_release 156rc = 0x0 (0)
0 <- mod_release_mod 4887rc = 0x0 (0)
0 <- modunrload 55748rc =
0x10 (16)
0 -> modunload_end 3
0 <- modunload_end 25rc = 0x0 (0)
0 <- modunload 1185219rc =
0x10 (16)
which can only mean (as no other function calls are reported within
moduninstall()) that one of the conditions checked in at the start
of moduninstall is not fulfilled:
if (mp->mod_prim || mp->mod_ref || mp->mod_nenabled != 0)
return (EBUSY);
(see
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/modctl.c#moduninstall)
However, looking at strut modctl afterwards shows that these three
member variables are all 0:
r...@d0 # echo "0xffffff0151b19140::print struct modctl" | mdb -k
mdb: failed to load walk genunix`task: walk name already in use
{
mod_next = 0xffffff0151b14c88
mod_prev = 0xffffff0151b190a0
mod_id = 0x114
mod_mp = 0xffffff0149046500
mod_inprogress_thread = 0
mod_modinfo = 0
mod_linkage = .XA$BAAB3Kd2Jkpp.modlinkage
mod_filename = 0xffffff0151b170e8 "misc/dis_mbox"
mod_modname = 0xffffff0151b17318 "dis_mbox"
mod_busy = '\0'
mod_want = '\0'
mod_prim = '\0'
mod_ref = 0
mod_loaded = '\001'
mod_installed = '\001'
mod_loadflags = '\0'
mod_delay_unload = '\0'
mod_requisites = 0xffffff0152d7b5f8
__unused = 0
mod_loadcnt = 0x6
mod_nenabled = 0
mod_text = 0xfffffffff83a8170
mod_text_size = 0x153a8
mod_gencount = 0x6
mod_requisite_loading = 0
}
And all modules that depend on this one are unloaded (dis_dx is the
hardware driver, dis_irm another device module):
r...@d0 # modinfo | grep dis_
157 fffffffff8ad0000 7e7d0 271 1 dis_dx (Dolphin DX 1.1.0 (rev 27143))
160 fffffffff8624000 5a898 272 1 dis_irm (Dolphin IRM (DX)3.3.2
November )
276 fffffffff83a8170 171d8 - 1 dis_mbox (Dolphin 3.5.0d- 3237)
Any idea what prevents the module from being unloaded?
Joachim
--
Joachim Worringen, Software Architect, Dolphin Interconnect Solutions
phone ++49/(0)228/324 08 17 - http://www.dolphinics.com
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
