Guessing that this bug might be the same as the one I'm seeing, I've reproduced it here with tgtd running under gdb. In my case, the drive actually vanished completely underneath the md because it got so upset! I see a null pointer dereference in bs_rdwr_request(): Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 6871] bs_rdwr_request (cmd=0x8077ce8) at bs_rdwr.c:98 98 if (((cmd->scb[0] != WRITE_6) && (cmd->scb[1] & 0x8)) || (gdb) p cmd $1 = (struct scsi_cmd *) 0x8077ce8 (gdb) p cmd->scb $2 = (uint8_t *) 0x0 What's odd is that switch(cmd->scb[0]) didn't fail back on line 70, but was valid and equal to WRITE_* or we wouldn't have got there. length and ret are both 524288 here for what it's worth. I tried using a device mapper zero target becoming error target, but couldn't reproduce the segfault with this. This isn't code I'm at all familiar with, so I hesitate to suggest what might be going on. Cheers, Chris. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
