Display Freezes Unless Mouse is Kept Moving

[Brodo]

When I have a display on the screen that has a an incrementing item on it such as a clock or a counter of some sort. I've noticed that the display stops updating unless the mouse is constantly jiggled.

The computer does not freeze up nor is any work lost. It's just that the screen does not keep the count updated.

When I jiggle the mouse the screen will update to the latest count but when I stop moving the mouse the screen will hibernate again after a couple of seconds.

Not a major problem but very annoying.

I also had this problem with Mandriva and obviously it has carried through to Mageia. It is not computer dependant this happens on every installation I've done irrespective of the hardware involved

Does anyone know how to fix it ?

Brodo

[doktor5000]

Sounds like faulty hardware, i'd say. If you could go into more details about hardware and attached peripheral devices that could help.
Also investigating in the logs may be a good point to start, examine maybe /var/log/messages and dmesg output after a clean reboot may give you some hints.

[Brodo]

Sounds like faulty hardware, i'd say. If you could go into more details about hardware and attached peripheral devices that could help.
Also investigating in the logs may be a good point to start, examine maybe /var/log/messages and dmesg output after a clean reboot may give you some hints.

I'm pretty sure it's not hardware. I have noticed this"freezing" of the display on every Mageia/Mandriva installation I've ever done and that covers a wide range of CPU's, Motherboards, GPU's, memory, the works. If I put Windows on the same hardware this problem doesn't occur. (Most of my machines are dual boot)

It only seems to occur with 3rd party programs such as BOINC or some other program that has a counter. The operation of the computer unaffected and the display updates to the correct value as soon as you move the mouse. If you stop moving the mouse it freezes again. The first time I saw it, I thought it was some kind of weird power saving feature.

There were no error messages in dmesg, if there was a hint there it was to subtle for me to pick as I'm not a software person .

The processor is only running about 20%, there's plenty of free memory and the swap file is empty. So it's not because it's paging

[andreano]

Does sound repeat when your screen freezes?
Can you unfreeze it by other means, like typing on your keyboard, (un)plugging AC power, open/closing the lid (think interrupt sources)?
Does playing sound (and other short-sleeping tasks) cause more frequent hangs?
Does it help to have `yes` running in a terminal?
Does it help booting with nohz=off or processor.max_cstate=1 on your kernel command line?

Other symptoms that are indicative, but not necessary:
Do you sometimes need to hold down a key in order for boot/shutdown/suspend to not hang?
Does your clock lag?

From your description, I am 99% sure you are experiencing this unsolved mystery:
https://bugzilla.novell.com/show_bug.cgi?id=579932
https://bugzilla.kernel.org/show_bug.cgi?id=12118

I have been participating in trying to track down this problem for 2 years. As you can imagine, I would _love_ to know what BIOS, motherboard and CPU you have on the systems you have experienced this.

My guess is that your hardware was bought around 2007-2010. You should not see many clues in /var/log/messages or dmesg (unless your kernel is compiled with debugging enabled), perhaps `dmesg | grep unstable` mentions an unstable clocksource.

[Brodo]

Does sound repeat when your screen freezes?

No the only thing that is effected is the updating of the 3rd party program.

Can you unfreeze it by other means, like typing on your keyboard, (un)plugging AC power, open/closing the lid (think interrupt sources)?

Yes, hitting a key will also unfreeze it

Does playing sound (and other short-sleeping tasks) cause more frequent hangs?

No, it's strictly a time thing, approx 15 seconds after the last mouse movement or key stroke

Does it help to have `yes` running in a terminal?

No

Does it help booting with nohz=off or processor.max_cstate=1 on your kernel command line?

Haven't tried that but I will.

Other symptoms that are indicative, but not necessary:

No other symptoms, Computer operation is quite normal otherwise

Do you sometimes need to hold down a key in order for boot/shutdown/suspend to not hang?
Does your clock lag?

No to both questions. The clock is as stable as any mobo clock

From your description, I am 99% sure you are experiencing this unsolved mystery:
https://bugzilla.novell.com/show_bug.cgi?id=579932
https://bugzilla.kernel.org/show_bug.cgi?id=12118

