|
Home > Archive > Debian Developers > January 2005 > acpi vs apm
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Christian Lynbech 2005-01-24, 5:54 pm |
| I have an HP Compaq NC6000 laptop and I have some problems getting it
to suspend. I am running the stock Debian 2.6.9 kernel (in the 686
variant, currently not sure whether it is version 1 or 2).
If I run apm (setting kernel parameters acpi=off and apm=on, loads the
apm module and starts apmd) I can suspend the laptop by issuing the
command "apm -s".
If I run acpi (no special kernel parameters, starting acpid which
loads a bunch of kernelmodules) I can not get it to suspend. First of
all, there does not seem to be an equivalent of "apm -s" for acpi. The
"acpi" command only reports stuff like battery status and
temperatures.
There is a file /proc/acpi/sleep but trying various values (0-5) only
one makes it blank the screen, but the power led is staedy green (it
blinks with "apm -s") and there is apparently no way to get it back to
life, other than cycling power and rebooting which kinds of defeats
the purpose of suspending :-)
So the questions goes: is this a shortcoming with the HP not being
properly supported with acpi, am I missing some command like "apm"
which is able to do what I want or is this simply acpi not really
having caught up with apm yet?
PS
Yes, I know of the swsusp but I would much prefer a solution that did
not require rebuilding the kernel as the distributed kernels (AFAIK)
does have these options enabled.
I also know that I could just use apm but acpi seems to be much better
at managing the fans, with apm they seemed to run at full speed, not
that I has been digging very much into that yet.
------------------------+-----------------------------------------------------
Christian Lynbech | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- petonic@hal.com (Michael A. Petonic)
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Matthew Garrett 2005-01-24, 5:54 pm |
| Christian Lynbech <lynbech@defun.dk> wrote:
> So the questions goes: is this a shortcoming with the HP not being
> properly supported with acpi, am I missing some command like "apm"
> which is able to do what I want or is this simply acpi not really
> having caught up with apm yet?
acpi requires a fairly large amount of userland support. I've been doing
a lot of work on this, and intend to push it back into Debian
post-Sarge. It's not as simple as running something like acpi -s - nor
will just echoing 3 into /proc/acpi/sleep work for many machines.
On the other hand, every report I've had for the nc6000 has been a
failure. The 4000 seems to have similar issues.
--
Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Cameron Patrick 2005-01-26, 2:48 am |
| Matthew Garrett wrote:
>
> acpi requires a fairly large amount of userland support. I've been doing
> a lot of work on this, and intend to push it back into Debian
> post-Sarge. It's not as simple as running something like acpi -s - nor
> will just echoing 3 into /proc/acpi/sleep work for many machines.
What kind of userland support do you see as being missing? I use the
hibernate package for ACPI sleep and it works pretty well. Most of
the problems that I've seen with ACPI have been kernel or BIOS issues
(e.g. the screen not being switched on when resuming unless you give
particular kernel options).
Cheers,
Cameron.
| |
| Matthew Garrett 2005-01-26, 7:51 am |
| Cameron Patrick <cameron@patrick.wattle.id.au> wrote:
> What kind of userland support do you see as being missing? I use the
> hibernate package for ACPI sleep and it works pretty well. Most of
> the problems that I've seen with ACPI have been kernel or BIOS issues
> (e.g. the screen not being switched on when resuming unless you give
> particular kernel options).
The ACPI spec makes it the OS's responsibility to reinitialise the video
hardware, not the BIOS's. The kernel is (for the most part) incapable of
doing so - there are some cases where you can get it to bring it back,
but there's a huge range of hardware where those options crash the
machine on resume.
The main things that need doing are:
1) Dealing with network interfaces and the like sensibly - at the
moment, this will often require unloading and reloading modules pre/post
suspend
2) Working with video state. The vbetool package makes it possible to
save and restore the graphics card state from userland, which tends to
work much better than the kernel fudges. In the long run, either X or
the framebuffer drivers need to get much better at programming the
video.
3) Decent integration into user configuration. In a lot of cases, you
want PM policy to be definable by the person carrying the computer
around, even if they don't have administrative access.
I've got some amount of code for doing most of these things, but it's
very heavily a post-Sarge thing - it involves touching a lot of
packages.
--
Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Cameron Patrick 2005-01-27, 7:54 am |
| Matthew Garrett wrote:
> 1) Dealing with network interfaces and the like sensibly - at the
> moment, this will often require unloading and reloading modules pre/post
> suspend
Yup. The hibernate package helps with this and can do quite a bit
automatically by way of a "blacklisted modules" mechanism plus
configuration options for bringing network interfaces up and down,
killing and restarting programmes, mounting and unmounting filesystems
and so on.
> 2) Working with video state. The vbetool package makes it possible to
> save and restore the graphics card state from userland, which tends to
> work much better than the kernel fudges. In the long run, either X or
> the framebuffer drivers need to get much better at programming the
> video.
Oooh, neat. With vbetool my laptop doesn't need any kernel hacks to
resume properly and doesn't spit out as many worrying acpi warnings.
I'm about to write a hibernate scriptlet for doing this soon.
Cheers,
Cameron.
|
|
|
|
|