Andrew Henry wrote:
> Tejun Heo wrote:
>> Can you please
>> post the outputs of dmesg after the wake up failure (fdisk -l) and
>> "hdparm --Istdout /dev/sdX"?
>>
> Yepp. Here is the hdparm result (identical for both drives), followed
> by the full dmesg output from boot until one of the drives starts
> failing and then all the messages that come for a while after failure.
> By the way, these are not the latest 'green' drives by Western Digital
> that you hinted at. They are one generation below the green drives, but
> maybe they do have an updated standby feature.
I see. Those green drives do strange things with advanced power
management feature and end up drastically reduce the lifetime. I
wouldn't be too surprised to see its predecessor doing weird things.
> [root@k2 Desktop]# hdparm --Istdout /dev/sdb
> 0040 3fff c837 0010 0000 0000 003f 0000
> 0000 0000 2020 2020 2057 442d 5743 4153
> 5530 3230 3638 3733 0000 0000 0000 3031
> 2e30 3142 3031 5744 204d 7920 426f 6f6b
> 2020 2020 2020 2020 2020 2020 2020 2020
> 2020 2020 2020 2020 2020 2020 2020 8001
> 0000 0b00 4001 0000 0000 0007 3fff 0010
> 003f fc10 00fb 0100 ffff 0fff 0000 0007
> 0003 0078 0078 0078 0078 0000 0000 0000
> 0000 0000 0000 0000 0106 0000 0000 0000
> 0070 001c 0029 7400 4002 0029 3400 4002
> 207f 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 6030 3a38 0000 0000
> 0000 0000 4000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 ab12 8004 c000 0001 0002 0001 0001
> 0000 0002 0000 0000 0000 0000 0001 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0001 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
Hmmm.. it's not setting any serial ata features including DIPM. The
drive shouldn't put the link into powersave mode.
> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata2.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata2.00: status: { DRDY }
> ata2: port is slow to respond, please be patient (Status 0xd8)
> ata2: device not ready (errno=-16), forcing hardreset
> ata2: hard resetting link
> ata2: port is slow to respond, please be patient (Status 0xff)
> ata2: COMRESET failed (errno=-16)
> ata2: hard resetting link
> ata2: port is slow to respond, please be patient (Status 0xff)
> ata2: COMRESET failed (errno=-16)
> ata2: hard resetting link
> ata2: port is slow to respond, please be patient (Status 0xff)
> ata2: COMRESET failed (errno=-16)
> ata2: hard resetting link
> ata2: COMRESET failed (errno=-16)
> ata2: reset failed, giving up
> ata2.00: disabled
Hmmm... it never sends the first D2H FIS. Can you please test the
attached patch and report the kernel log after failure?
Thanks.
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 927b692..97493b8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3477,7 +3477,7 @@ int sata_link_resume(struct ata_link *link, const unsigned long *params,
if ((rc = sata_scr_read(link, SCR_CONTROL, &scontrol)))
return rc;
- scontrol = (scontrol & 0x0f0) | 0x300;
+ scontrol = (scontrol & 0x0f0)/* | 0x300*/;
if ((rc = sata_scr_write(link, SCR_CONTROL, scontrol)))
return rc;
@@ -3532,6 +3532,10 @@ int ata_std_prereset(struct ata_link *link, unsigned long deadline)
const unsigned long *timing = sata_ehc_deb_timing(ehc);
int rc;
+ /* print link status */
+ printk("PRERESET: ");
+ sata_print_link_status(link);
+
/* if we're about to do hardreset, nothing more to do */
if (ehc->i.action & ATA_EH_HARDRESET)
return 0;