I have been participating in trying to track down this problem for 2 years. As you can imagine, I would _love_ to know what BIOS, motherboard and CPU you have on the systems you have experienced this.

My guess is that your hardware was bought around 2007-2010. You should not see many clues in /var/log/messages or dmesg (unless your kernel is compiled with debugging enabled), perhaps `dmesg | grep unstable` mentions an unstable clocksource.

This problem has been evident on every install I've done since MDV 2008, it does not occur if I install from my 2007 discs. It shown itself on a variety of motherboards (mainly gigabyte and DFI), bios versions and chipsets. CPU's have all been various incarnations of the Intel Core 2 family.

Apologies for taking so long to reply.

Brodo

[andreano]

Thanks. Very interesting to see that Intel Core 2 is the common hardware on all the failing machines.

On my Core 2 Duo T8100, dyn-ticks have been broken since the feature was introduced in Linux 2.6.24. It wasn't noticeable in normal desktop use before 2.6.33, and symptoms have varied since then. What happens is that the CPU fails to wake on a certain timer — I must feed it interrupts (user interaction) to keep it running (or keep it busy with something like `yes`).

I'm surprised that you don't hear repeating sound. When your CPU is stalled, there is no way your player software can feed your audio controller. The typical manifestation of that is that your audio controller repeats itself:
http://en.wikipedia.org/wiki/Buffer_und ... a_playback

Maybe your audio controller is smart enough to shut up in that case, I don't know. But it must fail somehow. Not immediately, because your audio controller's buffer lasts maybe half a second (mine does). If the hangtime is shorter, you won't hear anything wrong. If you can play music continuously while your screen is frozen for several seconds, you don't have the bug I'm talking about. How thoroughly did you test audio playback?

[Brodo]

I think we are discussing similar but different problems.

In my situation, it is definitely NOT the whole computer freezing, only the display for a program as described above. The program itself does not freeze, it continues operating normally but the display does not update. As soon as the mouse is moved or the keyboard touched the display updates to the correct value and then continues to update correctly for around 15 seconds. After this time the display then "sleeps" until the next mouse or keyboard input to that program. Video/audio playback is not effected, neither is the countdown timer on the player (although the problem is still evident on a susceptible program running on the same desktop).

It's as if the program loses contact with the X-server unless additional stimulation from a mouse or keyboard is provided

Brodo

[andreano]

How is audio playback not affected? Do you mean:
a) You have actually observed that audio is ok while your screen is frozen (for substantially longer than half a second)?
b) You never experience hangs while playing audio?

Only a) is conclusive.

Try this in a terminal while running the program that freezes your screen:
for ((i=0;;i++)); do echo -en '\r'$i; sleep 1; done

Does it hang too?

Code: Select all

if (it does){
    if (it skips numbers){
        your screen didn't update.
    }else{
        your CPU stalled.
    }
}

[Brodo]

How is audio playback not affected? Do you mean:
a) You have actually observed that audio is ok while your screen is frozen (for substantially longer than half a second)?
b) You never experience hangs while playing audio?

Yes to both - after your first email I tested very carefully

Try this in a terminal while running the program that freezes your screen:
for ((i=0;;i++)); do echo -en '\r'$i; sleep 1; done

Does it hang too?

I presume this script produces an output like

Code: Select all

bash: echo\rxxx: command not found

Where xxx is an incrementing number

I ran it for 15 minutes and it did not miss a beat despite the fact that the box was running at 100% cpu usage with other programs. While this was happening the display on BOINC was not updating unless stimulated. It made no difference which program was in the foreground.

Interestingly that script only seems to run under Konsole. I have 2 machines that run the LXDE desktop and under both LXTerminal and RXvt even though the script was running it did not produce any output on the screen. There was just the cursor sitting below the command until I hit ^C. The machine were operating normally at 60% CPU and there was no stuttering on audio playback

Brodo

[andreano]

Okay, your terminal was alive while BOINC was frozen, so your CPU cannot have stalled. I agree that we don't have the same bug. Sorry for being so over-confident.

As a sidenote, it looks like you mistyped the script into the terminal. You can paste into Konsole using Ctr+Shift+V.