Created attachment 21527 [details] lspci output this commit commit 19bde778c1fd2574cc020a618d7d576f260271ca Author: Len Brown <len.brown@intel.com> Date: Fri May 8 00:22:29 2009 -0400 ACPI: suspend: don't let device _PS3 failure prevent suspend causes resume to fail on my ASUS P5K. Reverting this patch makes resume work again.
Created attachment 21542 [details] dmesg output Got this dmesg output of a working kernel (2.6.30-rc6-git-00026-g0f6f49a + this hunk) @@ -110,8 +110,13 @@ static int pnpacpi_disable_resources(struct pnp_dev *dev) /* acpi_unregister_gsi(pnp_irq(dev, 0)); */ ret = 0; - if (acpi_bus_power_manageable(handle)) - acpi_bus_set_power(handle, ACPI_STATE_D3); + if (acpi_bus_power_manageable(handle)) { + ret =acpi_bus_set_power(handle, ACPI_STATE_D3); + if (ret) { + printk("--------acpi pnp returned %d\n", ret); + return ret; + } + } /* continue even if acpi_bus_set_power() fails */ if (ACPI_FAILURE(acpi_evaluate_object(handle, "_DIS", NULL, NULL))) ret = -ENODEV; Please note that the printk does not trigger. Since dmesg contains "ACPI handle has no context!" the first if might be even false - will check. In that case we have a change in behaviour: in one case acpi_evaluate_object is called, in the other case it is not. Dont know if that matters.
I did some more tests. Seems that the resume failure cannot be triggered reliably. Sometimes it works with Lens patch. I have to consider that the bisect pinpointed the wrong patch. Lets close this problem until I have better evidence. :-( Christian