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
