Steven Stallion wrote:
> 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.
That suggests a failure to match the device with hardware. Send the
contents of prtconf -vp along with grep dnet /etc/driver_aliases and
grep dnet /etc/path_to_inst
>
> DTrace has not yielded much of anything useful: dtrace -n
> 'fbt:dnet::entry' only fires on _info entries.
Well, if the bus driver (PCI) can't match the device properly, attach
won't get called.
-- Garrett
>
> Any ideas?
>
> Steve
>
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
