Re: sata suspend resume ...

[Hugh Dickins <hugh@veritas.com>]

On Fri, 21 Apr 2006, Pavel Machek wrote:
> 
> Not sure why it needs time. Waiting for disk to spin up?

I don't know, and can't hear, but doubt it (I can't see why
it'd need disk spun up just to do an ata_dev_set_xfermode).

> Will it recover from the timeout?

No, after that wait for 30 seconds, it degenerates into attempting I/O,
getting errors, remounting the root readonly, can't get much further.

> Would sticking ata_set_mode() at the end of timeout routine help?

Well, moving the ata_set_mode after the ata_start_drive does help:
then the ata_start_drive times out and fails, but that does not seem
to matter at all, and the ata_set_mode then succeeds and all is well.
I guess that amounts to what you meant; but all the same, I won't be
alone in preferring to wait 2 seconds than 30 seconds!

But you've made me try a bit harder, and the patch below, waiting for
ATA_BUSY to clear, copying a line used in several other places there,
fixes it in a much more satisfactory way than mdelay(2000).  (I checked
how long it in fact was waiting, saw various waits between 0.8s and 1.3s).

This is a patch I'd not be ashamed to send Jeff Garzik cc linux-ide,
even if we can't name precisely why it's ATA_BUSY then.  But I'll
give it a day or so of real-life suspend/resuming first - Arkadiusz
and I both noticed we're more likely to resume successfully after
a brief suspend, so longer suspends are needed for proper testing.

Hugh

--- 2.6.17-rc2/drivers/scsi/libata-core.c	2006-04-19 09:14:11.000000000 +0100
+++ linux/drivers/scsi/libata-core.c	2006-04-21 20:55:48.000000000 +0100
@@ -4288,6 +4288,7 @@ int ata_device_resume(struct ata_port *a
 {
 	if (ap->flags & ATA_FLAG_SUSPENDED) {
 		ap->flags &= ~ATA_FLAG_SUSPENDED;
+		ata_busy_sleep(ap, ATA_TMOUT_BOOT_QUICK, ATA_TMOUT_BOOT);
 		ata_set_mode(ap);
 	}
 	if (!ata_dev_present(dev))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/