Hi Thomas, On Tue, May 20, 2014 at 10:44 PM, Thomas Glanzmann <thomas@xxxxxxxxxxxx> wrote: > Hello Harry, > >> http://pastebin.com/AqqJaYVX > > I checked my log from 11th October last year when this happened to me, > and for me it looks like the same error we're hitting: > > ... > Oct 11 11:53:56 node-62 kernel: [219465.151250] ABORT_TASK: Sending TMR_TASK_DOES_NOT_EXIST for ref_tag: 5488 > Oct 11 11:53:56 node-62 kernel: [219465.151261] ABORT_TASK: Found referenced iSCSI task_tag: 5494 > Oct 11 11:53:56 node-62 kernel: [219465.151264] ABORT_TASK: ref_tag: 5494 already complete, skipping > Oct 11 11:53:56 node-62 kernel: [219465.151267] ABORT_TASK: Sending TMR_TASK_DOES_NOT_EXIST for ref_tag: 5494 > Oct 11 11:53:56 node-62 kernel: [219465.151271] ABORT_TASK: Found referenced iSCSI task_tag: 5495 > Oct 11 11:53:56 node-62 kernel: [219465.151273] ABORT_TASK: ref_tag: 5495 already complete, skipping > Oct 11 11:53:56 node-62 kernel: [219465.151275] ABORT_TASK: Sending TMR_TASK_DOES_NOT_EXIST for ref_tag: 5495 > Oct 11 11:54:09 node-62 kernel: [219478.744212] TARGET_CORE[iSCSI]: Detected NON_EXISTENT_LUN Access for 0x00000008 > Oct 11 11:54:09 node-62 kernel: [219478.751738] ABORT_TASK: Sending TMR_TASK_DOES_NOT_EXIST for ref_tag: 5508 > Oct 11 11:54:23 node-62 kernel: [219492.351282] TARGET_CORE[iSCSI]: Detected NON_EXISTENT_LUN Access for 0x00000013 > Oct 11 11:54:23 node-62 kernel: [219492.358819] ABORT_TASK: Sending TMR_TASK_DOES_NOT_EXIST for ref_tag: 5514 > Oct 11 11:54:23 node-62 kernel: [219492.630489] TARGET_CORE[iSCSI]: Detected NON_EXISTENT_LUN Access for 0x0000001d > ... > > Full log here: https://thomas.glanzmann.de/crash/extracted_crash_dmesg.log > > I'll try to reproduce it and let the list know when I find something. > Harry, can you let me know how many VM's you had running and if they > were thin or thick provisioned and if they're idle or they had a heavy > workload. > > In my case I did _not_ use jumbo frames, but 802.3ad bonding. My > switches are configured to be able to deliver jumbo frames. > > Cheers, > Thomas Indeed, it seems that we hit the same issue as the log lines look pretty similar. Our setup was comprised of around 7-10 VMs powered on with some activity (not too intense), and if I recall correctly some VM deployments (through OVF/OVA) had been made prior to the failure. Obviously, there are no discrete steps to reproduce the problem... I hope this can help reproduce the problem in your environment as it's kind of difficult for me to make changes in our production one (e.g. to recompile the kernel with debug on). Thanks! Regards, Harry -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
