LMDE4

My brother says the symptoms happened to him when he was working with a Unix mainframe computer at Sun Microsystems. I had it happen to me using Ubuntu. Now it has happened using LMDE 3 and LMDE 4. It has happened using different computers and different monitors, including CRT. I even tried using the original keyboard, wireless keyboard, secondary USB keyboard, and a Bluetooth keyboard.

The computer and peripherals function normally for a long time (days, weeks). Neither my brother nor I know what triggers it, but the screen goes blank and the keyboard no longer functions, not even to toggle the indicators (F-lock, Caps-lock, Num-lock) [never figured out how to toggle the fourth indicator light]. My brother could go to another terminal and reset his terminal, but I do not have that option. Reboot seems to be my only option. After reboot, the system functions normally.

The hardware is functioning normally, no loose or flaky connectors or connections. Happened using different computers and different keyboards. My brother suspects some buffer or counter is overflowing, but is unable to determine which is not programmed or buffered to prevent overflow from causing problems.

Anyone else have this problem?

Anyone have a solution?

Just a suggestion: does the LMDE os use suspend and hibernate properly?
In which case is the swap partition large enough?

Also what are your hardware specs?

When the lights on your keyboard go dead, it usually means either a kernel problem or, if you're in X, an Xorg/evdev issue. If it's a kernel panic, that will show up afterwards in the kernel log. If it's X, it might or might not show up in the previous Xorg.0 log. I would check both if only to check them off my list.

Never tried suspend or hibernate as I never found a use for it. This is a desktop computer, not a mobile device.

System: Host: lmde Kernel: 4.19.0-13-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0
Desktop: Cinnamon 4.8.6 wm: muffin dm: LightDM Distro: LMDE 4 Debbie
base: Debian 10.2 buster
Machine: Type: Desktop System: MSI product: MS-7693 v: 4.0 serial: <filter>
Mobo: MSI model: 970 GAMING (MS-7693) v: 4.0 serial: <filter> BIOS: American Megatrends
v: 22.2 date: 12/16/2014
Battery: Device-1: hidpp_battery_1 model: Logitech M570 serial: <filter> charge: 15%
status: Discharging
CPU: Topology: 8-Core model: AMD FX-8350 bits: 64 type: MCP arch: Bulldozer
L2 cache: 2048 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 67019
Speed: 4188 MHz min/max: N/A Core speeds (MHz): 1: 4188 2: 4187 3: 4188 4: 4188 5: 4187
6: 4164 7: 4187 8: 4188
Graphics: Device-1: AMD Curacao PRO [Radeon R7 370 / R9 270/370 OEM] vendor: Gigabyte
driver: radeon v: kernel bus ID: 01:00.0 chip ID: 1002:6811
Display: x11 server: X.Org 1.20.4 driver: ati,radeon unloaded: fbdev,modesetting,vesa
resolution: 1920x1080~60Hz
OpenGL: renderer: AMD PITCAIRN (DRM 2.50.0 4.19.0-13-amd64 LLVM 7.0.1)
v: 4.5 Mesa 18.3.6 direct render: Yes

Partition: ID-1: / size: 1.78 TiB used: 439.50 GiB (24.1%) fs: ext4 dev: /dev/sdc2
ID-2: swap-1 size: 8.20 GiB used: 140.1 MiB (1.7%) fs: swap dev: /dev/sdc1

Has it happened again?

Suspend, sleep, hibernate etc. can be disabled completely.
Although these functions shouldn't cause problems and power saving is important on desktop computers, too.
But if that's what you want, start by disabling them in your power manager. Or nuke your power manager completely. Since you don't need it.

I thought I made it clear that the lights on the keyboard are frozen in that they will not toggle when commanded from the keyboard.

I have no idea of the logs to which you refer, so I did a search for kernel.log and for Xorg.0.log.

I was unable to find a kernal.log, but I was able to find /var/log/Xorg.0.log, but there does not seem to be any indication of the failure to respond to the keyboard nor of the forced reboot. I presume that the information is ephemeral and must be accessed upon reboot or be lost forever. Since I did not know to do this after the problem occurred, I must wait for the next instance to acquire the appropriate log entry.

