If I leave my computer idle for two long (half hour or so) I come back to find a frozen screen filled with scrambled green boxes. I believe my computer is still functioning, as I was able to complete copying files to it via samba.

I boot into my SuSE 8.1 system with the acpi=off grub option, as my promise raid controller will not boot without that option. If I'm working at my computer or playing games I can go for hours without problem. It looks like it's trying to go into a monitor suspend mode in a way that my Geforce 4 ti4200 no longer likes. I attempted to dissable that feature through the kde control pannel with no luck, any thoughts?


--Steve

I have a problem along the same lines. On my desktop machine, the standby buttons works almost very well, except that it leave the monitor on and displaying random patterns. Nothing "locks up" because it all gets restored nicely once I bring the computer out of standby, but I would like the standby call to turn the display off before it goes into stand by.

PS: I'm using a custom compiled 2.4.19 kernel (with ACPI turned on) on an Intel BX440 motherboard and an ATI Rage128-AGP video card.

With the older Rage cards and older monitors, the best way I was able to get the monitor to show nothing was to set the computer's BIOS to send Video and Horizontal sync plus black on uspend, and not to try to turn it off in BIOS-- card was not sending monitor a wakeup signal it understood, and the thing was very good for its time. The monitor in fact is used on a test bench now for setting up new builds and repairing computers. Was card, not monitor.

With some of the new GeForce4 cards, the only way I know to get them to wake monitors right is to use a completely PNP monitor and NVidia mfr drivers (closed source) with an NVidia kernel module appropriate for your distro and version of distro. A really old monitor might need a power management setting of S1+S3 in BIOS, this will force a resync and complete frame send on wakeup-- monitor problem, not card, in many cases(new card made for new style montiors that have newer power management capabilites, a power management capability mismatch will cause this also).

Sorry, no one answer, depends on how old monitor is in termes of model introduction to market versus card in general terms. you would do best with radically new cards to buy a CRT type monitor that is of like vintage as far as model age-- then you are likely to get two peas that will get along in one pod (work together in one system). This is why Linux will happily function in remote access mode, Linux itself does not care about X at all adn can work from console while X is totally locked. And X can be ahppy while the monitor can be unhappy with the rate at which the card is comping out of suspend at (some cards will go to highest refresh rate coming out of suspend if a complete resync negotiation is not forced, then monitor cannot display right and over long run is damaged electronically trying to handle invalid refresh rates while card and rest of computer is fine and functioning-- best fix is newer monitor or much older power management called for in BIOS, sorry).

John Danielson.

I just recently bought a new motherboard, and I think I'll take a look at the options for it. As it stands I have never instructed to suspend my computer, I don't think that is the problem. It seems that my computer is trying to turn the monitor off after activity, but it never happens. It goes straight from functional to funky.

Again, I tried to turn off display power management through my kde control center, but no luck. Does anybody know where the config file for this option might lay?

Thanks

--steve

This *is* getting very informative, however with my problem, the monitor *does* turn off normally when the timeout is reached when the computer is NOT in standby. It comes back just fine too. It is only when I put the computer in standby using the hardware standby button (maybe I should try a software call?) that it just hangs. It is almost like video card just hangs, but the resume command resets it just fine and everything is back to normal.

Actually I remembered I did try putting it in standby after the monitor went to sleep. When I did it woke up the monitor and displayed the random patterns again. Interesting.

Ok-- what I mean by suspend is what the BIOS calls what you mean by standby, I think. The BIOS has a sleep mode also, and that may be what you are doing, but that should not do what you are experiencing.

What the BIOS can do is go to what it thinks of as suspend-- and there are two ways it can do so. There is, in modern BIOSs, a mode called Power-On Suspend, and a mode that causes RAM to be dumped to HD and then an almost complete powerdown to occur.

Power-on suspend suspends to RAM, and having too power-hungry a set of components can cause a RAM decay during suspend -- the result is junk in RAM, junk in display on refresh. What I have experienced MUCH more of is either a card or a monitor not getting along-- and this would be seen with chunks of possibly green with jaggies in them as the monitor tries to keep up with a radically diferent video feed rate when it wakes up than when it was sent to sleep and cannot cope (that is what I talked about above, and it DOES look like a video card lock but in this case the monitor is ignoring the card). So, what I think is happening, is that your computer is suspending to RAM in BIOS, and Linux is wanting a suspend to HD, or vice versa. I do not know enough about slack to know what Power Management it supports, but on my box with Mandrake I have to tell my computer's BIOS to do an S1+S3 suspend to get my monitor to wake up right with valid video. what appeared to be happening is similar to what are experiencing now, when I told it to suspend to HD-- I think Mandrake was trying to do one and the Computer the other thing. This general thing caused havoc with Windows users also, usually after their CMOS batteries died for the first time and the CMOS defaulted to a different PM than widnwos was set to support-- computer would go to sleep, lock on wakeup attempt, user wold power down computer, then get frustrated when same thing happened next time they left ti on by mistake or intent until it put itself to sleep with BIOS and then hibernated in some cases (which meant suspend the way BIOSs were writen).

