Aboo Valappil wrote:
> Hi Stefan Richter,
>
> Thanks everyone for their advice on this. As per your advice, I did the
> following when the last user space target serving the scsi_host quits,
> the queue command will do the following on the new commands coming through.
>
> sc->result = DID_NO_CONNECT << 16;
> sc->resid = sc->request_bufflen;
> set_sensedata_commfailure(sc); ---------------------
> This sets the sense buffer with Device Not ready/Logical Unit
> Commincation failure.
> done(sc);
>
> The scsi_host will remain in the kernel. Let the EH thread handle the
> queued commands (If any). If the user target wants to reconnects to the
> same scsi_host, it can do so (Just re-run the user space target again
> with same command line paramters). This connection from newly started
> target will make the HBA healthy again and start serving IO.
>
> I implemented a new IOCTL to remove this scsi_host if the user
> process really needs to. This removal will first finish all the SCSI
> commands (With the above status results) queued on the scsi_host (If at
> all) and then remove the scsi_host. Also the module unload will delete
> all the scsi_hosts created after finishing all the commands queued with
> the above status and sense information.
>
> I also implemented passing of sense code information from user space to
> sense_buffer. A little more work needs to be done on this.
> Also, I need to make sure that all the locking used inside is correctly
> implemented to prevent dead locks and improve efficiency.
>
> The new version is available http://vscsihba.aboo.org/vscsihbav204.gz
A few observations from testing this version:
# ./start_target.sh id=3 -files ../../zz_lun0 -v
# lsscsi
[0:0:0:0] disk Linux scsi_debug 0004 /dev/sda
[1:0:0:0] disk VirtualH VHD 0 /dev/sdb
So "id=3" doesn't look the target identifier. If not, what
is it?
Here is an attempt to fetch the Read Write Error Recovery
mode page:
# sdparm -p rw -vv /dev/sg1
inquiry cdb: 12 00 00 00 24 00
/dev/sg1: VirtualH VHD 0
mode sense (10) cdb: 5a 00 01 00 00 00 00 00 08 00
mode sense (10): Probably uninitialized data.
Try to view as SCSI-1 non-extended sense:
AdValid=0 Error class=0 Error code=0
>> Read write error recovery mode page [0x1] failed
That implies a sense buffer full of zeroes. The debug
output from start_target.sh associated with that attempt:
SCSI cmd Lun=00 id=2D CDB=12 00 00 00 24 00 00 00 08 00 00 00 00 00 00 00
SCSI cmd Lun=00 id=2D completed, status=0
SCSI cmd Lun=00 id=2E CDB=5A 00 01 00 00 00 00 00 08 00 00 00 00 00 00 00
SCSI cmd Lun=00 id=2E completed, status=2
SCSI cmd Lun=00 id=2F CDB=03 00 00 00 FC 00 00 00 08 00 00 00 00 00 00 00
SCSI cmd Lun=00 id=2F completed, status=0
SCSI cmd Lun=00 id=30 CDB=00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00
SCSI cmd Lun=00 id=30 completed, status=0
So that is an INQUIRY [expected], MODE SENSE(10) [expected],
REQUEST SENSE [what, no autosense??] and TEST UNIT READY
[ah oh, error recovery??] sequence.
Perhaps you could examine the way scsi_debug (or most
other LLDs) does autosense. This modern technique (used
for about the last 12 years) relieves the scsi midlevel
of having to send a follow up REQUEST SENSE.
It would be easier to read those SCSI commands in the
debug output if they were trimmed to their actual lengths
(e.g. the INQUIRY is 12 00 00 00 24 00).
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
