Eric Lee Green wrote:
>
> [snip]
>
> one thing, I'm having trouble getting sensible sense data out of the SCSI
> generic device, sigh... if I use SCSI_IOCTL_SEND_COMMAND and send
> 'READ_ELEMENT_STATUS' to a disk drive, the low-level SCSI device driver
> sensibly returns 'INVALID_REQUEST' in the sense data, but the write()/read()
> process, same SCSI command, to the SCSI generic device associated with the
> drive returns no error code at all?!?!).
Eric,
What the scsi generic driver (sg) will yield in terms of scsi error
codes depends on which version you are using. If you are using
a kernel prior to lk 2.2.6 then the result code in the sg_header
is almost useless and the way people detected sense errors was
exactly as you have described: zero fill the sense buffer and
see if anything non-zero emerges there after the read().
>From and including lk 2.2.6, target_status, host_status and
driver_status were added. The sg.h file notes:
unsigned char sense_buffer[SG_MAX_SENSE]; /* [o] Output in 3 cases:
when target_status is CHECK_CONDITION or
when target_status is COMMAND_TERMINATED or
when (driver_status & DRIVER_SENSE) is true. */
The last one is quite subtle and arises when a pseudo adapter
(e.g. ide-scsi) wants to manufacture a scsi error. [Perhaps
Eric Y. could think about how this case could be folded
back into the normal scsi status byte.] The other tricky
thing about target_status is that it is shifted 1 bit from
the normal scsi status byte value. So CHECK_CONDITION has
the value of 1 (rather than the SCSI II standard's value of
2) in the file /usr/src/linux/include/scsi/scsi.h . Does
anyone know the original rationale for this? Perhaps this
oddity should be noted in that header file and another set
of "standard" defines put there with "SCSI_" prepended to
them.
There is also a potential mismatch between the header files
/usr/include/scsi/sg.h and
/usr/src/linux/include/scsi/sg.h
which can lead to confusion. [ ../scsi/scsi.h can also
become a problem for a similar reason.] The gnu glibc
group maintain the first file while the second one belongs
to the linux kernel. Several distributions over the last 15
months have had these 2 files out of "sync". This has lead to
people trying to use facilities of sg that weren't really
there.
Anyway this stuff is documented in
/usr/src/linux/Documentation/scsi-generic.txt . Having worked
on both sg and the SCSI_IOCTL_SEND_COMMAND ioctl I would be
surprised if you got a (scsi) check_condition from the ioctl
and _not_ a CHECK_CONDITION from target_status in sg for the
same operation. If you think this is the case could you send
a code snippet demonstrating this directly to me, please.
Good to read (in another posting) that the sg_utils package
helped you find a solution.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
