[Solved] Random System Crashes/Black Background

arcdmp · 2018-01-16 07:02:34

I've had Arch running smoothly for almost 4 years.

However, recently (past 3-10 months) I've had crashes that are making me lose my mind. I haven't found any thread that vaguely looks like what's happening, so here goes.

I'm running encrypted Arch (LUKS) on an Asus N56VM laptop, booting from an external hard drive (Seagate Backup Plus Slim 1TB). It's using KDE as my DE, and this setup has worked well the entire time. Any small issues I've been able to solve on my own, either from the Wiki, manpages, or a little searching.

These crashes happen fairly frequently, from twice a week to three times in the same day, the exact same way every time:
The background goes black, the disk becomes inaccessible, and after 2-5 minutes everything finally hard crashes. Occasionally, the CapsLock light will be flashing. As soon as the background goes, nothing new runs either. All CLI tools give back weird I/O errors. I can't switch to another TTY. Rarely (eg. once or twice) after the Black Background, KDE appeared to catch/restart something, and everything reverted safely. This isn't the norm, however.

There doesn't appear to be anything out of place in dmesg, journalctl, or coredumpctl. Xorg logs also look like everything ran smoothly. The last boot's journalctl always abruptly stops near the crash. This might make sense, though, since as soon as the crash happens, nothing can touch the disk.

There are no usage patterns/common programs running when this happens. Sometimes, I'll have just Konsole running, and other times I'll have multiple different programs up.

I though maybe there could be something wrong with the drive, but it has never randomly disconnected (when being used other than my OS), and there are zero corruption issues with any of the files that are on there. There are also no noises/scratching/clicks the entire time, even during the crash. The only weird thing about it is that smartctl can't read its SMART data, but that could be because I reformatted the entire drive to put the encrypted Arch system on it.

$ sudo smartctl /dev/sda -a -T permissive
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.14.13-1-ARCH] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

Read Device Identity failed: scsi error unsupported field in scsi command

=== START OF INFORMATION SECTION ===
Device Model:     [No Information Found]
Serial Number:    [No Information Found]
Firmware Version: [No Information Found]
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   [No Information Found]
Local Time is:    Tue Jan 16 00:44:21 2018 EST
SMART support is: Ambiguous - ATA IDENTIFY DEVICE words 82-83 don't show if SMART supported.
SMART support is: Ambiguous - ATA IDENTIFY DEVICE words 85-87 don't show if SMART is enabled.
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

I've also run memtest86, and the results are completely clean.
What worries me a lot is that twice in the past month, these hard crashes have resulted in a bootup "error in filesystem" messages. Both times, I've successfully repaired it manually with fsck, but luck may be running short.

Maybe this problem is unfixable, but right now I really want to know why.

I should also add, there's nothing else out of the ordinary (other than these total crashes). No odd pacman errors, conflicts, upgrade problems, crashes in other programs, overheating/increased fan speed, something strange eating up CPU, etc... I've micromanaged my system as carefully as possible.

$ uname -a
Linux arch 4.14.13-1-ARCH #1 SMP PREEMPT Wed Jan 10 11:14:50 UTC 2018 x86_64 GNU/Linux

These are all the xf86 drivers installed:

multilib/lib32-libxxf86vm 1.1.4-1
    X11 XFree86 video mode extension library (32-bit)
extra/libxxf86vm 1.1.4-1
    X11 XFree86 video mode extension library
extra/xf86-input-libinput 0.26.0-1 (xorg-drivers)
    Generic input driver for the X.Org server based on libinput
extra/xf86-input-synaptics 1.9.0-1 (xorg-drivers)
    Synaptics driver for notebook touchpads
extra/xf86-video-intel 1:2.99.917+802+gaf6d8e9e-1 (xorg-drivers)
    X.org Intel i810/i830/i915/945G/G965+ video drivers
extra/xf86-video-nouveau 1.0.15-2 (xorg-drivers)
    Open Source 2D acceleration driver for nVidia cards
extra/xf86-video-vesa 2.3.4-4 (xorg-drivers xorg)
    X.org vesa video driver
extra/xf86vidmodeproto 2.3.1-3
    X11 Video Mode extension wire protocol

PS. I tried uninstalling xf86-video-intel, but sddm failed to load until I reinstalled it.

Last edited by arcdmp (2018-01-16 19:47:37)

jasonwryan · 2018-01-16 07:13:35

Given the lack of data in your journal, I would imagine it is some sort of hardware error. If not the disk, then the cable or some other part of your infrastructure (MB, power supply, etc)...

seth · 2018-01-16 11:04:16

Either the drive is broken or the connection to it is. If segate sells a "backup" drive that has no (proper) SMART support, you've been conned.
I guess it's USB connected? Try it (SMART wise) on another host and with different cables. If it's always reporting the same mess, backup your data from it. If it's not the connection, the drives firmware is broken.

Fyi, formatting a drive has no impact on it's SMART features.

arcdmp · 2018-01-16 19:47:15

jasonwryan wrote:

If not the disk, then the cable...

I feel a bit silly now, this appears to be the problem. The USB connection on my machine is not seated very tightly, and despite not being able to crash it just by vigorously wiggling, when I pulled the drive out & plugged it back in, the background went black and crashed the exact same way.

seth wrote:

Either the drive is broken or the connection to it is. If segate sells a "backup" drive that has no (proper) SMART support, you've been conned.
I guess it's USB connected? Try it (SMART wise) on another host and with different cables. If it's always reporting the same mess, backup your data from it. If it's not the connection, the drives firmware is broken.
Fyi, formatting a drive has no impact on it's SMART features.

It turns out the drive actually has SMART, I simply couldn't access it from my booted Arch system.
Are these stats worrying? I used CrystalDiskInfo, and some of the numbers looks worryingly bad despite the blue tickmark next to them:
https://imgur.com/xNPfvOn

Thanks so much for the help, I hadn't thought of something beyond software.

Last edited by arcdmp (2018-01-16 19:56:06)

seth · 2018-01-16 19:53:03

Please replace the oversized image with a link.

The only really relevant value (in most cases) is the most right one.
The worrysome field is the pending sector count, you may want to run badblocks on the disk. The value should go back to 0 and ideally the re-allocation value doesn't rise.
The other things are explainable by the wonky connection (because the connection also provides power supply)

arcdmp · 2018-01-16 20:05:39

Is it safe to run the non-destructive read-write Test (badblocks -nsv /dev/sda) from the Arch system on itself?
Or should I do it from another machine?

seth · 2018-01-16 20:07:04

If you don't have to, do it offline.
https://grml.org/

Arch Linux

#1 2018-01-16 07:02:34

[Solved] Random System Crashes/Black Background

#2 2018-01-16 07:13:35

Re: [Solved] Random System Crashes/Black Background

#3 2018-01-16 11:04:16

Re: [Solved] Random System Crashes/Black Background

#4 2018-01-16 19:47:15

Re: [Solved] Random System Crashes/Black Background

#5 2018-01-16 19:53:03

Re: [Solved] Random System Crashes/Black Background

#6 2018-01-16 20:05:39

Re: [Solved] Random System Crashes/Black Background

#7 2018-01-16 20:07:04

Re: [Solved] Random System Crashes/Black Background

Board footer