From owner-freebsd-scsi@freebsd.org Tue Feb 9 23:17:36 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DC53AA2CF2 for ; Tue, 9 Feb 2016 23:17:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 13705676 for ; Tue, 9 Feb 2016 23:17:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 12049AA2CE6; Tue, 9 Feb 2016 23:17:36 +0000 (UTC) Delivered-To: scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1186EAA2CE5; Tue, 9 Feb 2016 23:17:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5CC6674; Tue, 9 Feb 2016 23:17:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7C77AB94A; Tue, 9 Feb 2016 18:17:34 -0500 (EST) From: John Baldwin To: Scott Long Cc: Sreekanth Reddy , freebsd-current@freebsd.org, ken@freebsd.org, scsi@freebsd.org Subject: Re: Panic on reloading a driver with same DEVICE_PROBE() return value Date: Tue, 09 Feb 2016 15:02:59 -0800 Message-ID: <1675870.rYHsh4pVC7@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <0C31DEA0-0AD0-4E1B-9656-C6ABB6AA854A@yahoo.com> References: <2227929.z5Tr1XC1Xs@ralph.baldwin.cx> <0C31DEA0-0AD0-4E1B-9656-C6ABB6AA854A@yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 09 Feb 2016 18:17:34 -0500 (EST) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 23:17:36 -0000 On Tuesday, February 09, 2016 03:17:39 PM Scott Long wrote: >=20 > > On Feb 9, 2016, at 3:00 PM, John Baldwin 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