Linux freezes completely except mouse pointer

Question

It is my first question, please be patient.

This is to me a general question since I saw many questions about Linux freezing (didn't help to apply the answers, including the "Raising Skinny Elephants Is Utterly Boring" keystrokes combinations sequence).

It should be general also because it used to happen to me in Ubuntu (the version "LTS" up to date in 2016) and also on Centos 7, which I installed about one year ago, on the same desktop, a 2011 HP Compaq 8000 Elite.

Basically everything is frozen, it appears there is no disk activity. Only the mouse pointer moves correctly, but clicks have no effect.

Up to now I am obliged to reboot the box.

Any suggestions about how to unfreeze the box in these cases and possibly search and suppress the reason?

Thanks Flosta

Solution

This is an error that just started happening for me in a specific context: I open the Gnome application search field by pressing the 'windows' key. I begin spelling my application, i.e. 'byobu', and before I can finish typing and select it, the gnome desktop freezes, though the mouse still moves. The only way I'm able to regain control is to switch to a virtual terminal, Ctrl+Alt+F1, log into that and then issue a kill command:

sudo killall -9 gnome-shell

This will kill the current shell, and gnome automatically respawns it leaving all your applications in the same state as when the desktop froze.

But note, there must be something slightly problematic with how Gnome respawns the shell, because if the issue happens a second time in the same session, killing the shell will log you out aborting any desktop applications you have running.

Comments

[Basile Starynkevitch]

connect remotely to the computer (so install ssh). Then run some commands (notably dmesg). Could be a graphics driver bug (so model of GPU is relevant, with exact version of driver)

[r_hribar]

^that, and it could also be a hardware problem, if the above suggestion fails just throw a whole bunch of diagnostics and stress tests at it. Especially RAM, as RAM issues can cause such weirdness.

[Admin]

Does this happen as soon as it boots up, or in response to something you do? Is it repeatable? How often does it occur?

[Flosta]

@BasileStarynkevitch Thanks, I always suspected something related to graphics. I will try that, although I am afraid that it may simply not respond.

[Flosta]

@Deuxis Thank you. Can you suggest some interesting diagnostics and stress tests and how to get them?

[Flosta]

@DrEval It does not happen at boot. It happens randomly, at least as far as I can understand. It can run for few days with no problem and suddenly stop. Sometimes it stucks much more often, around once per hour, and the day after start to run fine per 3-4 days. My feeling is that is linked to some conditions happening with browers...

[Flosta]

@Basile Thanks, I managed to ssh the computer. I tried to killall something (inspired by you and your comment to the other answer) and something happened. killall -TERM, though, was not working. When I tried killall nautilus I could interact with the mouse with what left on display (for exemple firefox tabs), but it was too messy. I could reboot.

[Flosta]

@Basile This is some GPU info (shortened): bash-4.2$ lspci -vnn|grep VGA -A 12 00:02.0 VGA compatible controller [0300]: Intel 4 Series Chipset Integrated Graphics Controller [8086:2e12] (rev 03) (prog-if 00 [VGA controller]) Subsystem: HP Device [103c:3647] Flags: bus master, fast devsel, latency 0, IRQ 31 Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at 1230 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915

[Flosta]

and: 00:02.1 Display controller [0380]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e13] (rev 03) Subsystem: Hewlett-Packard Company Device [103c:3647]

[r_hribar]

@Flosta good ol' memtest from boot (included in most distributions that come with a bootloader) should be enough to test RAM for any faults that may cause such behaviour. Besides that I don't really know, the only stress tests I've been doing on Linux were graphics.

[Basile Starynkevitch]

should use killall -TERM

[Basile Starynkevitch]

Ok should be killall -SIGTERM