Thread (6 messages) read the whole thread 6 messages, 2 authors, 2018-03-27

Re: disk-io lockup in 4.14.13 kernel

From: Jaco Kroon <hidden>
Date: 2018-03-27 08:59:14

Hi Bart,
The above call trace means that SysRq-l was triggered, either via the keyboard
or through procfs. I don't think that there is any information in the above
that reveals the root cause of why a reboot was necessary.
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.
What I do myself to identify the root cause of weird kernel behavior is to
rebuild the kernel with a bunch of debugging options enabled and that I try to
repeat the trigger that caused the weird behavior. If this causes the kernel
debugging code to produce additional output that output can be very helpful for
identifying what is going on. This approach does not always work however.
Yea, I find debugging is often an art more than a science.  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 - I've emailed w.r.t. that but I've
not received a response.  Have you managed to get anything more sensible
from them?

Kind Regards,
Jaco
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help