While debugging more, I got one more clue,

static driver_t mps_pci_driver = {
        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.


On Tue, Feb 9, 2016 at 2:55 PM, Sreekanth Reddy
<sreekanth.re...@broadcom.com> wrote:
> On Mon, Feb 8, 2016 at 11:58 PM, John Baldwin <j...@freebsd.org> wrote:
>> On Monday, February 08, 2016 08:13:26 PM Sreekanth Reddy wrote:
>>> sc->facts = malloc(sizeof(MPI2_IOC_FACTS_REPLY), M_MPR, M_ZERO|M_NOWAIT);
>> M_NOWAIT can fail with NULL.  Normally in an attach routine you should use a
>> blocking malloc (M_WAITOK) which will not fail with NULL.
> Yes I agree that in an attach routine we should to use a blocking
> malloc (M_WAITOK) flag.
> But, here I am observing same page fault even with (M_WAITOK) flag.
> Here, page fault is occurring inside the malloc function and driver is
> not receiving any NULL or any other value.
>>> * How can I reload the modified driver with return same device_probe()
>>> value as the one which has loaded during the OS boot time. I observed
>>> that whenever I try to load this modified driver using "kldload
>>> ./mpr.ko" command then I see that driver in the /boot/kernel/ path has
>>> executed.
>> At runtime you can use the devctl(8) command on HEAD (it will be included
>> in 10.3) to force a device to detach/attach to force a re-probe.
>> e.g.
>> devctl detach mpr0
>> # note that the device won't be named mpr0, you will need to use its PCI
>> # location for this next:
>> devctl attach pci0:4:0:0
> I have started downloading the current kernel. I will verify this
> today/tomorrow.
>> --
>> John Baldwin
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to