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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
