Jane Chu wrote:
> Hi, Garrett,
>
> Garrett D'Amore wrote:
>> The case looks pretty good now, and I'm almost ready to issue a +1,
>> but I have one question, which concerns the pm-capable attribute. I
>> think other HBAs might be using this property. Has the project team
>> verified that no other consumers exist? Or if the 16-th bit is not
>> set in the new mask value, does it behave in the old fashion?
> The improvement of the "pm-capable" property is backwards compatible
> with all existing HBA drivers
> with-in and with-out ON. If the 16-th bit is not set, it would behave
> in the old fashion, that is, sd would
> skip checking the Log page 0Eh and honor the PM capability. There are
> existing HBAs that do not
> set bit 16, such as USB SCSI, 1394 SCSI.
(That was exactly my concern! :-) With that, +1.
- Garrett
>
> thanks,
> -jane
>
>
>>
>> - Garrett
>>
>> Terry (Sarito) Whatley wrote:
>>> I'm restarting this case as a fast-track, timing out
>>> 7/1/09.
>>>
>>> The project team has removed all of the interfaces which
>>> do not have current consumers from this case.
>>> In particular the pm-* properties which described the
>>> attributes of the different power states, and the new
>>> argument "dip" to pm_trans_check(9F) are removed.
>>>
>>> The case now just brings the disk IO stack power
>>> management up to date with new transport types
>>> (particularly SATA).
>>>
>>> Below is a summary and some explanation to help make
>>> the case more obvious.
>>>
>>> Summary
>>>
>>> This case is now composed of 4 parts.
>>> 1. a property used to communicate between the transport layer
>>> and the target driver code (sd) about what support the
>>> device has for power management features,
>>> eliminating the need for the target driver to know which
>>> transport is being used and which commands it supports.
>>> 2. extend pm_trans_check(9F) support to SATA devices
>>> 3. a tunable used to override information that disk/transport
>>> HW might present;
>>> 4. a USCSI flag to allow power management to stop FMA from
>>> bringing up a power managed disk to see if it is ok.
>>>
>>> Explanation
>>>
>>> 1. target-transport communication property (pm-capable)
>>>
>>> The sd/scsa system is designed to allow the target driver (sd)
>>> not to have to know about the details ofthe transport used to
>>> control the drive (one of SCSI, SATA, SAS, FCAL, IEEEE-1394,
>>> USB, etc.), and the transport driver not to have to know
>>> the details of the target device.
>>>
>>> Unfortunately, there are several different schemes for
>>> identifying and controlling the power states of a disk,
>>> depending on the transport and the set of power states supported
>>> by the disk, and to provide access to information about how many
>>> power cycles the disk has experienced (so that they can be meted
>>> out over the desired lifetime of the disk and not squandered
>>> immediately upon putting the disk in service).
>>>
>>> In particular, for control the current options are the
>>> Start field of the Start Stop Unit command, and the
>>> Power Condition field of the Start Stop Unit command.
>>> For getting the start-stop history information, the options
>>> are check or ignore log page 0Eh, and to expect (if not
>>> ignored) for log page 0Eh to contain SMART attribute data
>>> or SCSI native log page 0Eh information.
>>>
>>> The pm-capable property is extended to communicate this
>>> information to the target driver.
>>>
>>> This information is needed to allow the sd driver to
>>> support the existing autopm framework behavior on the new
>>> transports.
>>>
>>> This scheme was worked out by/in collaboration with the owners of
>>> all of the drivers involved. While the specific values in
>>> this property may not be obvious to those not familiar with the
>>> detailed specs of the various transports, I submit that using
>>> a property which already conveys related information to convey
>>> this info rather than perturbing the scsa/sd interface is obvious.
>>>
>>>
>>> 2. pm_trans_check change
>>>
>>> The modification of pm_trans_check() allows for the slightly
>>> different flavor of information (native SCSI vs. SMART)
>>> provided by different transports to be used in making power
>>> down decisions.
>>>
>>>
>>> 3. tunable
>>>
>>> Sometimes the firmware is buggy and lies about the capabilities
>>> of the device. The "power-condition" tunable allows a way to
>>> override the information presented by firmware for a specific
>>> device identified by Product ID and Vendor ID.
>>>
>>>
>>> 4. USCSI_PMFAILFAST flag
>>>
>>> There is a problem where an FMA disk health checking thread spins
>>> up disks periodically to test device status. This flag allows
>>> for the device driver to not spin up the device to get this
>>> information.
>>>
>>> The full text of the new proposal is in the materials directory as
>>> "proposal".
>>>
>>> thanks,
>>> sarito
>>>
>>
>
