![](https://seccdn.libravatar.org/avatar/389a9fcfce25eb695c9523b35c995100.jpg?s=120&d=mm&r=g)
On Sun, Feb 11, Patrick Shanahan wrote:
* Michael Fischer <michael@visv.net> [02-11-18 11:40]:
On Sun, Feb 11, Patrick Shanahan wrote:
* Michael Fischer <michael@visv.net> [02-11-18 00:10]:
Been a while, but I just got hit with the "X, keyboard and mouse all freeze at once" - no getting to another VT. But I could ssh in from another machine. As always when this happens, nothing useable in any logs.
always happens, you have made a bug report?
what logs, what video card, what openSUSE version, odd repos
It happens say with a frequency of say, once every 5 or 6 months over 5 years. Has not been enough to provoke me to a bug report. Would also cover 3 different machines, with different graphics cards, drivers, kernels, SuSE versions, etc.. This is also why I didn't bother to provide logs, etc. as there is too much history and variety to pin it down to the current setup. I was kind of hoping someone knew a good trick for coping with this sort of problem, short of a reboot. In case it is of use, the current setup is: Model: "ATI Ellesmere [Radeon RX 470/480]" Driver: "amdgpu" SuSE Leap 42.3 kernel 4.14.6-1.g45f120a-default Logs I examined were ~/.xsession-errors /var/log/Xorg.0.log `journalctl` which, besides xsession-errors being full of very repetetive browser junk, told me nothing of any error conditions.
Trying to `sudo kill -9 pidof X`, etc.. did absolutely nothing.
as root: systemctl isolate multi-user or init 3
Replying to both Patrick and Carlos: I run my systems from 3, then manually run `startx`. What would be the effect of `init 3` or its systemd equivalent in this case?
none, but, somehow you failed to mention that pertinent fact. and now "init 3" is an equivalent for "systemctl isolate multi-user", not the reverse
Sorry, and understood about systemd back-compat commands. And thank you for clarifying that `init 3` to a system brought up to that runlevel in the first place would have no effect.
did your "kill" operation actually kill a process? what ",etc" was tried? and i "assume" 'did absolutely nothing' actually means it didn't do what you expected or ...
`kill -9 pidof X` didn't kill X. Screen didn't change, and over the ssh session, `ps` showed X still there, with the same pid. This is what I meant by "did abosolutely nothing". As ~/.xsession-errors was full of noise about browser problems, I killed firefox and chrome processes, which did work (pids no longer in `ps`, sound cut out from the movie I was watching in chrome), but the screen did not update (i.e. the browser windows were still there, unchanged).
What does the CTRL-ALT-BACKSPACE, BACKSPACE sequence actually do "under the hood"? If my keyboard were responsive, I'd have tried that.
are you asking and answering or is the quoting obscured?
Hmm. Asking. Sorry if that somehow came out with confusing quoting.
is your keyboard freezing causing the problem? is your mouse still active?
No idea if keyboard freezing is *causing* the problem. To me it seems like more of a symptom. As stated in the original email, each of the screen, mouse and keyboard freeze together. There is simply no interactivity whatsoever.
you ask a lot but provide very little information :(
Sorry, but the system gave me very little information (logs, etc.) to pass along. I appreciate you trying in spite of the low level of such information. Michael -- Michael Fischer michael@visv.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org