Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 May 2014 16:59:21 -0600 (MDT)
From:      Warren Block <wblock@wonkity.com>
To:        Rui Paulo <rpaulo@felyko.com>
Cc:        Kevin Oberman <rkoberman@gmail.com>, "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
Message-ID:  <alpine.BSF.2.00.1405041641290.9118@wonkity.com>
In-Reply-To: <FCE7DE37-81D4-4859-98DF-89E606B29CAC@felyko.com>
References:  <CAJ-Vmo=mUtpjgVwNHg8af05vCxVchZdsaekR9_Wf-pOfFjnABQ@mail.gmail.com> <FCE7DE37-81D4-4859-98DF-89E606B29CAC@felyko.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 May 2014, Rui Paulo wrote:

> On May 4, 2014, at 1:27, Adrian Chadd <adrian@FreeBSD.org> wrote:
>
>> * Flipping the default lid state to S3. I think ACPI suspend/resume
>> seems to work well enough these days and I've not met anyone lately
>> who expects the default from their laptop to be "stay awake with the
>> lid shut."
>
> The sysctl is really just a hack.  We should have a much better mechanism for integrating our ACPI with the X11 desktop environments.  GNOME/KDE/Mate don't understand our sysctl and get confused easily.
>
> You can turn it on by default, but I'm sure ACPI suspend/resume is not working well enough like you say.  How many laptops have you tested?  For completeness, how many desktops?

Suspend works for me.  It's the resume part, on Dell and Acer systems at 
least, that does not work at all.

> There are bunch of ports kernel modules that will crash your system if you suspend.  VirtualBox is one of them.
>
>> * Save chip bugs that we should add workarounds for, we should be OK
>> to enter lower sleep states when idling. Flipping this may expose some
>> further crazy driver, platform or timer bugs, but they again likely
>> should be fixed.
>
> They are still not fixed.  Some of these problems are not in FreeBSD though and I don't expect us to be able to work around them.  We should try to identify systems where C3 has surprising effects and blacklist them.

If there were an easy-to-run test, many would be happy to report 
results.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1405041641290.9118>