Re: sg timeout problem

[Douglas Gilbert <dgilbert@interlog.com>]

Norman Diamond wrote:
>>> But if sg is running on top of an actual SCSI driver, someone aborts the
>>> ioctl after 3 seconds.  The ioctl returns success even though the
>>> operation didn't complete.  I tried this with two Adaptec drivers and 
>>> one
>>> NinjaSCSI driver with 100% repro.
>>>
>>> What am I missing?  I need the call to run to completion.
>>
>> If you set it to the max of a signed int does it behave, or to a large
>> value thats well under the limit. That will help tell if there is a
>> problem with sign handling in the scsi code somewhere or it is getting
>> multiplied up for some reason.
> 
> I have the impression now that the drives are lying and it's not the fault
> of the drivers or cards.  The same problem occured with a fourth card and a
> non-Linux system.
> 
> Anyway I also tried changing the timeout to 86400000 milliseconds (one day)
> and it made no difference.  So again I stop blaming the drivers.

Norman,
I'm not sure what version or distro of Linux you have
but I just did this quick test on Ubuntu 9.04 in which
a kernel tick seems to be around 4 milliseconds:

$  uname -a
Linux zink 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 
GNU/Linux
$
$ modprobe scsi_debug delay=1000
$ lsscsi -g
[7:0:0:0]    disk    Linux    scsi_debug       0004  /dev/sdb   /dev/sg2

$ time sg_readcap /dev/sg2
Read Capacity results:
    Last logical block address=16383 (0x3fff), Number of blocks=16384
    Logical block length=512 bytes
Hence:
    Device size: 8388608 bytes, 8.0 MiB, 0.01 GB

real	0m3.999s
user	0m0.000s
sys	0m0.000s
$


See 'modinfo scsi_debug' for more about the arguments to the
scsi_debug driver. If the delay is too long then the kernel
may timeout registering the pseudo device. I picked 4 seconds
because you noted a failure above 3 seconds. The timeout on
sg_inq is set at 60 seconds.

Doug Gilbert