On 03/27/18 01:59, Jaco Kroon wrote:
I triggered it hoping to get a stack trace of the process which is
deadlocking finding where the lock is being taken that ends up blocking,
but I then realized that you mentioned sleeping, which may end up not
having a stack trace because there is no process actually running? (I'm
not that intimately familiar with kernel internals, mostly doing
user-space development, so kernel is an interesting environment for me
only, but not really part of my day-to-day activities.
Usually I proceed as follows to obtain more information about a lockup:
* Trigger SysRq-w (shows tasks that are in uninterruptible wait state).
* If the output that appears does not provide enough information,
trigger SysRq-t (shows all tasks).
* If it seems like a block layer request got stuck, also analyze the
output of the following command:
find /sys/kernel/debug/block -type f |
grep -vE \
'/(poll_stat|write_hints|completed|merged|dispatched|run|queued)' |
xargs grep -a .
I saw a
patch for the mpt3sas issue but the email was munged and I wasn't able
to apply the patch from the email.
That's weird. Saving that patch ("Save as mbox") and applying it with
"git am" works fine for me. See also
https://www.mail-archive.com/linux-scsi@xxxxxxxxxxxxxxx/msg72175.html.
Because I was too busy during the past two weeks I have not yet had the
time to have a close look at that patch. But I hope to find some time
soon to have a closer look.
Bart.
