Bug 62955

I'm not sure if this could be due to a kernel bug, X bug, APM bug, or
just configuration.

Make sure you are running the latest BIOS update for your machine, as they
often solve problems like this related to APM.

Arjan, any thoughts?

My system BIOS is up-to-date.

I should probably mention, that this was not a problem when my system was
running RH 7.2.

Ok simple test: can you install the 2.4.9-31 kernel from the 7.2 updates and
test that. If that works then it's a kernel change, if that still doesn't work
it's an XFree thing, maybe. A third thing to try is to downgrade the "gpm" rpm
to the 7.2 one.

OK, to successfully install, and boot from 2.4.9-31, I had to move my only
harddisk from hde(Promise Ultra133-TX2 controller) to hda, as the promise
controller was not supported in the 2.4.9-31 version of the kernel. So I moved
the device and started the system, still using the 2.4.18 kernel shipped with
skipjack. I wanted to make sure that the problem was still there, before
conducting the actual proposed test. And guess what... It works just fine now!?!
The Promise Controller is still installed in the computer and there is a DVD
drive attached to it, but it does NOT install it's BIOS on boot, as there is no
supported bootable devices attached to the controller. Could this be it?
Other that that I changed the kernel command line a bit... of course changing
the root from /dev/hde2 to /dev/hda2 but I also removed two options of ide-scsi.
One for my cd-rw drive which was completely removed in the new test
configuration and one for the DVD drive attached to the promise controller.

I did some further testing, as I was suspecting the Promise controller might
have something to do with the problem. I have also been tracking a problem,
where mouse controls(clicks) does not seem to work correctly after having run an
apm -s from X/GNOME... So I removed the promise controller completely - same
problem(the problem descriped right here - I will continue with tests with the
2.4.9-31 kernel and I will try to reproduce the problem, that this bugreport is
about. The reason i mention the strange mouse behaviour in this report, is that
whenI do an apm -s, the system does not wake up at mouse movement. (should i
create another bugreport on tat one or should we see where this goes before
deciding?)

resuming from apm -s is 100% a bios thing (most bioses have settings that
control what makes the machine wake up).....

OK - Then I suppose that the X wake up problem, is probably caused by the
promise controller BIOS and/or some conflicts with my PC BIOS. I've written to
Promise support, to get their idea on the matter, but haven't got anything back
yet. The X wake up on mouse movement problem is non-existant, if the Promise
controller BIOS is not installed. The other problem i have mentioned here will
be reported in a new bugreport in a few moments.

Here is the answer I got from Promise 

--8<-------------------------------------
The reason that your experiencing this is due to driver problem. The
card currently has not Linux driver to truly support the OS and any
function it has. Promise is currently working on the driver and there is
no ETA on when it will be release yet.
------------------------------------->8--

I don't know for sure, but I thought plenty of people was using the Promise
Ultra133TX2 in their linux boxes... Do You guys have another oppinion on this
matter?

Promise is just saying stuff... I can't explain why having their card in makes a
difference (I'm sure you're not using the binary only drivers) though....

It seems to work under Windows Xp, though. Do You have any idea what I could
try, in order to close in on the problem and/or a fix - I thought of compiling
and installing a 2.4.19-pre-latest to see if that could make a differende. I
won't be able to do this until tonight at the earliest!

2.4.19-pre7 does not show any changes inthis behaviour... At least not when
compiling using a near-similar-to-kernel-2.4.18-0.13.i686.config for configuration.

Any ideas to what I could try to change, in order to change behaviour on this issue?

Nothing changed, in relation to this bug, in RH 7.3

This problem is still totally up in the air as to wether it is a hardware issue,
local configuration issue, kernel issue, or XFree86 issue.  I'd suggest doing
some troubleshooting of this problem on mailing lists such as xpert,
linux-kernel, and possibly others to see if anyone else has suggestions as
to what to try - either to fix the problem, or to find more details as to what
is causing the problem.

Quite honestly, if we can't easily reproduce a problem with available hardware,
then it is next to impossible to try to fix.  Problems with APM tend to vary
wildly as to what the problem is, and quite often end up being hardware issues.

Considering the difficulty in troubleshooting this sort of issue, I need
to be honest and tell you that it would be very low priority to look into
further without a lot more detail.

If you can gather up sufficient detail to show that it is a kernel issue,
or that it definitely is not a hardware issue, or some other such detail
to narrow the problem down, it could help greatly to find either a proper
solution, or at least a workaround.

Sorry, I can't be of more assistance currently.

I think, that the error is actually caused by either

a) An oversimplified BIOS - My system is an IBM PC and the BIOS setup utility is
geared towards "normal" people. I can't ask it to monitor additional IRQ's for
Activity in the APM dialog, but only "Hard Disk Controller", "Serial Ports" etc.
This means that activity on my add-on Promise controller is not considered to be
worth keeping my system alive for and so, after a while the system may be going
in to an even deeper state of power-saving that what i usually experience. My
on-board controller is monitored for activity just fine.

b) Power Savings is aparrently a complete stranger to the people over at
promise. They have informed me that the adapter does not support any kind of
power saving, whatsoever. However i'm told that they are in fact working on this
for the Ultra 133-TX3 device at the moment, but cannot tell when the next
firmware upgrade will be ready.

c) all of the above

For the moment, I've moved my system Hard Drive onto the on-board controller,
which effectively eliminates the problem. The Promise Controller is still
installed in the computer(for when i am going to test the new firmware for
changes in this behaviour) but it's BIOS won't be installed, as there are no
drives attached.

I think that this is where the problem probably lies - Unfortunately I have no
clone pc with more tunable/generic BIOS possibilities to try on, so i'm having
trouble, deciding on either one of the described possible problem sources.

The reason I never experienced this problem on 7.2 is most likely due to the
fact, that the promise controller was first supported in 7.3, and I have always
used my on-board controller on RHL versions prior to 7.3.

Doing it all over again with RH7.3 and a 2.4.19 kernel, this is no longer an issue.
It seems that the older promise driver versions had a problem with telling the
system about disk activity on this device, making the system think that nothing
was being used, and thus brought to a complete Standby! I suppose a Resume from
Standby requires more than mouse movement, and that's what was happening...

With the 2.4.19 kernel I have yet to see a Standby situation - I strongly
believe that my problem has simply been corrected in the kernel

My hope now is that the 2.4.19 kernel makes it into limbo(or at least the
promise driver)