Re: iscsi_trx going into D state

Nicholas A. Bellinger
2016-10-19T06:25:59Z

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..?