Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
..
FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook)
increments the "Power-Off_Retract_Count" on each suspend-to-RAM operation.
It does not do any double spin-up/spin-down things though.
Hmmm.. It shouldn't. libata now issues STANDBYNOW prior to entering
STR. Can you instrument code a bit and see whether it actually gets
issued?
Heh.. I haven't instrumented it yet, but I did discover a bit more about it:
The Power-Off_Retract_Count incrmenents *only* when there's data in the
on-drive write-cache. So if I haven't written anything significantly large
before suspending, then it often does NOT increment the retract counter.
But if I copy a couple of multi-MB files around and then suspend (to RAM),
the retract count gets incremented.
So I've now just stuck "hdparm -F /dev/sda" into my suspend script,
and that cures the problem completely for me. "-F" does a FLUSH_CACHE,
and requires a recent copy of hdparm.
Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW command,
prior to entering STR, which is what my script is currently now doing..
I'll instrument libata and see what the current sequence is.
Okay, instrumented it and all of that now.
Yes, sd + libata-scsi send the proper FLUSH_CACHE_EXT and STANDBY1 commands
immediately prior to the suspend-to-RAM, and there are no other commands
sneaking through at the same time. Good.
But the retract count still increments if I've recently written a signficant
amount of data.
My suspend script now has this little chunk of code at the point
where it actually does the suspend-to-RAM:
sync; sync
hdparm -F /dev/sda ## flush drive write cache
sleep 1 ## allow time for the flush to complete
echo mem > /sys/power/state ## suspend-to-RAM
Without the "sleep 1", it doesn't always eliminate the extra Retract,
so I hypothesize that the FLUSH_CACHE_EXT command is implemented in
an asynchronous fashion by the drive: it returns immediately before
it has actually completed writing cached data to disk. The "sleep 1"
seems to give it enough time to finish up, at least for me.
Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
