Re: iscsi_trx going into D state

On Tue, 2016-10-18 at 16:13 -0600, Robert LeBlanc wrote:

Nicholas,

We patched this in and for the first time in many reboots, we didn't
have iSCSI going straight into D state. We have had to work on a
couple of other things, so we don't know if this is just a coincidence
or not. We will reboot back into the old kernel and back a few times
and do some more testing, but so far it has given us a little bit of
hope that we may be narrowing down on the root cause. We will report
back once we have some more info.

Thank you,
Robert LeBlanc
----------------
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1

Hello Robert,

Thanks for the update.  Btw, if the original /var/log/messages
reproduction logs for iser-target are still handy, I'm happy to have
a look to confirm.  Feel free to send them along here, or off-list if
necessary.

For further reference, you can also enable Linux kernel crash dump
(LKCD) at build time using CONFIG_CRASH_DUMP=y, so it's possible to
manually generate a vmcore dumpfile of the running system via 'echo c

/proc/sysrq-trigger', once the bug occurs.

http://cateee.net/lkddb/web-lkddb/CRASH_DUMP.html

Note in order to fully debug within this in a LKCD environment, it
requires the vmcore dump from /var/crash/, unstripped vmlinux,
target_core_mod, iscsi_target_mod and ib_isert modules matching the
specific particular x86_64 build setup of the running system.

Also, can you share a bit more about the details of your particular
iser-target + backend setup..?

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html