* Keerthy <j-keerthy@xxxxxx> wrote: > orderly_poweroff is triggered when a graceful shutdown > of system is desired. This may be used in many critical states of the > kernel such as when subsystems detects conditions such as critical > temperature conditions. However, in certain conditions in system > boot up sequences like those in the middle of driver probes being > initiated, userspace will be unable to power off the system in a clean > manner and leaves the system in a critical state. In cases like these, > the /sbin/poweroff will return success (having forked off to attempt > powering off the system. However, the system overall will fail to > completely poweroff (since other modules will be probed) and the system > is still functional with no userspace (since that would have shut itself > off). > > However, there is no clean way of detecting such failure of userspace > powering off the system. In such scenarios, it is necessary for a backup > workqueue to be able to force a shutdown of the system when orderly > shutdown is not successful after a configurable time period. > > Signed-off-by: Keerthy <j-keerthy@xxxxxx> > Suggested-by: Eduardo Valentin <edubezval@xxxxxxxxx> > Reported-by: Nishanth Menon <nm@xxxxxx> > --- > Links to previous discussion can be found here: > > http://www.spinics.net/lists/linux-omap/msg124925.html > > Boot tested on DRA7. > > changes in v2: > > * Changed #ifdef to #if CONFIG_SHUTDOWN_BACKUP_DELAY_MS > > arch/Kconfig | 7 +++++++ > kernel/reboot.c | 23 ++++++++++++++++++----- > 2 files changed, 25 insertions(+), 5 deletions(-) > > Index: linux/arch/Kconfig > =================================================================== > --- linux.orig/arch/Kconfig 2016-01-11 15:26:07.732173131 +0530 > +++ linux/arch/Kconfig 2016-01-11 15:26:07.728173205 +0530 > @@ -37,6 +37,18 @@ > def_bool y > depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI && !PPC64 > > +config SHUTDOWN_BACKUP_DELAY_MS > + int "Backup shutdown delay in milli-seconds" > + default 0 > + help > + The number of milliseconds to delay before backup workqueue > + executes attempting to poweroff the system after the > + orderly_poweroff function has failed to complete. > + > + If set to 0, the backup workqueue is not active. The value > + should be conservatively configured based on userspace latencies > + expected for a given system. I don't really understand this. In what circumstances can a reboot fail? I think that is what should be fixed: a reboot should never fail, instead of introducing some sort of fragile timeout based method. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
