Aravind Parchuri wrote: > My log messages were getting all mixed up, so I cleaned up my little > test to send just one command at a time. It actually looks like the mid > layer passes the command through to open-iscsi with the right size the > first time, but then it sends a second command with request_bufflen = 0. > > I can verify that the command completed on the target just like the > regular ones did, so there should be no reason for a retry of any sort. > > Here's the log for a 32896 byte command: > Mar 9 11:27:43 ITX000c292c3c8d kernel: sg_open: dev=0, flags=0x802 > Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_add_sfp: sfp=0xcbadc000 > Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_build_reserve: req_size=32768 > Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_build_indirect: > buff_size=32768, blk_size=32768 > Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_add_sfp: bufflen=32768, > k_use_sg=1 > Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_ioctl: sg0, cmd=0x2285 > Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_common_write: scsi > opcode=0x3b, cmd_size=10 > Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_start_req: dxfer_len=32896 > Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_build_indirect: > buff_size=32896, blk_size=33280 > Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_write_xfer: num_xfer=32896, > iovec_count=0, k_use_sg=2 > Mar 8 11:27:43 ITX000c292c3c8d kernel: iscsi_queuecommand: opcode 3b > request_bufflen 32896 transfersize 32896 Did you add your own output? Could you enable iscsi debugging? What kernel is this with and what versions of open-iscsi (upstream or svn or tarball release)? - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
