This message is from the T13 list server.
Although PMACK is clearly defined, PMNAK has two meanings (15.4.9): "PMACK is sent in response to a PMREQ_S or PMREQ_P when a receiving node is prepared to enter a power mode state. PMNAK is sent in response to a PMREQ_S or PMREQ_P when a receiving node is not prepared to enter a power mode state or when power management is not supported." The originator is required to do something when it receives PMACK: "The PMREQ_P primitive is sent continuously to enter Partial power management state until PMACK or PMNAK is received. When PMACK is received, current node (host or device) will stop PMREQ_P and enters the Partial power management state. The PMREQ_S primitive is sent continuously to enter Slumber power management state until PMACK or PMNAK is received. When PMACK is received, current node (host or device) will stop PMREQ_S and enters the Slumber power management state." However, there is no rule about what to do if the originator receives a PMNAK. Should it keep sending PMREQ_n (for how long?) or should it stop? If the recipient does not support the request, the bus could hang exchanging PMREQ_n/PMACKs. No timeout is specified. If the recipient is just temporarily not ready, it will eventually complete. These additions might help: * add IDENTIFY DEVICE data indicating whether the device supports receiving PMREQ_P/PMREQ_S, to let the host know if it is should even try to make a request. * add a way (via SET FEATURES?) to enable/disable a device from sending PMREQ_P/PMREQ_S on its own and advise it how to handle PMNAKs. These additions would let PMNAK assume the "temporary" meaning and let the PMREQ_n originator retry indefinitely, knowing that it will eventually be accepted (if IDENTIFY DEVICE/SET FEATURES meant it was supposed to send the request). -- Rob Elliott, [EMAIL PROTECTED] Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott
