On Thu, Jun 21, 2018 at 7:49 PM, Bart Van Assche <Bart.VanAssche@xxxxxxx> wrote: > On Thu, 2018-06-21 at 15:41 +0530, Sreekanth Reddy wrote: >> Bart, we tried using lock_system_sleep() before calling IOC reset >> operation in .resume() callback function and unlock_system_sleep() >> after the IOC reset. With this code change we see system is going to >> hang state during hibernation and we just see below messages, >> >> [ 625.788598] PM: hibernation entry >> Jun 21 05:37:33 localhost kernel: PM: hibernation entry >> [ 627.428159] PM: Syncing filesystems ... >> Jun 21 05:37:34 localhost kernel: PM: Syncing filesystems ... >> [ 628.756119] PM: done. >> [ 628.758707] Freezing user space processes ... (elapsed 0.001 seconds) done. >> [ 628.768340] OOM killer disabled. >> [ 628.772010] PM: Preallocating image memory... done (allocated 197704 pages) >> [ 632.554470] PM: Allocated 790816 kbytes in 3.77 seconds (209.76 MB/s) >> [ 632.561664] Freezing remaining freezable tasks ... (elapsed 0.002 >> seconds) done. >> [ 632.572269] Suspending console(s) (use no_console_suspend to debug) >> >> >> The fix which we have posted looks simple and we don't see any side >> effects of it. >> We have done complete regression testing on our fix and we don't see >> any issue with it. So please consider our fix which have posted. > > scsi_internal_device_block_nowait() can be called by the mpt3sas driver from > interrupt context. lock_system_sleep() locks a mutex and hence must not be > called from interrupt context. Does the above mean that (a) a call to > lock_system_sleep() was inserted in an interrupt handler and No, lock_system_sleep() is not inserted in the interrupt context. we have inserted it in .resume() call back function just before issuing the IOC reset. (b) that the > above test was performed with a kernel in which lockdep was disabled? No, lockdep is enabled in the kernel. ~Sreekanth > > Bart. > > >
