More trouble with USCSICMD support

I appears error code are not returned when sending an USCSICMD command.

To test my theory I took the scsi_util.tgz source code and added
a cmd_unit_ready function. The command send is
USCSI_UNIT_RDY. I took the tape out of the unit and the value
in scsicmd.uscsi_status = USCSI_STATUS_GOOD.

According to all specs I read the value returned should have been
USCSI_STATUS_CHECK.

I also added USCSI_REWIND command and tried it with NO tape in the unit and
I still got USCSI_STATUS_GOOD.

However if I issue the command “tape rewind”, the tape command returns:
“tape: Unable to Issue “rewind” to Tape, Use tape log for detail”.
And tracectrl shows an entry with info that means “MEDIUM NOT PRESENT”

How does tape know about the “problem”, does it sensd a SENSE command
to get fail/pass status for every command it send?

Is scsu_util source wrong about how it get error status?

In article <9j481j$qqh$1@inn.qnx.com> you wrote:
: However if I issue the command “tape rewind”, the tape command returns:
: “tape: Unable to Issue “rewind” to Tape, Use tape log for detail”.
: And tracectrl shows an entry with info that means “MEDIUM NOT PRESENT”
: How does tape know about the “problem”, does it sensd a SENSE command
: to get fail/pass status for every command it send?

“tape” uses the QCTL_RAW_CMD interface (which predates the newer methods,
and actually builds the commands inside the driver itself, rather than
the way the external pass-through methods allow the user to do it - which
is ultimately more flexible but has greater demands on the developer).

You should be able to work it out from <sys/qioctl.h> plus this:

QIC02_MSG_STRUCT qic02ms;
qic02ms.Header.Command = T_READ_STATUS;
qnx_ioctl(fd, QCTL_RAW_CMD,
&qic02ms, sizeof (QIC02_HEADER_STRUCT),
&qic02ms, sizeof (QIC02_LAST_ERROR_STRUCT));

qic02ms.Header.Command = *commandp;
*(long *)qic02ms.Body.Generic.Data = (long)parameter;
qnx_ioctl(fd, QCTL_RAW_CMD,
&qic02ms, sizeof (QIC02_HEADER_STRUCT) + 4,
&qic02ms, sizeof (QIC02_MSG_STRUCT));

“John Garvey” <jgarvey@qnx.com> wrote in message
news:9j77ek$bfo$1@nntp.qnx.com

In article <9j481j$qqh$> 1@inn.qnx.com> > you wrote:
: However if I issue the command “tape rewind”, the tape command returns:
: “tape: Unable to Issue “rewind” to Tape, Use tape log for detail”.
: And tracectrl shows an entry with info that means “MEDIUM NOT PRESENT”
: How does tape know about the “problem”, does it sensd a SENSE command
: to get fail/pass status for every command it send?

“tape” uses the QCTL_RAW_CMD interface (which predates the newer methods,
and actually builds the commands inside the driver itself, rather than
the way the external pass-through methods allow the user to do it - which
is ultimately more flexible but has greater demands on the developer).

You should be able to work it out from <sys/qioctl.h> plus this:

QIC02_MSG_STRUCT qic02ms;
qic02ms.Header.Command = T_READ_STATUS;
qnx_ioctl(fd, QCTL_RAW_CMD,
&qic02ms, sizeof (QIC02_HEADER_STRUCT),
&qic02ms, sizeof (QIC02_LAST_ERROR_STRUCT));

qic02ms.Header.Command = *commandp;
*(long *)qic02ms.Body.Generic.Data = (long)parameter;
qnx_ioctl(fd, QCTL_RAW_CMD,
&qic02ms, sizeof (QIC02_HEADER_STRUCT) + 4,
&qic02ms, sizeof (QIC02_MSG_STRUCT));

Thanks John,

Next on my list is; any way to go around/beyond/above the 8k-1 limit.
I was hoping qnx_ioctlmx would do it, but apparently it doesn’t.

  • Mario

“John Garvey” <jgarvey@qnx.com> wrote in message
news:9j77ek$bfo$1@nntp.qnx.com

In article <9j481j$qqh$> 1@inn.qnx.com> > you wrote:
: However if I issue the command “tape rewind”, the tape command returns:
: “tape: Unable to Issue “rewind” to Tape, Use tape log for detail”.
: And tracectrl shows an entry with info that means “MEDIUM NOT PRESENT”
: How does tape know about the “problem”, does it sensd a SENSE command
: to get fail/pass status for every command it send?

“tape” uses the QCTL_RAW_CMD interface (which predates the newer methods,
and actually builds the commands inside the driver itself, rather than
the way the external pass-through methods allow the user to do it - which
is ultimately more flexible but has greater demands on the developer).

For sake of discussion what about SCSI CD-ROM if I was to issue a read to
a block that doesn’t exists would I also NOT get an error status back???

It seems to me the fact that USCSICMD do not return SCSI error code
is pretty bad no? How can one achieve reliable operation. One can’t use
REQUEST SENSE data to check for error because if there was no error
the data doesn’t have to be updated (implention dependent). I must be
missing
something I can’t beleive the USCSICMD doesn’t deal with this.

The QCTL_RAW_CMD is a crude work around for that limitation, (I will
probably have to deal with CD-ROM support in the futur)

Hey Rennie if you are reading this; I guess this is a case where
architecture
doesn’t make a difference :wink: I’m screwed… Can’t read > 8k-1, and
can’t get error code back from raw SCSI Command. Plus QNX4 development
being forever put on hold, there is hope of having these limitations
removed.

\

  • Mario “badly needing vacation” Charest.