Date: Tue, 09 Feb 2016 15:02:59 -0800 From: John Baldwin <jhb@freebsd.org> To: Scott Long <scott4long@yahoo.com> 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: <1675870.rYHsh4pVC7@ralph.baldwin.cx> In-Reply-To: <0C31DEA0-0AD0-4E1B-9656-C6ABB6AA854A@yahoo.com> References: <CAK=zhgoGwXSsD-mNF=jGov1FJFnpM7m_fZ0Jwsq4JR5yazB%2Bww@mail.gmail.com> <2227929.z5Tr1XC1Xs@ralph.baldwin.cx> <0C31DEA0-0AD0-4E1B-9656-C6ABB6AA854A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, February 09, 2016 03:17:39 PM Scott Long wrote:
>=20
> > 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 requ=
ired 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 loa=
ded from foo.ko"
>=20
>=20
> So the problem wasn=E2=80=99t that the malloc was failing, it was tha=
t sc was pointing to memory
> that the driver didn=E2=80=99t own, so the fault was happening from a=
ssigning 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 enoug=
h signal.
I'm actually not certain of what triggered the fault. The check that e=
mits
the printf should also be failing the kldload with EEXIST (but that doe=
sn't
work for the case where both are compiled into the kernel). The new dr=
iver
should have just never been registered, but then I'm not sure how its m=
ethod
could be called at all. The only reference to the driver's methods are=
in the
struct driver which also has the associated softc size (so you shouldn'=
t get
a mismatch between softc size and the driver methods used).
--=20
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1675870.rYHsh4pVC7>