Red Hat Bugzilla – Bug 71563
Promise Ultra133 TX2 - does not inform system about activity
Last modified: 2007-04-18 12:45:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020721
Description of problem:
I installed a Promise Ultra133-TX2 controller in my IBM PC a while ago, and
whenever I've decided to try to put my harddisk on it i've gotten frustrated
with the fact that it allows my system to standby(even during activity - not to
mention the normal ext3 committing activity), and removed my controller again...
The problem is always seen, if booting the system(initlevel 5 on my system) and
just letting it stay there for a while... When I want to work with the computer,
i need to activate the keyboard, the mouse is not enough, and /var/log/messages
shows that the system is resuming from standby, re-init'ing my ethernet
controller and everything...
I've even had this happening while building garome from the net... suddenly in
the middle of everything the system has gone into standby, during a filetransfer!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot to initlevel 5
2. Wait for APM to cause a standby event
3. Move the mouse(doesn't work)
4. Press "anykey"(wakes up)
5. check /var/log/messages for APM events
Actual Results: I can see that my system has been in standby mode and that it
Expected Results: It should not have went into standby in the first place,
that's not happening with my onboard controller
That said, my system is an IBM PC300-PL and installing a secondary
ide-controller is "unsupported" this could easily be a BIOS issue or
something... What i'm looking for, if not a fix, is a way to determine where the
bug is - if it in the BIOS I need to get a new machine :)
Tried 2.4.19 kernel, which I was told contained fixes to the Ultra133-TX2
driver... Same result
This has been an annoying problem for me on RH7.3, which is where I have done
most testing... Only just seen it on Limbo!
I had a talk with alan cox today, and given his input to the problem, and some
testing that i did, I'm closing this case as "not a kernel problem".
The problem is much more likely to be with that my system BIOS doesn't recognice
the second ide controller and so does not look as if in use if that controller
is active. kernel option apm=off eliminates the problem on the kernel i've tried
so far (2.4.19) but should work on other kernels as well...