Re: sata suspend resume ...

[Pavel Machek]

Hi!

> > > > System suspends ok. Resume ok. but no disk access after that.
> > > 
> > > Not the same disk model, but I've been having similar trouble on a T43p.
> > 
> > Could you
> > 
> > 1) try if mdelay(2000) also helps?
> > 
> > 2) binary-search on drivers to see which one breaks it?
> 
> Thanks for looking into this.  But we already know mdelay(2000) works
> around it, and that the failure is "ata1: qc timeout (cmd 0xef)"
 > when

Aha, sorry, I was confused.

> trying to resume the SATA disk (in my case, don't know about Jeff's):
> so I'm confused as to what binary search to be doing.  I just tried
> backing out the time.c patch I sent originally, and substituting the
> patch below, much closer to the heart of the problem: that works too.
> This is with ata_piix, by the way; resuming from suspend to RAM.
> Do let me know what else to try if you've got an idea.

Not sure why it needs time. Waiting for disk to spin up?

Will it recover from the timeout? Would sticking ata_set_mode() at the
end of timeout routine help?
								Pavel


> --- 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 13:19:54.000000000 +0100
> @@ -4287,6 +4287,7 @@ static int ata_start_drive(struct ata_po
>  int ata_device_resume(struct ata_port *ap, struct ata_device *dev)
>  {
>  	if (ap->flags & ATA_FLAG_SUSPENDED) {
> +		mdelay(2000);
>  		ap->flags &= ~ATA_FLAG_SUSPENDED;
>  		ata_set_mode(ap);
>  	}

-- 
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/