lkml.org 
[lkml]   [2009]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Possible suspend/resume regression in .32-rc?
From
On Mon, Nov 2, 2009 at 5:38 AM, Pavel Machek <pavel@ucw.cz> wrote:
> On Mon 2009-11-02 05:22:30, Haojian Zhuang wrote:
>> On Sun, Nov 1, 2009 at 6:03 PM, Pavel Machek <pavel@ucw.cz> 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.

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.

Thanks
Haojian


\
 
 \ /
  Last update: 2009-11-02 11:51    [from the cache]
©2003-2011 Jasper Spaans