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
