sg_io_hrd_t - host_status error (0x05)

sg_io_hrd_t - host_status error (0x05)

[Liong Hoong]

Hi all,

I have set up the main control structure for the
version 3 SCSI generic driver. I am trying to send
down some opcodes (vendor specific) to a usb mass
storage device. Found that I encountered host_status
error, SG_ERR_DID_ABORT whenever I send opcodes from
0x80 to 0x9f, but encountered no errors with other
opcodes. 

The errors occured even without the device plugged in,
which seem the sg driver has exclusively blocked the
opcodes from 0x80 to 0x9f. Is it true?? Is there any
work around for this??

Is it because of Group 4 (0x80 to 0x9f) need 16 bytes
of cdb length? But even I prepare the cdb of 16 bytes,
it also failed. 

I am using red hat 8.0, 2.4.18. 

Thanks for any helps and comments!
Sean

__________________________________________________
Do You Yahoo!?
Log on to Messenger with your mobile phone!
http://sg.messenger.yahoo.com

Re: sg_io_hrd_t - host_status error (0x05)

[Douglas Gilbert]

Liong Hoong wrote:
> Hi all,
> 
> I have set up the main control structure for the
> version 3 SCSI generic driver. I am trying to send
> down some opcodes (vendor specific) to a usb mass
> storage device. Found that I encountered host_status
> error, SG_ERR_DID_ABORT whenever I send opcodes from
> 0x80 to 0x9f, but encountered no errors with other
> opcodes. 
> 
> The errors occured even without the device plugged in,
> which seem the sg driver has exclusively blocked the
> opcodes from 0x80 to 0x9f. Is it true?? Is there any
> work around for this??
> 
> Is it because of Group 4 (0x80 to 0x9f) need 16 bytes
> of cdb length? But even I prepare the cdb of 16 bytes,
> it also failed. 
> 
> I am using red hat 8.0, 2.4.18. 

The scsi subsystem mid level allowed 16 byte cdbs through
from and including lk 2.4.15 . The sg driver allows them
through. That leaves the usb-storage driver (and drivers
further down the USB stack) and the device itself as the
cause of your problem.

Doug Gilbert

Re: sg_io_hrd_t - host_status error (0x05)

[Liong Hoong]

Hi Douglas Gilbert,

Thanks for commenting on the problem I am facing. I
have few other question,

1) Is it a common error on kernel 2.4.18 where the
host_status error, SG_ERR_DID_ABORT occured whenever
pass through opcodes from 0x80 to 0x9f?

2) Is there any patch to work around this error?

3) Can you point me to any links or codes that have
caused the error?

Thanks for spending time on my doubts.

Best Regards,
Sean

--- Douglas Gilbert <dougg@torque.net> wrote: > Liong
Hoong wrote:
> > Hi all,
> > 
> > I have set up the main control structure for the
> > version 3 SCSI generic driver. I am trying to send
> > down some opcodes (vendor specific) to a usb mass
> > storage device. Found that I encountered
> host_status
> > error, SG_ERR_DID_ABORT whenever I send opcodes
> from
> > 0x80 to 0x9f, but encountered no errors with other
> > opcodes. 
> > 
> > The errors occured even without the device plugged
> in,
> > which seem the sg driver has exclusively blocked
> the
> > opcodes from 0x80 to 0x9f. Is it true?? Is there
> any
> > work around for this??
> > 
> > Is it because of Group 4 (0x80 to 0x9f) need 16
> bytes
> > of cdb length? But even I prepare the cdb of 16
> bytes,
> > it also failed. 
> > 
> > I am using red hat 8.0, 2.4.18. 
> 
> The scsi subsystem mid level allowed 16 byte cdbs
> through
> from and including lk 2.4.15 . The sg driver allows
> them
> through. That leaves the usb-storage driver (and
> drivers
> further down the USB stack) and the device itself as
> the
> cause of your problem.
> 
> Doug Gilbert
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
http://vger.kernel.org/majordomo-info.html 

__________________________________________________
Do You Yahoo!?
Log on to Messenger with your mobile phone!
http://sg.messenger.yahoo.com

Re: sg_io_hrd_t - host_status error (0x05)

[Liong Hoong]

