Date: Tue, 9 Feb 2016 15:17:39 -0700 From: Scott Long <scott4long@yahoo.com> To: John Baldwin <jhb@freebsd.org> Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com>, freebsd-current@freebsd.org, ken@freebsd.org, scsi@freebsd.org Subject: Re: Panic on reloading a driver with same DEVICE_PROBE() return value Message-ID: <0C31DEA0-0AD0-4E1B-9656-C6ABB6AA854A@yahoo.com> In-Reply-To: <2227929.z5Tr1XC1Xs@ralph.baldwin.cx> References: <CAK=zhgoGwXSsD-mNF=jGov1FJFnpM7m_fZ0Jwsq4JR5yazB%2Bww@mail.gmail.com> <CAK=zhgpjD2aF-XNiSG6AHojJm1gxvARXTc2enrnoQzLHe=WksA@mail.gmail.com> <CAK=zhgpSH73-AJKdiipHo9UAkTaGHs8=LPnKmYRgNs7-xAYFJQ@mail.gmail.com> <2227929.z5Tr1XC1Xs@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Feb 9, 2016, at 3:00 PM, John Baldwin <jhb@freebsd.org> wrote:
>=20
> On Tuesday, February 09, 2016 05:45:38 PM Sreekanth Reddy wrote:
>> Hi,
>>=20
>> While debugging more, I got one more clue,
>>=20
>> =
--------------------------------------------------------------------------=
---------------------
>> static driver_t mps_pci_driver =3D {
>> "mpr",
>> mps_methods,
>> sizeof(struct mps_softc)
>> };
>>=20
>> static devclass_t mps_devclass;
>> DRIVER_MODULE(mpr, pci, mps_pci_driver, mps_devclass, 0, 0);
>> =
--------------------------------------------------------------------------=
-----------------------
>>=20
>> 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.
>=20
> 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:
>=20
> "module_register: cannot register pci/mpr from blah.ko; already loaded =
from foo.ko"
So the problem wasn=E2=80=99t that the malloc was failing, it was that =
sc was pointing to memory
that the driver didn=E2=80=99t 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=E2=80=99s a kernel
printf, like you said, but that=E2=80=99s apparently not a good enough =
signal.
Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0C31DEA0-0AD0-4E1B-9656-C6ABB6AA854A>