On Mon 2009-11-02 05:22:30, Haojian Zhuang wrote:

On Sun, Nov 1, 2009 at 6:03 PM, Pavel Machek [off-list ref] wrote:

quoted

quoted

Hi!

quoted

quoted

Is anyone using suspend/resume with a recent git mainline kernel on PXA
or other ARM embedded boards? My platform used to suspend and resume
just fine on 2.6.31 but now as I rebased it, it fails the resume part.

Unfortunately, I can't bisect it as the platform is not mainline yet and
so I always have mandatory patches (without my platform won't do
anything) on top of the git repository. Which breaks the bisect logic.

What puzzles me is that I see the current raising at wakeup time, so at
least the processor seems to resume, but I can't see any serial console
output, just like if the kernel crashed very early after wakeup.
'no_console_suspend' didn't help either.

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.

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.

Given that it hangs very early, in arch_suspend_enable_irqs() (see my
other mail), I don't trust your analysis.

Deepak,
Could you help to investigate this issue also?

By the way, the suggested quick test command is in below. If we tried
these commands for 20 times, the issue would occur. I only test it in
PXA silicon. I don't know the symptom on other silicons.
$ echo devices > /sys/power/pm_test
$ echo mem > /sys/power/state

I'm not using serial console on spitz, and I have never had successful
resume with the patch applied.

The original patch is also poorly changelogged. What is the advantage
of ICHP and why do we want default priorities?

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html