[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1190379599.3213.8.camel@chaos>
Date: Fri, 21 Sep 2007 14:59:59 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jaroslav Kysela <perex@...e.cz>, Takashi Iwai <tiwai@...e.de>,
linux-usb-devel@...ts.sourceforge.net,
Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
Ingo Molnar <mingo@...e.hu>, miklos@...redi.hu,
Len Brown <len.brown@...el.com>,
David Shaohua Li <shaohua.li@...el.com>
Subject: Re: 2.6.23-rc6-mm1: failure to boot on HP nx6325, no sound when
booted, USB-related WARNING
Rafael,
On Fri, 2007-09-21 at 00:30 +0200, Rafael J. Wysocki wrote:
> > -ETOOTIRED led me too a wrong conclusion, but still it is a valuable
> > hint that this change is making things work again.
>
> Yes, it is.
>
> > I need to go down into the details of the swsusp_suspend() code path to
> > figure out, what's the root cause.
>
> If you need any help from me with that, please let me know.
I'm zooming in. It seems, that the ACPI idle code plays tricks with us.
After debugging the swsusp_suspend() code path I figured out, that we
end up in C2 or deeper power states while we run the suspend code. The
same happens when we come back on resume. It looks like we disable stuff
in the ACPI BIOS, which makes the C2 and deeper power states misbehave.
I hacked the idle loop arch code to use halt() right before we call
device_suspend() and switch back to the acpi idle code right after
device_resume(). This solves the problem as well.
Len, any opinion on this one ?
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists