Re: REQ_PM vs REQ_TYPE_PM_RESUME

[Douglas Gilbert <dgilbert@interlog.com>]

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