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. ~Sreekanth On Tue, Feb 9, 2016 at 2:55 PM, Sreekanth Reddy <sreekanth.reddy_at_broadcom.com> wrote: > On Mon, Feb 8, 2016 at 11:58 PM, John Baldwin <jhb_at_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 BaldwinReceived on Tue Feb 09 2016 - 11:15:40 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:02 UTC