On Mon 2009-11-02 06:48:28, Haojian Zhuang wrote:

On Mon, Nov 2, 2009 at 5:38 AM, Pavel Machek [off-list ref] wrote:

quoted

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

quoted

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

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.

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

It seems that we're talking on different issue with similar symptom.
Please check my test method. While I'm testing suspend with devices
level, kernel is blocked in console resume. In this level, it won't
call arch_suspend_enable_irqs(). This function call is only invoked in
processor level or below.

For me, everything but real suspend works. I do _not_ have serial
console for spitz.

Up to now, I can't reproduce the issue you're talking on my platform
yet. I'll check this issue continuously. I also want to know your
hardware information.

Spitz, aka Sharp Zaurus c3000.

Can we get the patch reverted till its fixed, so other development can
continue?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html