Hi,

Sorry if there is any misunderstanding in my previous
questions.
I would like to ask, 
I am using Linux Red Hat 8.0, kernel 2.4.18. I used
the SG driver version 3 without any modification of
the kernel. I encountered host_status error (0x05)
ONLY on sending opcodes from 0x80 to 0x9f. Can anyone
give me hints on why or which part of the kernel codes
that might failed this specific range of opcodes? Or
is there any work around or patches? Anyone out there
did experience similar problems and like to share with
me?

Thanks,
Sean
 --- Liong Hoong <liongshliongsh@yahoo.com> wrote: >
Hi Douglas Gilbert,
> 
> Thanks for commenting on the problem I am facing. I
> have few other question,
> 
> 1) Is it a common error on kernel 2.4.18 where the
> host_status error, SG_ERR_DID_ABORT occured whenever
> pass through opcodes from 0x80 to 0x9f?
> 
> 2) Is there any patch to work around this error?
> 
> 3) Can you point me to any links or codes that have
> caused the error?
> 
> Thanks for spending time on my doubts.
> 
> Best Regards,
> Sean
> 
> --- Douglas Gilbert <dougg@torque.net> wrote: >
> Liong
> Hoong wrote:
> > > Hi all,
> > > 
> > > I have set up the main control structure for the
> > > version 3 SCSI generic driver. I am trying to
> send
> > > down some opcodes (vendor specific) to a usb
> mass
> > > storage device. Found that I encountered
> > host_status
> > > error, SG_ERR_DID_ABORT whenever I send opcodes
> > from
> > > 0x80 to 0x9f, but encountered no errors with
> other
> > > opcodes. 
> > > 
> > > The errors occured even without the device
> plugged
> > in,
> > > which seem the sg driver has exclusively blocked
> > the
> > > opcodes from 0x80 to 0x9f. Is it true?? Is there
> > any
> > > work around for this??
> > > 
> > > Is it because of Group 4 (0x80 to 0x9f) need 16
> > bytes
> > > of cdb length? But even I prepare the cdb of 16
> > bytes,
> > > it also failed. 
> > > 
> > > I am using red hat 8.0, 2.4.18. 
> > 
> > The scsi subsystem mid level allowed 16 byte cdbs
> > through
> > from and including lk 2.4.15 . The sg driver
> allows
> > them
> > through. That leaves the usb-storage driver (and
> > drivers
> > further down the USB stack) and the device itself
> as
> > the
> > cause of your problem.
> > 
> > Doug Gilbert
> > 
> > -
> > To unsubscribe from this list: send the line
> > "unsubscribe linux-scsi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at 
> http://vger.kernel.org/majordomo-info.html 
> 
> __________________________________________________
> Do You Yahoo!?
> Log on to Messenger with your mobile phone!
> http://sg.messenger.yahoo.com
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
http://vger.kernel.org/majordomo-info.html 

__________________________________________________
Do You Yahoo!?
Log on to Messenger with your mobile phone!
http://sg.messenger.yahoo.com

Re: sg_io_hrd_t - host_status error (0x05)

[Douglas Gilbert]

Liong Hoong wrote:
> Hi,
> 
> Sorry if there is any misunderstanding in my previous
> questions.
> I would like to ask, 
> I am using Linux Red Hat 8.0, kernel 2.4.18. I used
> the SG driver version 3 without any modification of
> the kernel. I encountered host_status error (0x05)
> ONLY on sending opcodes from 0x80 to 0x9f. Can anyone
> give me hints on why or which part of the kernel codes
> that might failed this specific range of opcodes? Or
> is there any work around or patches? Anyone out there
> did experience similar problems and like to share with
> me?

Sean,
I assume that you have already determined (via another OS)
that the device really does accept 16 byte SCSI commands
in that opcode range.

As mentioned in my previous post the 12 to 16 byte cdb
expansion occurred in lk 2.4.15. Maybe the usb-storage driver
took a few versions to catch up. Apart from vendor specific
commands, there would not be a lot of demand for the
usb-storage driver to support 16 byte commands.
Perhaps you should try a more recent version of the linux
kernel. If the problem persists then you are more likely to
get help.

Doug Gilbert

