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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191104135111.GF28764@mit.edu>
Date:   Mon, 4 Nov 2019 08:51:11 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Tom Cook <tom.k.cook@...il.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Power management - HP 15-ds0502na

On Mon, Nov 04, 2019 at 11:21:24AM +0000, Tom Cook wrote:
> * Power management doesn't work very well.  The most obvious symptom
> of this is that /sys/power/mem_sleep contains only "[s2idle]" and so
> there is no suspend-to-RAM available.  Setting
> "mem_sleep_default=deep" on the command line doesn't change this.

This is actually the laptop's ACPI and/or EC not supporting
suspend-to-ram at all.  Suspend to idle is the new hotness, because it
gives the OS much more control (but also gives the OS much more
opportunity to screw up).  The Dell XPS 13 (models 9370 and 9380)
supports both s2idle and s2ram, but s2idle doesn't work well at all on
Linux.  (Well, at least not the upstream kernels; the official Dell
Ubuntu kernel and userspace apparently has enough tweaks that it works
well.)

I tried for a bit to see if I could get s2idle working well on the
upstream Dell XPS 13, but bits of hardware would randomly fail to come
back from a s2idle resume --- or in some cases, the laptop wouldn't
come back at all, that I decided, "life's too short", and gave up on
it.  Hopefully Dell or other folks will get s2idle working well on the
XPS 13... at least before suspend2ram gets dropped entirely.  :-/


> * There are a few devices that appear to be on I2C buses and declared
> in the ACPI tables (eg the fingerprint sensor) which don't show up
> under Linux.  They did under Windows, until I blew the Windows
> installation away to install Linux, and I'm assuming that Windows
> found them through the ACPI DSDT.  Now thinking it may have been handy
> to keep Windows around for debugging, but that's regrets for you.

Even if they showed up, it's unclear the device driver would exist for
Linux.  Most fingerprint readers have proprietary interfaces and
aren't well supported by Linux in general.

> Is this the right place to raise this?  If there's some other place
> that Linux ACPI issues are dealt with, please point me there as I've
> not had any luck googling.

There is the linux-acpi@...r.kernel.org mailing list and the
linux-pm@...r.kernel.org (pm --> "power management") where you might
try asking about the s2idle.  A lot of the issues with s2idle appear
to be very device driver specific, and not about the power management
core, so it's unclear folks on those lists will be able to help.  But
it's worth a try...

					- Ted

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