Basically, the keyboard stops responding to key presses, the screen goes blank and the audio stops when further keyboard input is required. The computer is still running, just not accepting keyboard commands.

Just for the record, most distros keep two versions of the Xorg log: the current run and the one before. The older ones are scrapped. So if X fails in any way, the next time you boot, you'll need to look at the previous record. If there's anything significant in that, you can always copy it to a place of safety. The kernel messages are kept indefinitely in a continuous log but the names can vary. There's usually one called messages which contains the kernel messages and those from various system daemons. But most distros keep separate logs for the kernel and the rest of the system as well as the messages log. The kernel one tends to be called kernel.log or kern.log but you may need to list /var/log to find out what it's called on your system..

Does not happen often, but when it does, I should find something in the Xorg.0.log or is there other logs that may show the problem? Do you have any suggestions as to what other logs I should access when this problem recurs? To this end, I am not going to shut down the computer until the problem exhibits itself again and access the suggested logs after a reboot.

I do use sleep. Sleep seems to function properly as I am unaware of any issues related to sleep.

Acknowledged the existence of /var/log/Xorg.0.log and /var/log/Xorg.0.log.old, with the relevant log being /var/log/Xorg.0.log.old. Unfortunately neither cover the relevant date and time.

I did find /var/log/kern.log, /var/log/kern.log.1, /var/log/kern.log.2.gz, /var/log/kern.log.3.gz, and /var/log/kern.log.4.gz with the relevant log being /var/log/kern.log.1. I deleted all the UFW BLOCK entries as they were very repetitive and seemingly routine. The remainder of the log entries seem to be routine, but are submitted for your inspection. They are:

Jan 3 12:58:03 lmde kernel: [386859.488414] usb 1-4.5: reset high-speed USB device number 6 using ehci-pci
Jan 3 12:58:04 lmde kernel: [386859.599089] sd 6:0:0:0: [sdg] 7892991 512-byte logical blocks: (4.04 GB/3.76 GiB)
Jan 3 17:10:12 lmde kernel: [401988.340301] usb 1-4.5: reset high-speed USB device number 6 using ehci-pci
Jan 3 17:10:12 lmde kernel: [401988.451084] sd 6:0:0:0: [sdg] 7892991 512-byte logical blocks: (4.04 GB/3.76 GiB)
Jan 3 17:28:50 lmde kernel: [403106.569060] usb 1-4.5: reset high-speed USB device number 6 using ehci-pci
Jan 3 17:28:50 lmde kernel: [403106.679889] sd 6:0:0:0: [sdg] 7892991 512-byte logical blocks: (4.04 GB/3.76 GiB)
Jan 3 21:19:57 lmde kernel: [416973.831180] usb 1-4.5: reset high-speed USB device number 6 using ehci-pci
Jan 3 21:19:57 lmde kernel: [416973.941948] sd 6:0:0:0: [sdg] 7892991 512-byte logical blocks: (4.04 GB/3.76 GiB)
Jan 3 21:35:01 lmde kernel: [417878.131522] Bluetooth: hci0: urb 00000000ab562e7e failed to resubmit (113)
Jan 3 21:35:01 lmde kernel: [417878.131763] Bluetooth: hci0: urb 000000007fb1505a failed to resubmit (113)
Jan 3 21:35:01 lmde kernel: [417878.133026] Bluetooth: hci0: urb 000000005fa7bc0d failed to resubmit (113)
Jan 3 21:36:16 lmde kernel: [417952.972882] Bluetooth: hci0: urb 00000000bbceb3f9 failed to resubmit (113)
Jan 3 21:36:16 lmde kernel: [417952.973129] Bluetooth: hci0: urb 0000000062745bf7 failed to resubmit (113)
Jan 3 21:36:16 lmde kernel: [417952.974380] Bluetooth: hci0: urb 00000000cbf6db69 failed to resubmit (113)
Jan 4 08:18:25 lmde kernel: [456482.538858] usb 1-4.5: reset high-speed USB device number 6 using ehci-pci
Jan 4 08:18:25 lmde kernel: [456482.653315] sd 6:0:0:0: [sdg] 7892991 512-byte logical blocks: (4.04 GB/3.76 GiB)
Jan 4 08:20:52 lmde kernel: [456629.845648] usb 1-3.6: reset high-speed USB device number 5 using ehci-pci
Jan 4 13:19:46 lmde kernel: [474563.511609] usb 1-3.6: reset high-speed USB device number 5 using ehci-pci
Jan 4 16:23:36 lmde kernel: [485593.863468] usb 1-3.6: reset high-speed USB device number 5 using ehci-pci
Jan 4 16:24:07 lmde kernel: [485624.715812] usb 1-3.6: reset high-speed USB device number 5 using ehci-pci
Jan 4 21:12:16 lmde kernel: [502914.045423] audit: type=1400 audit(1609819936.295:41): apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="/home/james/.icons/default/index.theme" pid=18391 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Jan 4 21:12:16 lmde kernel: [502914.305050] nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead.
Jan 4 21:34:49 lmde kernel: [504267.348535] NET: Registered protocol family 38
Jan 4 21:35:07 lmde kernel: [504285.578235] EXT4-fs (dm-1): recovery complete
Jan 4 21:35:07 lmde kernel: [504285.601409] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
\00\00\00\00\00\00\00 * deleted similar * \00\00\00\00\00\00\00 * FORCED REBOOT *
Jan 5 01:36:58 lmde kernel: [ 0.000000] Linux version 4.19.0-13-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.160-2 (2020-11-28)