So, one of two things is happening electronically(and I anthropomorphized deliberately to show the relationships clearly), and best and easiest answer is to set BIOS to multimode and let Linux choose which to use. Unfortunately, if you set no PM in KDE and lower levels have PM enabled, or BIOS has PM enabled, you WILL get PM, but it will not be something Linux will expect or can dale with right (IT cannot read the BIOS's "mind" as it thinks of PM differently than some modern BIOSs do, so the BIOS has to meet Linux's needs-- and it can).

Essentially, you set the BIOS to meet the needs of the oldest video part of computer, the rest will usually play along-- the exception is the latest cards, which are intended to work with the latest PM and the latest monitors, and are less backward compatible than older cards. If you ware right, and it is the card itself, then it is just possible the card is trying to PM its video to ITS RAM, and the computer around it is trying to suspend to HD and the rersult is the video RAM does not get saved right at all and you get junk on wakeup-- shadowing video RAM in such an event, if you have enough RAM to do that, might help some-- in this case, an older box might sync what it saves to the video aperture stored in RAM which is in essence the active frame buffer. If that newer card had 128 MB and you had a 16 MB frame buffer set, you might get a partial amount of junk on wakeup. That is one reason why I have a 64 MB frame buffer and a 64 MB video card and the card is older (GeForce2). If I had the money, would be trying a GF4 Ti 4200 or one of the less expensive Matrox Quadros instead of my lowlier card, but cannot afford one right now-- so can say it is probably the generation of card and the way it handles PM versus Linux kernel version, video driver version, and Linux distro PM handling as it was scripted in your distro version. And the most likely easy fix is a BIOS fix or programming of same in BIOS setup run right at boot time plus maybe a BIOS\CMOS battery or 48-72 hours on-time to charge an older battery. so the settings are kept if they disappear way too often (battery keeps CMOS table that records your settings refreshed as well as running clock).

John Danielson.

With all due respect, my post has been hijacked by somebody with a very different problem than mine. Although, as the other poster mentioned there is a lot of interesting information coming out of this, and I thank you for that.

I have never attempted to suspend my cpu, never put it to sleep, never instructed it (in bios or otherwise) to do it by itself. With my laptop (also running SuSE 8.1) the default is as so... 4 minutes to screensaver, another 4 or so minutes and the screen powers off. The laptop never stops running, never suspends to disk, and pops back up the second I move anything. It seems that my PC is attempting the same sequence, but freezing my video card on the screen power off command. I have acpi=off set in my Grub, as my computer won't boot without that. (motherboard with raid chip) I'm not terribly familiar with acpi, but I thought it was some sort of power management feature, could that be part of my problem?

Also, I recently noticed that my bios has a default monitor power saving feature enabled, which I have disabled to no avail. Besides bios where might I find power management.

Thanks

--Steve

Well, what I was TRYING to get across is that the BIOS will rule over Linux, NOT vice sersa. So, if your BIOS is set to any kind of power mangement or the battery deis, it could DEFAULT to PM.

BUT, I think you understand that now.

try seeing if the boot option apic=no or apic=off helps (and it is perhaps just barely possible that the option you HAVE should be spelled apci instead of acpi (depends on what exactly the distro language translaters did-- acpi is advanced Controller\Peripheral Interface, adn is not an american way to say that, we would say Advanced Peripheral Controller Interface (or PCI bus)).

John Danielson.

Again, thanks for the interesting info. acpi=off is what gets my computer to boot (locks up on pci bus scans without it) I use SuSE which is a German distro, I don't know if that would be the reason for the acpi/apci spelling difference.

I'm aware that the lowest common denominator in computers typically has precedence, and have insured that all bios settings regarding any form of power management are turned off. I still can't imagine what would be crashing my video card. If I got the scrambled screen in the middle of working, I would have assumed hardware issue. But as it only happens if I leave my computer I have to guess that some form of power management is causing that to happen. I've never had this problem before with the only things having changed being the motherboard and the acpi=off option. Oh well, I'll keep playing with it.

As always thanks a million.

--Steve

There should be no difference in the spelling because it will always be spelled the way Linus wants it because it is part of his kernel domain.

There is some confusion of terms because both of them occur in PCs and the Linux kernel. The "ACPI" stands for the "Advanced Configuration and Power Interface", but the "APIC" stands for "Advanced Programmable Interrupt Controller". I believe it is ACPI that we want to be dealing with here. I don't know much about "APIC" other than it is a concern dealing with multi-processor motherboards. There is no "APCI".

One of the reasons I "hijacked" this thread (sorry about that), was that I believe I was getting the same scrambled screen when I was putting my computer in standby. I thought that the two symptoms might be related in that your video card is going to sleep/standby or whatever the same way, only yours never wakes up! The same solution might help both of us.

I know with my system, that the going to sleep and not waking up of my NVidia card disappeared when I changed my PM settings-- adn that this has happened on boxes with Windows also, and same fix worked there. I also know that US computer folks and Engineers use different spellings for teh bus controller acronyms than European folks. Good luck with your problem.