Recently after the kernel upgade to 4.7.6-1, as far as I know,
from time to time, quite often, my Dell XPS-15 9550 gives in, when emacs makes an auto-save file in the
background.
It is like a zombie out of linux:
What I mean by that is
command “ls” is greeted by "ls: no such command’
Rebooting the machine fails. I have to hard-reset the machine and need to boot the machine
in the recover-mode. Everytime, the machine recovers well.
However, I cannot login with the user ID any more, although I am still in /etc/passwd.
After the first incidence with the BTRFS / partition that includes the /home, I re-installed
tumbleweed with the XFS / and /home separately. Yet, all this emacs trouble is still going on
for more than three days by now.
I inserted two lines
(setq make-backup-files nil) ; stop creating backup~ files
(setq auto-save-default nil) ; stop creating #autosave# files
Are you running Emacs as a console or graphical app in a graphical Desktop?
If so, you should identify the Desktop.
You need to identify your TW release, you can display it in
cat /etc/os-release
If you’re running a graphical app, try running in a console window to see if there is a difference.
If you’re running in a graphical Desktop, are you saying that the entire Desktop is frozen in some way that you say you need to do a hard reset?
If your system is not completely frozen, you can try opening up a new console window and inspecting the last 10 lines or so of the system log to see if there is anything there. You can also launch top and see if a process is running wild, sucking up all CPU cycles or memory.
Although nothing is impossible, I can’t remember the last time I ran any kind of text editor in a windowed console that caused a screen freeze…
The login greeter “lightdm” got a bug recently. I switched to my login manager program from lightdm to gdm. Then, login problem disappeared.
By now, the ultimate zombie problem seems to be a hardware issue related to my SSD.
When the machine becomes a zombie and I give the simple “ls” command, the machine responds as
If `ls’ is not a typo, you can use command-not-found to look up the package that contains it, like this
cnf ls
Does the above response from the machine ring a bell?