On Sat, Jan 22, 2011 at 2:10 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>
> I have a theory, which is that on failing runs your system doesn't even try
> to enter S3 and it's trying to enter a bogus S1 instead.
Hmm. I can certainly believe in the "BIOS is confused" idea, but I
don't see where that gets us.
> The reason why I think so is that the "Back to C!" message is not present in
> the failing log
It's not present in the good logs either.
> A couple of things may be done to verify this. First, before suspending for
> the first time after a reboot, you can check if there's "standby" in
> /sys/power/state (it shouldn't be there, because your "good" dmesg says S1
> isn't supported).
No, just "mem".
> Second, after a failing run that was revived by a key press
> you can check if there's S1 instead of S3 in the "ACPI: Preparing to enter
> system sleep state ..." message.
Nope, all log messages say S3.
> Finally, which I suspect is the case, it is
> possible that we don't even try to enter S1, but something confuses the BIOS
> which thinks it should go into S1 although it's told to go into S3.
Now this I can believe in.
> Now, if the BIOS is confused, I have no idea what may be the reason, but I
> think it would be good to rule out the change from ioremap() to
> ioremap_cache() in ACPI (as I said before, it's sufficient to modify
> include/linux/acpi_io.h for this purpose so that ioremap() is called by
> acpi_os_ioremap() - unless you have done that already in which case sorry for
> the noise).
Tried it. First boot was fine, second boot had the "press key to make
suspend continue" problem on the first suspend, and then (as
apparently always happens after that half-suspend) locked up
completely on the second.
Oh well.
Linus
--
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
