Garrett D'Amore wrote: > Over the course of history, I've learned that sometimes the breakpoint > on a function entry doesn't always get triggered. Adding 4 or 8 to the > function entry (_init+4:b) may show different results. > > _init is surely the first thing called in any kernel module. Put a > cmn_err() debug message if you really want to see it.
After changing my breakpoints to the format suggested by Dan Mick, my breakpoints started working. I added in a couple of cmn_err's to double-check the inner workings of _init and _info; nothing seems out of place. This is basically what is happening when update_drv is called: _init is invoked; returns 0 (indicates success) _info is invoked; returns 1 (indicates success) _fini is invoked; void dnet_probe and dnet_attach are never called. DTrace has not yielded much of anything useful: dtrace -n 'fbt:dnet::entry' only fires on _info entries. Any ideas? Steve -- Yet magic and hierarchy arise from the same source, and this source has a null pointer. Reference the NULL within NULL, it is the gateway to all wizardry. _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
