Bug#167009: Proper creation of /dev/apm_bios
The question was: Why does X need APM support in order
to recover from a suspend-and-resume cycle?
If the OS lacks APM support, then it is completely
unaware of APM events such as suspending and resuming,
which is implemented in firmware. The OS can't switch
from X to the console, because nothing tells it that
a suspend is about to happen, or has happened. So far
as the OS is concerned, all that happens is that the
real time clock jumps ahead.
Of course, because firmware rarely restores everything
exactly to its pre-suspend state, some other things
are different too ... and herein lies the cause of the
hangs.
To cure the problem on powerpc it will not suffice
to install the powermgmt-base package. All that
does (after getting the administrator's permission) is
create /dev/apm_bios (via MAKEDEV) if the node doesn't
exist already exist. It also configures modutils
and devfs for APM. But powermgmt-base doesn't add APM
support to a kernel that lacks it.
I am told that Debian kernel images have the apm driver
built in, but disabled. Is this true on the powerpc
arch? Would it be possible for powermgmt-base to add
"apm=on" or something like that to the boot parameters?
Perhaps. But even if that is done, the system will
still hang if it is suspended before the next reboot.
I think we have to conclude that the problem here is one
of documentation. Users should be told somewhere that
they should not suspend their machines unless they have
APM support properly configured. (On i386: APM BIOS,
apm driver built and enabled in the kernel, powermgmt-base
and optionally apmd and its dependencies installed.)
As I said before, it's fair to ask for a warning message
in the X log about this. I suggest that this bug be
reopened as a wishlist item.
--
Thomas Hood
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Reply to: