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-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
