ide-scsi cmd_per_lun

ide-scsi cmd_per_lun

[Tony Battersby]

I have encountered another problem with ide-scsi.  My userspace program has
the sg device for an IDE tape drive open multiple times so that it can have
multiple outstanding commands.  The tape drive itself (like most tape
drives) does not support multiple outstanding commands.  The driver should
send the commands one at a time to the drive; having multiple outstanding
commands is merely a convenience for my program.

Let me use a concrete example to illustrate the problem.  I have /dev/sg0
open twice, yielding two file descriptors.  To the first file descriptor I
send a read(6) command, and then to the second file descriptor I send a test
unit ready command.  The ide-scsi driver sends the read command, which after
a several second medium access delay, returns CHECK CONDITION because of an
ILI (incorrect block size).  Next the ide-scsi driver sends the test unit
ready command.  Finally, the ide-scsi driver sends a request sense command
to recover the sense data from the read command's CHECK CONDITION.  This
obviously doesn't work as intended, since the test unit ready command has
reset the sense data.

The problem boils down to the fact that ide-scsi relies on the mid-level
(old eh) to do the auto-sense.  I was able to work around this problem by
setting cmd_per_lun: 1 in ide-scsi.h (vanilla 2.4.17).  Doing this caused
the request sense command to make it to the drive before any other command
could sneak in and reset the sense data.  Can anyone tell me if this is a
good solution?  Looking at the 2.4.19-rc1 source, I see an additional field
"can_queue: 10" in the template.  Should this be changed too?  I cannot use
2.4.19 for the moment, so I can't experiment with it.

Thanks,
Anthony J. Battersby
Cybernetics

Re: ide-scsi cmd_per_lun

[Doug Ledford]

On Tue, Jul 09, 2002 at 05:18:31PM -0400, Tony Battersby wrote:
> 
> The problem boils down to the fact that ide-scsi relies on the mid-level
> (old eh) to do the auto-sense.  I was able to work around this problem by
> setting cmd_per_lun: 1 in ide-scsi.h (vanilla 2.4.17).  Doing this caused
> the request sense command to make it to the drive before any other command
> could sneak in and reset the sense data.  Can anyone tell me if this is a
> good solution?

It is the appropriate setting for any driver that doesn't automatically 
request sense itself on check condition status returns.  It does not solve 
the problem for tagged queue enabled devices though since they don't honor 
this field and will loose sense information, so in reality any driver that 
doesn't auto request sense data is broken to some extent.  The new eh code 
requires that drivers auto request sense, so this is actually likely to be 
really broken in 2.5 at the moment since the old eh code is now gone.

>  Looking at the 2.4.19-rc1 source, I see an additional field
> "can_queue: 10" in the template.  Should this be changed too?  I cannot use
> 2.4.19 for the moment, so I can't experiment with it.

No, this is only for the host wide queue, so if you had 5 ide-scsi devices 
that showed up, this limits the total number of commands sent to the 
ide-scsi driver to 10, which would be 2 each.  Obviously, this is 
different than what you are trying to set and is only limited by what the 
ide-scsi driver can actually handle in terms of outstanding commands at a 
time.

> 
> Thanks,
> Anthony J. Battersby
> Cybernetics
> 
> -
> 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

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606