[conspire] idle computer

[Paul Zander]

Thank you to the several people who replied to my posting. 

First I will admit that I globed together several different things under the category of, "I expected the computer to be going X.  Instead it paused X and did something else."  Sorry that I didn't follow the guidelines for "asking good questions"

Situation 1:
I will agree the classic SETI and the newer BOINC appear to sense keyboard and mouse activity.  Unless someone can provide alternate information, I conclude that these are not compatible with a computer that sometimes needs to run another activity unattended.

Situtation 2:
This happened during an install of LMDE from DVD onto a laptop.  Once it started copying the files from the DVD, I walked away and expected that it would complete on its own.  Instead when I returned, the screen was black.  I touched ?? on the keyboard and the screen light up and it showed that files were copying.  At this point, the DVD and HD lights were blinking.  

I repeated this process of walking away and coming back several times. After a couple iterations, I realized that the disk lights were NOT active when I approached the machine, but were on after the display was also back on.

Because I did not keep interacting with the computer, the install took more than 12 hours on the wall clock.

The installed version is Gnome. The live version is (probably) also Gnome.  I did not mess with the settings on the live version.  I am guessing that maybe power settings that had been previously made with Windows were saved in hardware outside of either OS and that the settings caused the computer to go to an "idle" state.

Hopefully this fills in the holes in the original description. 

Now that the install was successful, I can try the GNOME power management to get desired behavior.  Also try to remember in the future when I do need to run something unattended, I might first want to temporarily change the settings.

Paul

--- On Tue, 7/12/11, Rick Moen <rick at linuxmafia.com> wrote:

> From: Rick Moen <rick at linuxmafia.com>
> Subject: Re: [conspire] idle computer
> To: conspire at linuxmafia.com
> Date: Tuesday, July 12, 2011, 4:08 PM
> 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.
> 
> 
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
>