From: Russell King - ARM Linux <linux@arm.linux.org.uk> To: Grygorii Strashko <grygorii.strashko@ti.com> Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>, nm@ti.com, Keerthy <a0393675@ti.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>, linux-pm@vger.kernel.org, peterz@infradead.org, Keerthy <j-keerthy@ti.com>, linux-kernel@vger.kernel.org, josh@joshtriplett.org, edubezval@gmail.com, joel@jms.id.au, mpe@ellerman.id.au, akpm@linux-foundation.org, linux-omap@vger.kernel.org, dyoung@redhat.com, Thomas Gleixner <tglx@linutronix.de>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2] reboot: Backup orderly_poweroff Date: Fri, 15 Jan 2016 14:12:17 +0000 [thread overview] Message-ID: <20160115141217.GF5783@n2100.arm.linux.org.uk> (raw) In-Reply-To: <5698F420.2010500@ti.com> On Fri, Jan 15, 2016 at 03:29:04PM +0200, Grygorii Strashko wrote: > Seems ARM doesn't have endless loop implemented in machine_power_off() - so, > not too much chances for Watchdog to fire. > void machine_power_off(void) > { > local_irq_disable(); > smp_send_stop(); > > if (pm_power_off) > pm_power_off(); > > --- endless loop ? > --- or restart ? > } > [and even if it will be there - 20-30sec is usual timeout for Watchdog > and this enough time to burn the system in case of thermal emergency > poweroff :(] I covered this in my reply to Ingo yesterday. The result is that a failed or unimplemented call drops through to do_exit(0) on behalf of the calling process, terminating that process. However, as I said in that same email, I don't think you're getting anywhere near this code. > That's true - original log [1] has > Nov 30 11:19:22 [ 5.942769] thermal thermal_zone3: critical temperature reached(108 C),shutting down > [...] > Nov 30 11:19:24 [ 7.387900] ahci 4a140000.sata: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part ccc apst > Nov 30 11:19:24 INIT: Switching to runlevel: 0 > Nov 30 11:19:24 INIT: Sending processes the TERM signal > > and there are no > [ 220.004522] reboot: Power down Right, so things are stuck in userspace, which means the system is still in an active runnable state. As I mentioned (again) in my email, the issue appears to be that the 'rc' script is stuck waiting on a FIFO. The init daemon is trying to do an orderly shutdown. As part of that, it's executing the 'rc' script, which in systems I've seen, runs through a set of scripts in the /etc/rc?.d directory in order, which normally bring up or take down services and perform other sequenced actions. If this script hangs (as it seems to be doing) it won't get to running /sbin/poweroff or similar, and that means machine_power_off() won't be called. > In general, this kind of use case can be simulated using SysRq on any arch > - [3.290034] Freeing unused kernel memory: 492K (c0a67000 - c0ae2000) > INIT: version 2.88 booting > Starting udev > ^^ The issue most probably might happens when system in the process of > loading modules > So, once modules loading process is started - fire Sysrq "poweroff(o)" This suggests it could be a udev issue - but without knowing what's happening inside sysvinit's scripts, it's hard to know for certain. Adding some debug to the 'rc' script (make sure it works without rebooting or changing the run level, or have a way of restoring the file if it fails to boot) so that it's possible to see what it's doing may be a good idea - the simplest approach may be to just add set -x towards the top of the file - which will make it very noisy. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2] reboot: Backup orderly_poweroff Date: Fri, 15 Jan 2016 14:12:17 +0000 [thread overview] Message-ID: <20160115141217.GF5783@n2100.arm.linux.org.uk> (raw) In-Reply-To: <5698F420.2010500@ti.com> On Fri, Jan 15, 2016 at 03:29:04PM +0200, Grygorii Strashko wrote: > Seems ARM doesn't have endless loop implemented in machine_power_off() - so, > not too much chances for Watchdog to fire. > void machine_power_off(void) > { > local_irq_disable(); > smp_send_stop(); > > if (pm_power_off) > pm_power_off(); > > --- endless loop ? > --- or restart ? > } > [and even if it will be there - 20-30sec is usual timeout for Watchdog > and this enough time to burn the system in case of thermal emergency > poweroff :(] I covered this in my reply to Ingo yesterday. The result is that a failed or unimplemented call drops through to do_exit(0) on behalf of the calling process, terminating that process. However, as I said in that same email, I don't think you're getting anywhere near this code. > That's true - original log [1] has > Nov 30 11:19:22 [ 5.942769] thermal thermal_zone3: critical temperature reached(108 C),shutting down > [...] > Nov 30 11:19:24 [ 7.387900] ahci 4a140000.sata: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part ccc apst > Nov 30 11:19:24 INIT: Switching to runlevel: 0 > Nov 30 11:19:24 INIT: Sending processes the TERM signal > > and there are no > [ 220.004522] reboot: Power down Right, so things are stuck in userspace, which means the system is still in an active runnable state. As I mentioned (again) in my email, the issue appears to be that the 'rc' script is stuck waiting on a FIFO. The init daemon is trying to do an orderly shutdown. As part of that, it's executing the 'rc' script, which in systems I've seen, runs through a set of scripts in the /etc/rc?.d directory in order, which normally bring up or take down services and perform other sequenced actions. If this script hangs (as it seems to be doing) it won't get to running /sbin/poweroff or similar, and that means machine_power_off() won't be called. > In general, this kind of use case can be simulated using SysRq on any arch > - [3.290034] Freeing unused kernel memory: 492K (c0a67000 - c0ae2000) > INIT: version 2.88 booting > Starting udev > ^^ The issue most probably might happens when system in the process of > loading modules > So, once modules loading process is started - fire Sysrq "poweroff(o)" This suggests it could be a udev issue - but without knowing what's happening inside sysvinit's scripts, it's hard to know for certain. Adding some debug to the 'rc' script (make sure it works without rebooting or changing the run level, or have a way of restoring the file if it fails to boot) so that it's possible to see what it's doing may be a good idea - the simplest approach may be to just add set -x towards the top of the file - which will make it very noisy. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
next prev parent reply other threads:[~2016-01-15 14:12 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-01-13 12:33 [PATCH v2] reboot: Backup orderly_poweroff Keerthy 2016-01-13 12:33 ` Keerthy 2016-01-13 12:33 ` Keerthy 2016-01-14 9:05 ` Ingo Molnar 2016-01-14 9:05 ` Ingo Molnar 2016-01-14 9:18 ` Keerthy 2016-01-14 9:18 ` Keerthy 2016-01-14 9:18 ` Keerthy 2016-01-14 10:09 ` Ingo Molnar 2016-01-14 10:09 ` Ingo Molnar 2016-01-14 10:42 ` Keerthy 2016-01-14 10:42 ` Keerthy 2016-01-14 10:42 ` Keerthy 2016-01-14 11:23 ` Ingo Molnar 2016-01-14 11:23 ` Ingo Molnar 2016-01-14 13:25 ` One Thousand Gnomes 2016-01-14 13:25 ` One Thousand Gnomes 2016-01-15 10:14 ` Ingo Molnar 2016-01-15 10:14 ` Ingo Molnar 2016-01-15 13:29 ` Grygorii Strashko 2016-01-15 13:29 ` Grygorii Strashko 2016-01-15 13:29 ` Grygorii Strashko 2016-01-15 14:12 ` Russell King - ARM Linux [this message] 2016-01-15 14:12 ` Russell King - ARM Linux 2016-01-19 9:06 ` Ingo Molnar 2016-01-19 9:06 ` Ingo Molnar 2016-01-19 10:32 ` Keerthy 2016-01-19 10:32 ` Keerthy 2016-01-19 10:32 ` Keerthy 2016-01-14 14:22 ` Russell King - ARM Linux 2016-01-14 14:22 ` Russell King - ARM Linux 2016-01-15 10:13 ` Ingo Molnar 2016-01-15 10:13 ` Ingo Molnar 2016-01-15 11:05 ` Russell King - ARM Linux 2016-01-15 11:05 ` Russell King - ARM Linux
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=20160115141217.GF5783@n2100.arm.linux.org.uk \ --to=linux@arm.linux.org.uk \ --cc=a.p.zijlstra@chello.nl \ --cc=a0393675@ti.com \ --cc=akpm@linux-foundation.org \ --cc=dyoung@redhat.com \ --cc=edubezval@gmail.com \ --cc=gnomes@lxorguk.ukuu.org.uk \ --cc=grygorii.strashko@ti.com \ --cc=j-keerthy@ti.com \ --cc=joel@jms.id.au \ --cc=josh@joshtriplett.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=mpe@ellerman.id.au \ --cc=nm@ti.com \ --cc=peterz@infradead.org \ --cc=tglx@linutronix.de \ /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: linkBe 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.