From: rui.zhang@intel.com (Zhang Rui)
To: linux-arm-kernel@lists.infradead.org
Subject: [Bug] ARM: mxs: STI: console can't wake up from freeze
Date: Sat, 05 Nov 2016 19:39:32 +0800 [thread overview]
Message-ID: <1478345972.2206.15.camel@intel.com> (raw)
In-Reply-To: <322177156.158733.9867e3e7-5710-4844-a098-6f44bd852a6d.open-xchange@email.1und1.de>
On Sat, 2016-11-05 at 12:07 +0100, Stefan Wahren wrote:
> Hi,
>
> [add Rui]
>
> >
> > Russell King - ARM Linux <linux@armlinux.org.uk> hat am 1. November
> > 2016 um
> > 10:23 geschrieben:
> >
> >
> > On Mon, Oct 31, 2016 at 08:54:33PM +0100, Stefan Wahren wrote:
> > >
> > > [??366.696043] INFO: task ext4lazyinit:70 blocked for more than
> > > 120 seconds.
> > > [??366.703046]???????Not tainted 4.9.0-rc1 #7
> > > [??366.707188] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> > > disables
> > > this
> > > message.
> > > [??366.715161] ext4lazyinit????D c05aa6ac?????0????70??????2
> > > 0x00000000
> > This looks like a very different problem - I guess one for ext4
> > people.
> >
> i investigated the issue more further. This trace wasn't
> representative, because
> the stacktrace is different in most cases. The "endless loop" is
> located in
> freeze_enter(). So i added some debug messages:
>
is this a regression?
> -------------------------------->8-----------------------------------
> -
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index 1e7f5da..079c08d 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -67,17 +67,20 @@ static void freeze_enter(void)
> ? spin_unlock_irq(&suspend_freeze_lock);
> ?
> ? get_online_cpus();
> + pr_info("PM: calling cpuidle_resume()\n");
> ? cpuidle_resume();
> ?
> ? /* Push all the CPUs into the idle loop. */
> + pr_info("PM: calling wake_up_all_idle_cpus()\n");
> ? wake_up_all_idle_cpus();
> - pr_debug("PM: suspend-to-idle\n");
> + pr_info("PM: suspend-to-idle\n");
> ? /* Make the current CPU wait so it can enter the idle loop
> too. */
> ? wait_event(suspend_freeze_wait_head,
> ? ???suspend_freeze_state == FREEZE_STATE_WAKE);
> - pr_debug("PM: resume from suspend-to-idle\n");
> + pr_info("PM: resume from suspend-to-idle\n");
> ?
> ? cpuidle_pause();
> + pr_info("PM: called cpuidle_pause()\n");
> ? put_online_cpus();
> ?
> ? spin_lock_irq(&suspend_freeze_lock);
> @@ -91,6 +94,8 @@ void freeze_wake(void)
> ?{
> ? unsigned long flags;
> ?
> + pr_info("PM: freeze_wake()\n");
> +
> ? spin_lock_irqsave(&suspend_freeze_lock, flags);
> ? if (suspend_freeze_state > FREEZE_STATE_NONE) {
> ? suspend_freeze_state = FREEZE_STATE_WAKE;
>
> -------------------------------->8-----------------------------------
> -
>
> and repeated the test cases for freeze which shows none the
> representative
> stacktraces:
>
> 1. cmdline contains no_console_suspend
>
> * echo freeze > /sys/power/state
>
> ...
> [??139.371308] PM: suspend of devices complete after 1342.721 msecs
> [??139.385203] PM: late suspend of devices complete after 7.668 msecs
> [??139.399428] PM: noirq suspend of devices complete after 7.936
> msecs
> [??139.406639] PM: calling cpuidle_resume()
> [??139.410619] PM: calling wake_up_all_idle_cpus()
> [??139.415339] PM: suspend-to-idle
>
> >
> > >
> > > >
> > > > no reaction to input via Debug UART
> [??366.683570] INFO: task bash:373 blocked for more than 120 seconds.
> [??366.689814]???????Not tainted 4.9.0-rc1-dirty #14
> [??366.694705] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this
> message.
> [??366.702685] bash????????????D c05aa6ec?????0???373????275
> 0x00000000
> [??366.709227] [<c05aa6ec>] (__schedule) from [<c05aaff8>]
> (schedule+0x3c/0xbc)
> [??366.716495] [<c05aaff8>] (schedule) from [<c005b588>]
> (suspend_devices_and_enter+0x888/0xa78)
> [??366.725228] [<c005b588>] (suspend_devices_and_enter) from
> [<c005bea4>]
> (pm_suspend+0x72c/0x81c)
> [??366.734150] [<c005bea4>] (pm_suspend) from [<c005a008>]
> (state_store+0x80/0xcc)
> [??366.741554] [<c005a008>] (state_store) from [<c02f0270>]
> (kobj_attr_store+0x18/0x1c)
> [??366.749515] [<c02f0270>] (kobj_attr_store) from [<c01911e8>]
> (sysfs_kf_write+0x48/0x4c)
> [??366.757735] [<c01911e8>] (sysfs_kf_write) from [<c0190308>]
> (kernfs_fop_write+0xfc/0x1d0)
> [??366.766130] [<c0190308>] (kernfs_fop_write) from [<c011f578>]
> (__vfs_write+0x2c/0x124)
> [??366.774255] [<c011f578>] (__vfs_write) from [<c011f724>]
> (vfs_write+0xb4/0x1a4)
> [??366.781640] [<c011f724>] (vfs_write) from [<c011f8e8>]
> (SyS_write+0x44/0x88)
> [??366.788890] [<c011f8e8>] (SyS_write) from [<c000a2c0>]
> (ret_fast_syscall+0x0/0x1c)
> [??366.796627]
> [??366.796627] Showing all locks held in the system:
> [??366.803011] 2 locks held by khungtaskd/10:
> [??366.807149]??#0: [??366.808931]??(
> rcu_read_lock[??366.811784] ){......}
> , at: [??366.814813] [<c0093a40>] watchdog+0xb4/0x61c
> [??366.819128]??#1: [??366.820902]??(
> tasklist_lock[??366.823876] ){.+.+..}
> , at: [??366.826765] [<c0051dbc>] debug_show_all_locks+0x28/0x1bc
> [??366.832151] 4 locks held by bash/373:
> [??366.835973]??#0: [??366.837765]??(
> sb_writers[??366.840365] #4
> ){.+.+.+}[??366.842987] , at:
> [??366.845079] [<c011f804>] vfs_write+0x194/0x1a4
> [??366.849551]??#1: [??366.851324]??(
> &of->mutex[??366.854058] ){+.+.+.}
> , at: [??366.856944] [<c01902cc>] kernfs_fop_write+0xc0/0x1d0
> [??366.861941]??#2: [??366.863839]??(
> s_active[??366.866288] #43
> ){.+.+.+}[??366.868877] , at:
> [??366.870938] [<c01902d4>] kernfs_fop_write+0xc8/0x1d0
> [??366.876053]??#3: [??366.877843]??(
> pm_mutex[??366.880272] ){+.+.+.}
> , at: [??366.883266] [<c005b808>] pm_suspend+0x90/0x81c
> [??366.887757]
> [??366.889268] =============================================
> [??366.889268]
>
> 2. cmdline contains no_console_suspend
>
> * echo enabled > /sys/class/tty/ttyAMA0/power/wakeup
> * echo freeze > /sys/power/state
>
> the same as in 1.
>
> 3. cmdline doesn't contains no_console_suspend
>
> * echo enabled > /sys/class/tty/ttyAMA0/power/wakeup
> * echo freeze > /sys/power/state
>
> [??161.093187] PM: Syncing filesystems ... [??161.734413] done.
> [??161.793242] Freezing user space processes ... (elapsed 0.008
> seconds) done.
> [??161.809797] Freezing remaining freezable tasks ... (elapsed 0.004
> seconds)
> done.
> [??161.821953] Suspending console(s) (use no_console_suspend to
> debug)
>
> >?
> > > > > no reaction to Debug UART
Then the system does not have any response? or the system freezes and
wakes up as expected?
> I expected that in all 3 cases freeze_wake() will be called. Why not?
>
> Here my config again:
>
> CONFIG_PM_SLEEP=y
> CONFIG_SUSPEND=y
> CONFIG_SUSPEND_FREEZER=y
> CONFIG_PM=y
> CONFIG_CPU_IDLE is not set
hmmm, why not have CONFIG_CPU_IDLE set?
thanks,
rui
next prev parent reply other threads:[~2016-11-05 11:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-23 9:19 [Bug] ARM: mxs: STI: console can't wake up from freeze Stefan Wahren
2016-10-23 13:31 ` Russell King - ARM Linux
2016-10-29 11:44 ` Stefan Wahren
2016-10-31 16:17 ` Russell King - ARM Linux
2016-10-31 19:54 ` Stefan Wahren
2016-11-01 9:23 ` Russell King - ARM Linux
2016-11-05 11:07 ` Stefan Wahren
2016-11-05 11:39 ` Zhang Rui [this message]
2016-11-05 12:01 ` Stefan Wahren
2016-11-05 13:00 ` Daniel Lezcano
2016-11-05 15:28 ` Stefan Wahren
2016-11-05 18:05 ` Russell King - ARM Linux
2016-11-06 10:20 ` Stefan Wahren
2016-11-06 14:55 ` Daniel Lezcano
2016-11-06 18:31 ` Stefan Wahren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1478345972.2206.15.camel@intel.com \
--to=rui.zhang@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).