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 (b) that the above test was performed with a kernel in which lockdep was disabled? Bart.
