On Tue, 2006-05-02 at 19:58 -0400, Mauriat Miranda wrote:
Ok I appreciate you response but:
>
> On 5/2/06, Aaron Konstam <akonstam@xxxxxxxxxxxxx> wrote:
> > Ok, but as I say in a separate message how exactly does one wake the
> > machine up. I used the script that was posted here which dos the supend
> > things you indicate but i can't wake the machine up. How is that done?
>
> Any script that you may have probably does the preparation work before
> suspending and the post-wakeup work to restore anything that was put
> into some modified state. However the script does not do the
> _physical_ wake up, that would be dependant on a user event or some
> type of registered hardware event.
Well as I said I can wake up the machine by hitting the power button but
it immediately locks up. So what to do?
>
> Actions for ACPI are driven by events. A typical event could be
> hitting the Power button or wake key (any key sometimes) or some
> special option on a laptop. Anything that can possibly wake up the
> system must already be supported in the hardware (BIOS), as once the
> system is suspended no user loaded software is available (ie. Linux).
>
> > Why does fedora not come with a suspend and wake up function that does
> > the right thigs? Noy just because this is built in to Windows but it
> > because it makes sense. For example how does one find out that:
>
> ACPI is (supposed to be) a standard/spec. However implementation
> requires some work. Since windows is a fixed platform with less
> variation in software many hardware manufacturers test their ACPI
> compliance against windows, hence once it works in Windows they don't
> care about other systems.
But Windows exists on many architectures. The manufacturer supplies the
needed routines. Maybe someone should look into routines for the fixed
platform Fedora.
>
> The Linux kernel often has to do a great deal of work arounds or code
> hacks to support as much hardware as it does (a great accomplishment
> btw). So often some deviation, or poor hardware support or something
> else from the _manufacturer_ can prevent ACPI from working in Linux as
> well as it does in Windows.
>
> > echo mem > /sys/power/state
> > will cause the processor to suspend. Is there a similar wake up
> > sequence.
>
> Wake up sequences are dependant on events, however they do not
> necessarily apply only when the system is powered off. For example
> most laptop batteries can trigger events, laptop lids, thermal
> sensors, etc. If your BIOS supports timed wakeup read up on 'nvram'.
> Additionally certain hardware can be controlled: CPU clock throttling
> (changing the freq of your processor) or fan speed, etc.
>
> Some of the files in /proc and /sys are read and write. Ex:
>
> [mirandam@charon ~]$ cat /sys/power/state
> standby mem disk
Ever since I ran the suspend script that executed:
echo mem > /sys/power state
cat /sys/power/state returns just: mem
standbye has disappeared and I can't get it back.
What does that mean?
> standby would be S1
> mem would be suspend to ram S3
> disk would be suspend to disk S4 ("hibernate")
> There's also S0, S2 and S5.
>
> However most all your ACPI support is pretty much known to Linux once
> the kernel loads. For a full list of support for your specific
> hardware, run:
> # dmesg
> Look for lines that say 'ACPI:', however most information will require
> some google research to understand what it means.
There are no boot messages with ACPI in their content but /proc/acpi
exists and can dispaly relevant information when cat-ing its sub-files.
What does that mean?
>
> You can also look in /proc/acpi
>
> I completely agree that the struggle for perfect ACPI in linux has
> been a pain! However please know that it has come a long long way and
> greatly improved since I first tried the acpi patch to kernel 2.4.20
> in 2002 just to get the power button to trigger shutdown (I was easily
> impressed back then). And please know that this is really the hardware
> manufacturers failure NOT linux.
>
> I would recommend complaining to manufacturers but it would fall on
> deaf ears. Instead be more picky with your hardware to find
> confirmation of compliant products.
>
> Some hardware works perfectly out of the box and eventually most will,
> however until that happens chances are that you will have to modify
> scripts or configs etc etc.
>
> I hope this helps.
>
> Mauriat
--
Aaron Konstam <akonstam@xxxxxxxxxxxxx>
