On 14-01-07 10:40 AM, Phillip Susi wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 1/7/2014 10:20 AM, Alan Stern wrote:
This raises two questions:
Should the host's resume be allowed to complete while the host is
still in error recovery? Wouldn't it be better to wait until the
recovery is finished?
Ahh, right, my other patch changed the ata_port stuff to schedule the
eh, and return from resume, so that IT doesn't block the system
resume path for a long period of time while IT tries to spin up the
disk. Both the libata and sd layers were spinning up the disk.
Still, the sd request should just wait in the queue until after the
recovery completes shouldn't it?
How does the queue end up in a stopped state? (The stopped queue
explains why blk_peek_request returns NULL.)
I was guessing that was the cause from reading the code, after
stepping through it with gdb and qemu, it turned out it was in
SHOST_RECOVERY rather that stopped. I suppose it may be stopped as
well, so I guess I'll have to go do another debug session and make
sure, but I think that was a red herring.
The flow seems to simply be:
host is in recovery
sd_resume queues REQUEST SENSE
You need to be careful with the SCSI REQUEST SENSE command
when used for getting power management information from
SCSI devices (mainly disks and tape drives).
Many moons ago REQUEST SENSE was used to explicitly fetch
sense data when the previous SCSI command failed and only
yielded a single byte status: CHECK CONDITION.
All modern SCSI transports have "autosense" so the original
semantics of REQUEST SENSE became pointless. So some crafty
folks at T10 decided to re-purpose REQUEST SENSE into what
it is today. That transition has been going on for around
10 years (and may not have finished).
When REQUEST SENSE had its original semantics, TEST UNIT
READY was the only game in town for monitoring power
management. From my reading of spc4r36n.pdf section 5.1.2
"Important commands for all SCSI device servers" TEST UNIT
READY should be called before REQUEST SENSE during device
initialization (including resume). If the responses to TEST
UNIT READY and REQUEST SENSE contradict then the former is
correct.
There are SCSI devices out caught in that transition. For
example with sg_format I monitor progress with either TEST
UNIT READY or REQUEST SENSE, defaulting to the former.
[Progress indication is another new role for REQUEST SENSE.]
Note that the billion or so USB keys out there that say that
they comply with SCSI-2 should respond to a REQUEST SENSE
with its original semantics.
The ATA REQUEST SENSE DATA EXT command refers to the SPC-4
"standard" (not yet it ain't) which is naturally the new
SCSI semantics of REQUEST SENSE. I believe the ATA REQUEST
SENSE DATA EXT command is a relatively new ATA command so
it does not carry the historical baggage of its SCSI
counterpart.
Just a little more hand waving for Phillip's amusement.
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
