Tejun Heo wrote:
Mark Lord wrote:
Further to this, if I have an active-writer running at the time of suspend,
then even my scripted "sleep 1" is not good enough, as additional writes
are still happening before/after the flush.
Now I'll reboot and try it with the "sleep 1" hardcoded inside
sd_suspend().
Hmmm... queue quiescing might be broken. Can you verify there's no
command issued between STANDBYNOW1 and suspending?
Yeah, I verified that already. Nothing happens other than
the FLUSH_CACHE_EXT and STANDBY commands.
I've now tried adding various sleeps into the sd_suspend() routine.
The sleeps actually do sleep, but they don't seem to solve the problem there.
The "hdparm -F /dev/sda ; sleep 1" inside my script actually works better,
though even it fails if there's a ton of writes happening.
I put a 4-second sleep in front of the sd_start_stop_device() call,
and here is what I observed:
the disk light flickers briefly,
then the system does absolutely nothing for the 4-seconds,
and then it flickers again,
and then the light comes on solid for a second or two,
and then it suspends.
I am ssssoooooooo confused now. :)
We need Eric (from Seagate) to enlighten us.
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
