Re: sg timeout problem

[Douglas Gilbert]

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




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/