I do not see anything that would cause the problem, but I am submitting this to see if you find anything useful. Perhaps there may be other logs that may contain useful information?

Sorry, I can't see anything there. The point I was making is that you should check those particular logs first if you get something that seems to be a hardware lockup. They might or might not give you a lead but it's always worth checking.

The numbered gzipped logs are back numbers. You can delete the oldest of these periodically to recover space. The UFW logs come from your firewall.

btw, you should always enclose print-outs within [code] and [/code] brackets. It makes them easier to read.

Is the entire system catatonic at this point? Are you able to access it via the network and snoop around? Or at least do a "clean" reboot (not just an abrupt power cycle)?

I sometimes find that after rebooting as part of an upgrade my keyboard will be inoperable when I'm at the Grub menu but when it times out and boots, all is well. But... my keyboard didn't work a few days ago following a upgrade/reboot. Unplugged the (wired, Model M) keyboard. No effect. Power cycled the system and all was well after the fscking needed as a result of the unceremonious shutdown. Of course, there was nothing in any log files to provide a clue as to explain what happened.

Unless the keyboard is working for you and then, in mid command, it stops working, I would suspect something related to power saving and/or a screensaver locking problem. I would try disabling any power saving options and the screen locking option of any screensaver to see if that corrects the problem. Other than maybe shutting down the monitor, I'm not sure that feature makes a lot of sense on a desktop system. Anyway, it'd be worth a try.

(It seems to be the season for intermittent problems. :^/ )

Good luck...

What is sleep by your definition?

1 members found this post helpful.

The computer seems to still be running normally. When this first happened, I was running Ubuntu. I know the computer was running normally, but with keyboard/trackball disabled. I was running BOINC and the CPU fan was running full blast as usual. As with UNIX, Linux can sometimes disconnect the keyboard/trackball from the system. Neither my brother nor I know what triggers this event. Unknown is how to reconnect the keyboard/trackball to the system without another terminal online. The only recourse is to restart. Is the "abrupt power cycle" the same as pushing the restart button on the computer?

Sounds like a similar problem to mine except you have a clue as to the triggering event. In my case the computer has been running for a long time continuously and the problem occurs with the additional symptom of a blank screen (all white in my case). Seems this is a UNIX flaw that carried over when the UNIX code was enhanced with a graphical interface. Additionally, this problem is not unique to this computer. It has happened with every computer I used while running Linux. I have the habit of leaving the computer running.

Your suggestion sounds logical, but in my case, there is no evidence that either screensaver nor sleep function were activated while I was actively using the computer. When using Office, I would wait about ten minutes before pressing the reboot button so that the auto-save feature would save my work.

I thank you for your comments and advice. I hope that when this problem recurs, the log will show something useful. Perhaps you might know which logs I should monitor?