linux-kernel - suspending machine from kernel (was Re: [linux-pm] [RFC] why do we need run disk sync before entering S3)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090515090843.GC32740@elf.ucw.cz>
Date:	Fri, 15 May 2009 11:08:44 +0200
From:	Pavel Machek <pavel@....cz>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	kernel list <linux-kernel@...r.kernel.org>,
	linux-pm@...ts.linux-foundation.org, linux-acpi@...r.kernel.org
Subject: suspending machine from kernel (was Re: [linux-pm] [RFC] why do we
	need run disk sync before entering S3)

On Thu 2009-05-14 22:00:56, Henrique de Moraes Holschuh wrote:
> On Thu, 14 May 2009, Pavel Machek wrote:
> > But remember there are even in-kernel s2ram triggers, for example on
> > zaurus when battery goes critical.
> 
> Are there?  I am quite interested on this!

Yes.

It is a bit of mess, but see

common/sharpsl_pm.c:

   /* Suspend if critical battery level */
        if ((sharpsl_pm.battstat.ac_status != APM_AC_ONLINE)
                        && (sharpsl_pm.battstat.mainbat_status ==
APM_BATTERY_STATUS_CRITICAL)
                        && !(sharpsl_pm.flags & SHARPSL_APM_QUEUED)) {
                sharpsl_pm.flags |= SHARPSL_APM_QUEUED;
                dev_err(sharpsl_pm.dev, "Fatal Off\n");
                apm_queue_event(APM_CRITICAL_SUSPEND);
        }

it eventually triggers regular s2ram paths.

Older versions did suspend on power button press. (You can't really
turn zaurus _off_, AFAICT.)

> Are they safe on x86?

Well, probably safe but definitely would need some cleanup.

> thinkpad-acpi receives some critical alarms from the firmware, for which the
> recommended action by the vendor is to go into S3 immediately.  There is
> also one which requires S4 as the recommended damage control measure.

While s2ram should always work on hardware that supports it (zaurus),
S4 is more tricky. It needs swap to be configured, and userspace
cooperation in uswsusp case.

I guess sending signal to init would be right solution in that
case. (ACPI already does that on overheat.)

								Pavel
(Sorry about breaking Ccs)
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/