Re: sg_io_hrd_t - host_status error (0x05)

[Liong Hoong]

Hi,

Below is the some coding extracted from the Linux
kernel. It seems that before the opcodes of Group4
(0x80 and 0x9f) able to pass down to the device, the
scsi.c already failed the commands thus yield the
DID_ABORT error. 

Is it possible to edit scsi.c or the host.c to allow
the Group4 opcodes pass down to scsi device. Why is
there having such a restriction in scsi.c/host.c when
the sg drivers is already support of 16 bytes command
size?

scsi.c
/*
 * Macro to determine the size of SCSI command. This
macro takes vendor
 * unique commands into account. SCSI commands in
groups 6 and 7 are
 * vendor unique and we will depend upon the command
length being
 * supplied correctly in cmd_len.
 */
#define CDB_SIZE(SCpnt)	((((SCpnt->cmnd[0] >> 5) & 7)
< 6) ? \
				COMMAND_SIZE(SCpnt->cmnd[0]) : SCpnt->cmd_len)

================================================================================================
scsi.c

/*
	 * Before we queue this command, check if the command
	 * length exceeds what the host adapter can handle.
*/
	if (CDB_SIZE(SCpnt) > host->max_cmd_len) {
		SCSI_LOG_MLQUEUE(3, printk("scsi_dispatch_cmd :
command too long %d(Max %d).\n", CDB_SIZE(SCpnt),
host->max_cmd_len));
		SCpnt->result = (DID_ABORT << 16);
		scsi_done(SCpnt);
		return 1;
	}

=======================================================================================
sg drivers notes

Linux kernel prior to 2.4.15 limited SCSI commands to
a length of 12 bytes. In lk 2.4.15 this was raised to
16 bytes. However unless lower level drivers (e.g.
aic7xxx) indicate that they can handle 16 byte
commands (and few currently do) then the command is
aborted with a DID_ABORT host status.

========================================================================
host.c

/*
     * All drivers right now should be able to handle
12 byte commands.
     * Every so often there are requests for 16 byte
commands, but individual
     * low-level drivers need to certify that they
actually do something
     * sensible with such commands.
*/
    retval->max_cmd_len = 12;

=========================================================================
host.h

/*
     * The maximum length of SCSI commands that this
host can accept.
     * Probably 12 for most host adapters, but could
be 16 for others.
     * For drivers that don't set this field, a value
of 12 is
     * assumed.  I am leaving this as a number rather
than a bit
     * because you never know what subsequent SCSI
standards might do
     * (i.e. could there be a 20 byte or a 24-byte
command a few years
     * down the road?).  
*/

    unsigned char max_cmd_len;

Regards,
Sean

 --- Douglas Gilbert <dougg@torque.net> wrote: > Liong
Hoong wrote:
> > Hi,
> > 
> > Sorry if there is any misunderstanding in my
> previous
> > questions.
> > I would like to ask, 
> > I am using Linux Red Hat 8.0, kernel 2.4.18. I
> used
> > the SG driver version 3 without any modification
> of
> > the kernel. I encountered host_status error (0x05)
> > ONLY on sending opcodes from 0x80 to 0x9f. Can
> anyone
> > give me hints on why or which part of the kernel
> codes
> > that might failed this specific range of opcodes?
> Or
> > is there any work around or patches? Anyone out
> there
> > did experience similar problems and like to share
> with
> > me?
> 
> Sean,
> I assume that you have already determined (via
> another OS)
> that the device really does accept 16 byte SCSI
> commands
> in that opcode range.
> 
> As mentioned in my previous post the 12 to 16 byte
> cdb
> expansion occurred in lk 2.4.15. Maybe the
> usb-storage driver
> took a few versions to catch up. Apart from vendor
> specific
> commands, there would not be a lot of demand for the
> usb-storage driver to support 16 byte commands.
> Perhaps you should try a more recent version of the
> linux
> kernel. If the problem persists then you are more
> likely to
> get help.
> 
> Doug Gilbert
> 
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
http://vger.kernel.org/majordomo-info.html 


__________________________________________________
Do You Yahoo!?
Log on to Messenger with your mobile phone!
http://sg.messenger.yahoo.com