On 09/27/15 00:07, Ian Smith wrote:
> On Sat, 26 Sep 2015 11:56:10 -0700, Colin Percival wrote:
> > Ok, so you're satisfied with having the suspend-disabling triggered by
> > init (i.e., not happening until shutdown(8) reaches "now")?
>
> Sure, if you're satisfied that 'shutdown [..] now' - or h
On Sat, 26 Sep 2015 11:56:10 -0700, Colin Percival wrote:
> On 09/26/15 10:59, Ian Smith wrote:
> > On Sat, 26 Sep 2015 00:26:31 -0700, Colin Percival wrote:
> > > Points without consensus:
> > > * jkim thinks we should prevent suspend when we're dropping to
> > single-user
> > > mode; I'
On 09/26/15 10:59, Ian Smith wrote:
> On Sat, 26 Sep 2015 00:26:31 -0700, Colin Percival wrote:
> > Points without consensus:
> > * jkim thinks we should prevent suspend when we're dropping to single-user
> > mode; I'm not sure I see the point, but I don't think there's any harm in
> > doing th
On Sat, 26 Sep 2015 00:26:31 -0700, Colin Percival wrote:
> Hi all,
>
> I think there is consensus for:
> * Using a sysctl (simpler than a device node),
> * Setting this sysctl on all architectures,
> * Calling the sysctl kern.suspend_blocked,
> * Consulting the sysctl from the ACPI code (f
On 09/26/15 01:54, Dan Lukes wrote:
> Colin Percival wrote:
>> I've written (but not yet actually compiled or tested, so beware of typos) a
>> patch which I think makes sense.
>
> It look good.
>
> But it seems to me the goal has been lost during discussion. It has been
> started because of unwi
Colin Percival wrote:
> I've written (but not yet actually compiled or tested, so beware of typos) a
> patch which I think makes sense.
It look good.
But it seems to me the goal has been lost during discussion. It has been
started because of unwilling interaction of LID close and ongoing
shutdow
On 09/26/15 00:42, Hans Petter Selasky wrote:
> On 09/26/15 09:26, Colin Percival wrote:
>> I think there is consensus for:
>> * Using a sysctl (simpler than a device node),
>
> Presumably a read/write tunable sysctl, RWTUN?
I suppose it could be, but the intention here was to block suspend while
Hi,
On 09/26/15 09:26, Colin Percival wrote:
Hi all,
I think there is consensus for:
* Using a sysctl (simpler than a device node),
Presumably a read/write tunable sysctl, RWTUN?
* Setting this sysctl on all architectures,
* Calling the sysctl kern.suspend_blocked,
* Consulting the sysctl f
Hi all,
I think there is consensus for:
* Using a sysctl (simpler than a device node),
* Setting this sysctl on all architectures,
* Calling the sysctl kern.suspend_blocked,
* Consulting the sysctl from the ACPI code (for now) and possibly from
other platform-specific forms of sleeping (in the ind
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/23/2015 04:28, Colin Percival wrote:
> On 09/22/15 12:13, Jung-uk Kim wrote:
>>> I didn't want to pollute init with arch-dependent hacks.
>>> Anyway, the attached patch should do what you want (not
>>> tested).
>>
>> Or a simpler hack with sys
On Wednesday, September 23, 2015 01:38:00 AM Colin Percival wrote:
> On 09/22/15 15:38, John Baldwin wrote:
> > I kind of think just setting the LID switch sysctl during shutdown
> > is probably fine.
>
> It's all a matter of how general a solution we want, I guess. My immediate
> issue was the l
Ian Smith wrote:
> if you initiate a shutdown - I'd assumed you meant using 'shutdown -p now'
> ono?
Unsure what method the Colin is using, but I'm using power-off button to
initiate shutdown.
Dan
___
freebsd-acpi@freebsd.org mailing list
https://list
On Tue, 22 Sep 2015 01:28:27 -0100, Colin Percival wrote:
> On 09/20/15 03:04, Ian Smith wrote:
> > On Sun, 20 Sep 2015 00:16:36 -0700, Colin Percival wrote:
> > > On 09/18/15 11:29, Anthony Jenkins wrote:
> > > > Is it possible for /etc/rc.shutdown to complete, but shutdown not
> > > > occ
On 09/22/15 15:38, John Baldwin wrote:
> I kind of think just setting the LID switch sysctl during shutdown
> is probably fine.
It's all a matter of how general a solution we want, I guess. My immediate
issue was the lid switch, but I never like solving a small problem if I can
address a more gen
On 09/22/15 12:13, Jung-uk Kim wrote:
>> I didn't want to pollute init with arch-dependent hacks. Anyway,
>> the attached patch should do what you want (not tested).
>
> Or a simpler hack with sysctl(3) instead of ioctl(2).
Right, this is more like what I was thinking. (I can write patches mysel
On Tuesday, September 22, 2015 03:13:39 PM Jung-uk Kim wrote:
> > On 09/20/2015 03:16, Colin Percival wrote:
> >> On 09/18/15 11:29, Anthony Jenkins wrote:
> >>> Is it possible for /etc/rc.shutdown to complete, but shutdown
> >>> not occur? If so, there should be a mechanism to restore the
> >>> a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> On 09/20/2015 03:16, Colin Percival wrote:
>> On 09/18/15 11:29, Anthony Jenkins wrote:
>>> Is it possible for /etc/rc.shutdown to complete, but shutdown
>>> not occur? If so, there should be a mechanism to restore the
>>> ability to suspend. O
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/20/2015 03:16, Colin Percival wrote:
> On 09/18/15 11:29, Anthony Jenkins wrote:
>> Is it possible for /etc/rc.shutdown to complete, but shutdown
>> not occur? If so, there should be a mechanism to restore the
>> ability to suspend. Other tha
On 09/20/15 03:04, Ian Smith wrote:
> On Sun, 20 Sep 2015 00:16:36 -0700, Colin Percival wrote:
> > On 09/18/15 11:29, Anthony Jenkins wrote:
> > > Is it possible for /etc/rc.shutdown to complete, but shutdown not
> > > occur? If so, there should be a mechanism to restore the ability to
> > >
On Sun, 20 Sep 2015 00:16:36 -0700, Colin Percival wrote:
> On 09/18/15 11:29, Anthony Jenkins wrote:
> > Is it possible for /etc/rc.shutdown to complete, but shutdown not
> > occur? If so, there should be a mechanism to restore the ability to
> > suspend. Other than that, I like it.
>
> H
On 09/18/15 11:29, Anthony Jenkins wrote:
> Is it possible for /etc/rc.shutdown to complete, but shutdown not
> occur? If so, there should be a mechanism to restore the ability to
> suspend. Other than that, I like it.
Hmm... well, rc.shutdown runs before the system drops into single-user
mode.
On Fri, 18 Sep 2015 13:51:15 -0400, Jung-uk Kim wrote:
> On 09/17/2015 19:12, Colin Percival wrote:
> > On 09/17/15 13:31, Jung-uk Kim wrote:
> >> On 09/16/2015 23:49, Colin Percival wrote:
> >>> I ran into an interesting glitch recently: I told my laptop to
> >>> shut down, then closed the li
Colin Percival wrote:
> The example of a system which can usefully suspend but doesn't have enough
> battery life left to allow tit to complete a normal shutdown seems a bit
> implausible
It's valid for in-kernel portion of shutdown only. But you wish to
disable suspend even during userland part o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/18/2015 14:29, Anthony Jenkins wrote:
> On 09/18/2015 01:51 PM, Jung-uk Kim wrote:
>> On 09/17/2015 19:12, Colin Percival wrote: > > On 09/17/15 13:31,
>> Jung-uk Kim wrote: > >> On 09/16/2015 23:49,
> Colin Percival wrote: > >>> I ran into an
On 09/18/2015 01:51 PM, Jung-uk Kim wrote:
> On 09/17/2015 19:12, Colin Percival wrote: > > On 09/17/15 13:31, Jung-uk Kim
> wrote: > >> On 09/16/2015 23:49,
Colin Percival wrote: > >>> I ran into an interesting glitch recently: I
told my laptop to > >>> shut down, then closed the lid... and it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/17/2015 19:12, Colin Percival wrote:
> On 09/17/15 13:31, Jung-uk Kim wrote:
>> On 09/16/2015 23:49, Colin Percival wrote:
>>> I ran into an interesting glitch recently: I told my laptop to
>>> shut down, then closed the lid... and it promptly
On Thu, 17 Sep 2015 16:22:55 -0700, Colin Percival wrote:
> On 09/17/15 14:39, Dan Lukes wrote:
> > Colin Percival wrote:
> >> I considered that option but thought that disabling suspend completely
> >> would be better in case it was triggered by something else
> >
> > You has been affected
On 09/17/15 14:39, Dan Lukes wrote:
> Colin Percival wrote:
>> I considered that option but thought that disabling suspend completely
>> would be better in case it was triggered by something else
>
> You has been affected by LID issue - and here I'm with you.
Ok. But adjusting the sysctl might n
On 09/17/15 13:31, Jung-uk Kim wrote:
> On 09/16/2015 23:49, Colin Percival wrote:
>> I ran into an interesting glitch recently: I told my laptop to shut
>> down, then closed the lid... and it promptly went into S3. When I
>> opened the lid a couple days later, it resumed... and then finished
>> t
Colin Percival wrote:
> I considered that option but thought that disabling suspend completely
> would be better in case it was triggered by something else
You has been affected by LID issue - and here I'm with you.
Suspend triggered by exhausted battery case needs to be evaluated
carefully. Batt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/16/2015 23:49, Colin Percival wrote:
> Hi ACPI people,
>
> I ran into an interesting glitch recently: I told my laptop to shut
> down, then closed the lid... and it promptly went into S3. When I
> opened the lid a couple days later, it resume
On 09/17/15 04:31, Ian Smith wrote:
> On Thu, 17 Sep 2015 10:52:23 +0200, Dan Lukes wrote:
> > Colin Percival wrote:
> > > I think we need to get the kernel ACPI bits to disable Suspend.
> >
> > I consider it is suboptimal solution. I wish the suspend still happen if
> > shutdown will not com
On Thu, 17 Sep 2015 10:52:23 +0200, Dan Lukes wrote:
> Colin Percival wrote:
> > I ran into an interesting glitch recently: I told my laptop to shut down,
> > then closed the lid... and it promptly went into S3. When I opened the
> > lid a couple days later, it resumed... and then finished th
Colin Percival wrote:
> I ran into an interesting glitch recently: I told my laptop to shut down,
> then closed the lid... and it promptly went into S3. When I opened the
> lid a couple days later, it resumed... and then finished the shutdown
> which it had started 2 days earlier.
Yes, it's well
Hi ACPI people,
I ran into an interesting glitch recently: I told my laptop to shut down,
then closed the lid... and it promptly went into S3. When I opened the
lid a couple days later, it resumed... and then finished the shutdown
which it had started 2 days earlier. Meanwhile with two days of s
35 matches
Mail list logo
