On Tue, Aug 14, 2012 at 11:44:20AM +0300, Sergei Trofimovich wrote:
> > The only problem I can see is the offending commit didn't do a gtm for
> > IDE channel during init. It was used to be done in
> > ata_acpi_associate_ide_port.
> >
> > So can you please test if the following code fix your problem? Thanks.
>
> Unfortunately, nothing changed. The same hangup after resume.
> Did the bisected patch change the way kernel relies on ACPI
> information? I have some complains in dmesg output about it
> (attached whole dmesg) like that:
>
> ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0x0000000000000004) is beyond
> end of object (20120711/exoparg2-418)
> ACPI Error: Method parse/execution failed [\_SB_.C003.C09A._DOD] (Node
> ffff88007b82c988), AE_AML_PACKAGE_LIMIT (20120711/psparse-536)
> ACPI Exception: AE_AML_PACKAGE_LIMIT, Evaluating _DOD (20120711/video-1149)
> ata1: ACPI get timing mode failed (AE 0x1001)
Do you see this error message when using a working kernel?
And here is another try:
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 902b5a4..fd9ecf7 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -60,17 +60,7 @@ acpi_handle ata_ap_acpi_handle(struct ata_port *ap)
if (ap->flags & ATA_FLAG_ACPI_SATA)
return NULL;
- /*
- * If acpi bind operation has already happened, we can get the handle
- * for the port by checking the corresponding scsi_host device's
- * firmware node, otherwise we will need to find out the handle from
- * its parent's acpi node.
- */
- if (ap->scsi_host)
- return DEVICE_ACPI_HANDLE(&ap->scsi_host->shost_gendev);
- else
- return acpi_get_child(DEVICE_ACPI_HANDLE(ap->host->dev),
- ap->port_no);
+ return acpi_get_child(DEVICE_ACPI_HANDLE(ap->host->dev), ap->port_no);
}
EXPORT_SYMBOL(ata_ap_acpi_handle);
@@ -1101,6 +1091,9 @@ static int ata_acpi_bind_host(struct ata_port *ap,
acpi_handle *handle)
if (!*handle)
return -ENODEV;
+ if (ata_acpi_gtm(ap, &ap->__acpi_init_gtm) == 0)
+ ap->pflags |= ATA_PFLAG_INIT_GTM_VALID;
+
return 0;
}
Thanks,
Aaron
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
