[conspire] idle computer

[Rick Moen]

Quoting Ruben Safir (ruben at mrbrklyn.com):

> I believe he is talking about the suspend action, which is now built
> into the gnome interface allong with everything else it should do.

I see, on attempting to re-parse what Paul asked that -- in talking
about a computer being 'idle' or 'not in use' -- in _some_ places he's
talking about the OS or ACPI controller chip putting the computer into
sleep/suspend-to-RAM or hiberation/suspend-to-disk mode, and sometimes
he's talking about the screensaver kicking in, and some process
associated with the screensaver (e.g., SETI at home) kicking in.

Those are two rather different things.

The two separate programs called 'SETI at home' for Linux are both
proprietary packages, capable of either running whenever the screensaver
kicks in or alternatively in background continuously whever the
computer's active and the user is logged in.  The earlier program is
more accurately named 'SETI at home Classic' and did only SETI.  Its late
2005 replacement is Berkeley Open Infrastructure for Network Computing
(BOINC), which runs whatever distributed computing projects it's
directed to remotely by the scientists at UC Berkeley's Space Sciences
Laboratory.

Neither of those programs is particularly related to the process of an
ACPI-aware OS, or the ACPI controller chip acting on its own, deciding
to put the host machine into sleep or hibernate mode.

Paul wrote:

[He installed LMDE, and:]  
> After I had answered all of the questions and saw that files were
> being copied, I walked away and expected it would be done when I got
> back. I returned to a black display. I wiggled the mouse and I saw
> that files were still copying.

The 'black display' seems to refer to something having blanked the
screen.  Paul is more than a bit unclear as to whether or not the files
were copying while the screen was blanked.  He should have been able to
determine the answer to that question by listening to hard drive
activity.

Obviously, none of us is likely to be able to tell Paul exactly what was
going on with his machine, as we weren't there, and his recounting has
big holes in it.  It's likely that either the screen alone was blanked,
or that the screen was blanked and the system as a whole slept or
hibernated.  Which one?  Can't say.  Wasn't there.  Don't know the
particulars of Paul's system.

> Are ACPI settings written by Windows stored where they would effect
> the Linux install?

This seems like a very unfocussed question that rests on a wild guess
about how ACPI works.

ACPI is a horribly overfeatured specification for power management and
device configuration that was developed for x86 machines (but not, say, 
PowerPC ones) by a consortium that included Intel, Microsoft, and
several laptop and BIOS companies.  Additionally, as horribly mangled
and byzantine as the specification is, it's also marred by pervasive
manufacturer-specific proprietary extensions.  Thus, because they're
unwilling to develop proprietary code under NDA, the Linux kernel coders
are put in a position of having to reverse-engineer a significant part
of the necessary hardware support.

Speaking generally, once an ACPI-compliant operating system boots, 
it informs the ACPI controller chip of its presence and informs the chip
that it's taking over hardware + power management.  This control over
the system includes when and if to go into sleep or hibernate, and
switching among full-performance and lower-performance/power-saving
operating modes.  This situation persists until restart.  I _think_ 
the system reverts to its BIOS-set settings at the time of restart.
At which point, an ACPI-compliant operating system may boot and say 'I'm
taking over' again.

> Why does a computer that is busy copying files think it is 'not in
> use'?

I interpret this question as intending to ask:  'Why would a supposedly
ACPI-aware OS put a machine into a mode with the screen blanked and with
little or no computing power available, while a bulk file-copy is
underway?'

Again, it is unclear from Paul's description whether the screen was
_merely_ blanked or whether hard disk activity had also been halted.
(Paul, don't forget that your knowledge of how your system _sounds_ is
an important diagnostic tool.)  It is unclear whether his system went
into sleep / suspend-to-RAM 'S3' mode.  (MS-WIndows's 'hiberate' command
is associated with ACPI mode S3.)  It is unclear whether his system
went into hibernate / suspend-to-disk 'S4' mode.  It is unclear whether 
the system merely blanked the screen and used voltage/frequency CPU
scaling to enter a lower-power P1 to P16 power-saving mode.  It is
unclear whether the system blanked the screen and put the CPU into a
powered-on but halted S1 'stopgrant' mode.  (MS-Windows's 'standby'
command reportedly puts system ACPI into mode S1.)  It is unclear
whether the system blanked the screen and put most devices into
power-off via ACPI mode S5 'soft off' mode.  (MS-Windows's 'shutwon'
command puts system ACPI into mode S5.)

In any event, FWIW, when the Linux kernel's ACPI code does any of these
things, it changes the record of system state under /sys/power/state.
I'd speculate that it probably also makes entries under /var/log,
somewhere.

If the result was the kernel doing something dumb, then why did it do
something dumb?  Could be broken or manufacturer-proprietary things in
the system BIOS firmware that the kernel didn't understand correctly.
Could be actual inadequacies in how your version of the kernel attempts
to implement the inscrutable and byzantine ACPI specification.  Could be
that you're running cruddy proprietary hardware drivers (e.g., Nvidia)
that work only poorly with the kernel.  Could be that some ACPI kernel
modules aren't loaded.  (See:
https://wiki.archlinux.org/index.php/ACPI_modules )

Could be that the manufacturer's DSDT (Differentiated System Description
Table) is inscrutable and incomplete, and should be replaced by a better
one.  See:  https://wiki.archlinux.org/index.php/DSDT

To see how insanely complicated ACPI support can get, see this
troubleshooting guide: http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems
About controlling Linux's supervision of CPU frequency scaling, see
this:  http://rffr.de/acpi


I suspect that Paul's other questions are largely addressed by the
above.