All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhang Rui <rui.zhang@intel.com>
To: Stefan Wahren <stefan.wahren@i2se.com>,
	Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Sascha Hauer <kernel@pengutronix.de>,
	Shawn Guo <shawnguo@kernel.org>,
	joerg.krause@embedded.rocks,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Fabio Estevam <fabio.estevam@nxp.com>
Subject: Re: [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

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2016-11-05 11:39 UTC|newest]

Thread overview: 30+ 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  9:19 ` Stefan Wahren
2016-10-23 13:31 ` Russell King - ARM Linux
2016-10-23 13:31   ` Russell King - ARM Linux
2016-10-29 11:44   ` Stefan Wahren
2016-10-29 11:44     ` Stefan Wahren
2016-10-31 16:17     ` Russell King - ARM Linux
2016-10-31 16:17       ` Russell King - ARM Linux
2016-10-31 19:54       ` Stefan Wahren
2016-10-31 19:54         ` Stefan Wahren
2016-11-01  9:23         ` Russell King - ARM Linux
2016-11-01  9:23           ` Russell King - ARM Linux
2016-11-05 11:07           ` Stefan Wahren
2016-11-05 11:07             ` Stefan Wahren
2016-11-05 11:39             ` Zhang Rui [this message]
2016-11-05 11:39               ` Zhang Rui
2016-11-05 12:01               ` Stefan Wahren
2016-11-05 12:01                 ` Stefan Wahren
2016-11-05 13:00                 ` Daniel Lezcano
2016-11-05 13:00                   ` Daniel Lezcano
2016-11-05 15:28                   ` Stefan Wahren
2016-11-05 15:28                     ` Stefan Wahren
2016-11-05 18:05                     ` Russell King - ARM Linux
2016-11-05 18:05                       ` Russell King - ARM Linux
2016-11-06 10:20                       ` Stefan Wahren
2016-11-06 10:20                         ` Stefan Wahren
2016-11-06 14:55                         ` Daniel Lezcano
2016-11-06 14:55                           ` Daniel Lezcano
2016-11-06 18:31                           ` Stefan Wahren
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=daniel.lezcano@linaro.org \
    --cc=fabio.estevam@nxp.com \
    --cc=joerg.krause@embedded.rocks \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=rjw@rjwysocki.net \
    --cc=shawnguo@kernel.org \
    --cc=stefan.wahren@i2se.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.