Re: [PATCH] Re: 2.6.17-rc5-git1: regression: resume from suspend(RAM) fails: libata issue

[Mark Lord <liml@rtr.ca>]

Linus Torvalds wrote:
> 
> On Sat, 27 May 2006, Jens Axboe wrote:
>>> hardware, since the current suspend resumes to silicon defaults rather 
>>> than BIOS defaults (and ata_piix doesn't have a controller reset).
>> Definitely, and we need to cover a lot more controllers than just piix
>> and ahci. Being the selfish bastard that I am, I didn't care much about
>> other devices...
>>
>> diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
>> index fa476e7..28878f4 100644
>> --- a/drivers/scsi/libata-core.c
>> +++ b/drivers/scsi/libata-core.c
>> @@ -4297,6 +4297,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) {
>> +		ata_busy_wait(ap, ATA_BUSY, 200000);
> 
> Btw, it might not be enough to wait for ATA_BUSY to clear.
> 
> I think you should wait for ATA_DRDY to be set too.
> 
> What does it say if you change that "ata_busy_wait()" to
> 
> 	u8 status = ata_wait_idle(ap);
> 	if (!ata_ok(status))
> 		printk("ATA status %02x\n", status);

I got rid of the 500msec delay (not needed on my machine anyway),
and then added the above code *in front of* the ata_busy_wait().

Resume worked, with this output:

May 27 18:03:33 localhost kernel: ATA status 80
May 27 18:03:33 localhost kernel: ata1: dev 0 configured for UDMA/100
May 27 18:03:33 localhost kernel: ATA status 00
May 27 18:03:33 localhost kernel: ata2: dev 0 configured for UDMA/33

Note that the second set are for the DVD-RW drive,
which (being ATAPI) doesn't assert ATA_DRDY.

Cheers