this bug is similar to bug 36978, but on different hardware.
With redhat 7.1 installed on a Sony Vaio SR7K laptop,
things run fine and seem to suspend successfully.
On resume, the hard drive spins up and the fan comes on,
but the screen remains blank and the system is non-responsive
to keyboard input.
1. boot redhat 7.1
2. press Fn-ESC to suspend the system
(machine turns off)
3. hit any key to unsusupend
power light comes on but
machine is now locked up
The problem persists whether or not you suspend from with X11
or from a virtual terminal.
In Redhat 7.0 suspend/resume worked fine.
The suggestion from <http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36978>
about rlling back the apmd RPM to that from RH 7.0 did
not solve the problem for me.
*** Bug 37696 has been marked as a duplicate of this bug. ***
A possible work-around: I rebuilt redhat's 2.4.2 kernel variant
# CONFIG_APM_REAL_MODE_POWER_OFF is not set
This *seems* to allow resume to work, at least from a vritual console
(not from X the one time I tried).
Also, falling back to the 2.2.16 kernel from RH 7.0 allows resume to work
(although breaks other things). The default 2.2.16 kernel had
CONFIG_APM_REAL_MODE_POWER_OFF not set.
CONFIG_APM_REAL_MODE_POWER_OFF is a bit different in our kernel.
Even if it is "y", it is still disabled and only enabled if you give the
kernel a commandline option.
The possible culprit is CONFIG_APM_ALLOW_INTS.
Are you in a position to play with that option? We are working on a fix
for this and I'm very interested to know if this fix also works for vaio's.
(basically, we are building a list of machines that require a "y" to the
ALLOW_INTS question and make it automatic for those machines)
Also, do you have an eepro100 ethernet device in the laptop ?
Making realmode boot-time controllable is good (I hope this patch gets
back to the main tree).
Maybe the allow-ints stuff can be run-time
controllable as well? (Building kernels is a pain.)
I'll try building a kernel with ALLOW_INTS (but 2.2.16 worked without that).
I don't have an eepro100, just an old dlink pc-card adaptor.
> Maybe the allow-ints stuff can be run-time
> controllable as well? (Building kernels is a pain.)
guess what we have in our tree current tree ....
(Oh and it's also submitted to Alan Cox for inclusion in the -ac series and
later the official Linus kernel)
If your vaio works with allow_ints, we can make that the default for it by
identifying the bios. More about that when it is known _if_ it works.
Follow-up after several days of experimntation:
- with allow-ints off, the default kernel, and the boot option
apm=realmode,debug, and the /etc/sysconfig/apm-scripts/apmscript disabled (1st
line changed to exit 0), able to get power management (supsend/resume) to work
intermittently if I manually change to a text console before suspending.
If I enable apmscript, it always hangs (both with and without the CHANGEVT set).
If I suspend from within X11 it always hangs.
With these constraints it always suspends and resumes at least once and often a
couple of times, but at some point it refuses to resume (as previously described).
- turning on allow-ints makes power management hang on resume always
- As a work-around I rolled back to the RH 7.0 kernel upgrade (2.2.19). Power
managment now works reliably again from X11.
It seems like something about either the 2.4 kernel (or the patches to it)
breaks APM on my hardware. :-(
I am having the similiar problem on my IBM thinkpad T21 with a builtin
eepro100 ethernet card. everything worked fine in redhat 7.0 but with
redhat 7.1, sometimes I couldn't recover from a suspend mode (it doesn't
matter whether I was in console mode, or X11, before the suspend mode.
Some other times, I can recover from suspend mode without a problem.
When I do get the problem, I can see the hard drive started to spin
but I couldn't get the LCD screen back no matter what key I press.
It looks like the keyboard is not responding. I would guess the system
is still running fine and I could ssh into it if the network interface
weren;t brought down as part of the suspend.
I couldn't really reproduce this problem, but the failure rate is pretty
high, probably around 50%.
The thinkpad problem should be fixed in the latest kernels from rawhide.
Unfortionatly, this is a different problem than the vaio one.
I'm seeing a similar problem on my IBM ThinkPad X22 under Skipjack. After
loading the radeon and agpgart modules and starting X, I can not resume from a
suspend. It starts - and then hangs in an indeterminiate state with status
lights blinking. (I'm trying to get IBM to tell me what the lights mean) - but
the trigger is defninitely X related.
I can confirm the problem on the IBM Thinkpad X22 under RH7.3 (both 2.4.18-3 and
2.4.18-4). The hardware is a ATI Radeon Mobility M6 LY and the problem is
related in some way to the use of the radeom and agpgart modules and using X.
If I start X using a configuration that doesn't have 3d accelleration, then the
radeon and agpgart modules are not loaded and there is no trouble with suspend
and resume. It works regardless of whether I suspend while in a VT or in X. Just
"modprobe agpgart; modprobe radeon" doesn't make the system un-suspendable either.
But if I run X with 3d enabled, then the suspend apparently succeeds, but the
subsequent resume hangs forever with a flashing crescent light on the laptop.
Exiting X before trying to suspend does not help and neither does exiting X AND
"rmmod radeon; rmmod agpgart" The modules unload but the system will still hang
on suspend-and-resume. Weirdly enough, this happens even if I start X up again
after removing the modules without 3d enabled.
It is as though there is something about starting X in 3d mode on the Radeon
that puts the system in a state from which it does not want to return.
You may close this bug, this problem seems fixed as of RH 7.2.