I think this commit is somehow related to that problem:
commit 14216561e164671ce147458653b1fea06a4ada1e
Author: James Bottomley <jbottom...@parallels.com>
Date: Wed Jul 25 23:55:55 2012 +0400
[SCSI] Fix 'Device not ready' issue on mpt2sas
This is a particularly nasty SCSI ATA Translation Layer (SATL) problem.
SAT-2 says (section 8.12.2)
if the device is in the stopped state as the result of
processing a START STOP UNIT command (see 9.11), then the SATL
shall terminate the TEST UNIT READY command with CHECK
CONDITION
status with the sense key set to NOT READY and the additional
sense code of LOGICAL UNIT NOT READY, INITIALIZING COMMAND
REQUIRED;
mpt2sas internal SATL seems to implement this. The result is very
confusing
standby behaviour (using hdparm -y). If you suspend a drive and
then send
another command, usually it wakes up. However, if the next command
is a TEST
UNIT READY, the SATL sees that the drive is suspended and proceeds
to follow
the SATL rules for this, returning NOT READY to all subsequent
commands. This
means that the ordering of TEST UNIT READY is crucial: if you send
TUR and
then a command, you get a NOT READY to both back. If you send a
command and
then a TUR, you get GOOD status because the preceeding command woke
the drive.
This bit us badly because
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5056d21b.6060...@gmail.com
