On Mon, Nov 02, 2009 at 05:22:30AM -0400, Haojian Zhuang wrote:

quoted

quoted

quoted

Ok, got it. The culprit is commit d2c37068 ("[ARM] pxa: initialize
default interrupt priority and use ICHP for IRQ handling"). Reverting it
make suspend/resume work again on my board.

Haojian, Eric, could you have a look at this?

Okay, patch is this one: I'll test reverting it shortly.

commit d2c37068429b29d6549cf3486fc84b836689e122
Author: Haojian Zhuang [off-list ref]
Date: ? Wed Aug 19 19:49:31 2009 +0800

? ? [ARM] pxa: initialize default interrupt priority and use ICHP for IRQ handling

? ? Signed-off-by: Haojian Zhuang [off-list ref]
? ? Signed-off-by: Eric Miao [off-list ref]

And yes, reverting it _does_ fix suspend on spitz.

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Pavel

Em, it's not caused by the IRQ patch.

The kernel is blocked in resume path. When console is resumed, IRQ is
already disabled and system is blocked. Actually, IRQ shouldn't be
disabled at here. Up to now, I only find which patch will cause this
issue. But I can't find the best solution on it. The patch with issue
is pasted in below.

So this issue is only occused when console suspend is enabled. If you
enable no_console_suspend in command, you won't meet this issue. It
seems that it's caused by removing termios setting in
uart_resume_port() in the below patch. If I add these code back, the
issue doesn't occur any more.

Well no, not confirmed. I tested with no_console_suspend, and it still
hit me. And without too, btw.

Daniel