Re: Panic on reloading a driver with same DEVICE_PROBE() return value

From: Scott Long <scott4long_at_yahoo.com>
Date: Tue, 9 Feb 2016 15:17:39 -0700
> On Feb 9, 2016, at 3:00 PM, John Baldwin <jhb_at_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
Received on Tue Feb 09 2016 - 21:23:55 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:02 UTC