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.
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 >> >
