> On Feb 9, 2016, at 3:00 PM, John Baldwin <j...@freebsd.org> wrote:
>
> On Tuesday, February 09, 2016 05:45:38 PM Sreekanth Reddy wrote:
>> Hi,
>>
>> While debugging more, I got one more clue,
>>
>> -----------------------------------------------------------------------------------------------
>> static driver_t mps_pci_driver = {
>> "mpr",
>> mps_methods,
>> sizeof(struct mps_softc)
>> };
>>
>> static devclass_t mps_devclass;
>> DRIVER_MODULE(mpr, pci, mps_pci_driver, mps_devclass, 0, 0);
>> -------------------------------------------------------------------------------------------------
>>
>> in the above code snip-set, if I changed "DRIVER_MODULE" line as
>> DRIVER_MODULE(mpr3, pci, mps_pci_driver, mps_devclass, 0, 0);
>> (i.e. from "mpr" to "mpr3") then I am not observing any panic and I
>> can load & unload the mpr driver multiple times.
>
> Oh, that might be required, yes. DRIVER_MODULE uses its arguments to define
> a module name (in this case as "pci/mpr") and module names are required to
> be unique. I believe you should be getting a printf warning about this on
> the console. Something like:
>
> "module_register: cannot register pci/mpr from blah.ko; already loaded from
> foo.ko"
So the problem wasn’t that the malloc was failing, it was that sc was pointing
to memory
that the driver didn’t own, so the fault was happening from assigning
sc->facts. Is there
something that can be done to make this problem more obvious? I know there’s a
kernel
printf, like you said, but that’s apparently not a good enough signal.
Scott
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
