> 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. ScottReceived 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