Robert Hancock wrote: > Matthew Garrett wrote: >> On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote: >>> On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr <andi@xxxxxxxx> wrote: >>>> ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index >>>> (0FFFFFFFF) is beyond end of object [20070126] >>>> ACPI Error (psparse-0537): Method parse/execution failed >>>> [\_SB_.PCI0.IDE0.GTF_] (Node c180b990), AE_AML_PACKAGE_LIMIT >>>> ACPI Error (psparse-0537): Method parse/execution failed >>>> [\_SB_.PCI0.IDE0.CHN0.DRV1._GTF] (Node c180b888), AE_AML_PACKAGE_LIMIT >>>> ata1.01: _GTF evaluation failed (AE 0x300d) >> >> 037f6bb79f753c014bc84bca0de9bf98bb5ab169 ought to have fixed this? >> > > I should think it should have. > > I think we're too aggressive about disabling the libata ACPI support, > even. One of my laptop's _GTF commands on resume is a DEVICE > CONFIGURATION FREEZE LOCK command, which gets rejected by the drive > (maybe it worked on the original Hitachi disk, but I've upgraded it to a > newer Samsung). I'd say if the drive returns command aborted on one of > these, we should just ignore that command and continue to the next one > without trying to retry or disabling the ACPI support entirely. Yeap, my pending patchset does exactly that. It's currently being tested by but reporters. I'll soon post the patchset. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
