Douglas Gilbert wrote:
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?
This is just an identification for the scsi_host created inside the
kernel. If you re-run the same command again with same id, the new
process would attach to the same scsi_host. This can be seen as two user
process serving the same virtual host bus adapter. If use a different
id with the same lun file, It will create a new scsi_host and it would
appear as the same LUN on a different host bus adapter.
.
It is not the target.
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.
I shall look in the sdebug and see how it handles the Auto sense. What
is the scsi target does not give any sense informationx with a non zero
SCSI response?
Can I just make one up? I have modified it to give a sense of SK=06
(Illegal request), ASC=20(Invalid command Op code). May be looking at
the sdebug may give an idea.
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).
I will make it look better.
Doug Gilbert
-
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
