A couple of months ago, I had been using Ubuntu 16.04 on a Thinkpad T570 for a year or so, when my laptop windowing crashed for the first time. I restarted it, and it went back to normal for a week or so before doing it again. Over the next couple of weeks, it did this a half dozen times. For the next two weeks after that, it was completely stable and didn't freeze once. Last week, it started crashing again.
The symptoms are:
- Side bar disappears
- Components of the top bar disappear
- Top bar itself disappears
- Lose ability to switch windows
- Application windows stop responding or rendering
- May shutdown windowing completely and go to a black screen.
I ran Lenovo's builtin hardware diagnostics, and everything comes back fine. So I decided to try upgrading to Ubuntu 18.04 to see if that would solve the issue. I did not do a clean install, but upgraded instead.
In the week since the upgrade, 18.04 has crashed twice. The behavior is very similar to the 16.04 crashes, though the error messages and speed of the crash seem somewhat different.
The error messages from this last crash, which are repeated continuously until I hard shutdown are:
EXT4-fs error (device nvme0n1p2) ext3_find_entry:1436: inode#[NUMBER]: comm gmain: reading directory lblock 0systemd-journald[268]: Failed to write entry ([NUMBER] items [NUMBER] bytes), ignoring: Read-only file system
Other than that, I don't have other concrete data points to help nail down what's going on. But here are a few other thoughts that might be useful:
- As far as I can tell, nothing I'm doing triggers this response. I spend most of my time in Chrome, Pycharm, and the command line. I can be doing anything in any of those (or other applications) when this happens.
- My system is pretty stock. I don't do a lot of tinkering with system settings, and hadn't messed with anything in a while when the first crash happened.
- The reboot after a crash isn't always successful. Sometimes it'll get stuck on the Lenovo logo, sometimes a blank screen, sometimes Ubuntu's logo will appear for a bit before a purple blank screen.
- It seems like waiting longer between shutdown and reboot increases the likelihood that the restart will be successful.
Any thoughts on what might be going on would be greatly appreciated! Thanks!
Update 1
In repsonse to @heynnema suggestion:
The SMART Data & Tests button is grayed out and cannot be clicked (on any device/partition). I did: sudo apt install smartmontools, after which the SMART Data & Tests button stayed gray. In an attempt to get some relevant information, I then ran sudo smartctl -a /dev/nvme0n1p2. It doesn't produce any information including "sector", but the output is below:
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-29-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: SAMSUNG MZVLW256HEHP-000L7
Serial Number: S35ENX0J599958
Firmware Version: 4L7QCXB7
PCI Vendor/Subsystem ID: 0x144d
IEEE OUI Identifier: 0x002538
Total NVM Capacity: 256,060,514,304 [256 GB]
Unallocated NVM Capacity: 0
Controller ID: 2
Number of Namespaces: 1
Namespace 1 Size/Capacity: 256,060,514,304 [256 GB]
Namespace 1 Utilization: 168,824,696,832 [168 GB]
Namespace 1 Formatted LBA Size: 512
Local Time is: Thu Feb 28 18:47:38 2019 UTC
Firmware Updates (0x16): 3 Slots, no Reset required
Optional Admin Commands (0x0017): Security Format Frmw_DL *Other*
Optional NVM Commands (0x001f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat
Warning Comp. Temp. Threshold: 69 Celsius
Critical Comp. Temp. Threshold: 72 Celsius
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 7.60W - - 0 0 0 0 0 0
1 + 6.00W - - 1 1 1 1 0 0
2 + 5.10W - - 2 2 2 2 0 0
3 - 0.0400W - - 3 3 3 3 210 1500
4 - 0.0050W - - 4 4 4 4 2200 6000
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02, NSID 0x1)
Critical Warning: 0x00
Temperature: 28 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 1%
Data Units Read: 3,685,965 [1.88 TB]
Data Units Written: 8,000,875 [4.09 TB]
Host Read Commands: 54,265,691
Host Write Commands: 86,676,003
Controller Busy Time: 399
Power Cycles: 1,823
Power On Hours: 646
Unsafe Shutdowns: 93
Media and Data Integrity Errors: 0
Error Information Log Entries: 267
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 28 Celsius
Temperature Sensor 2: 29 Celsius
Error Information (NVMe Log 0x01, max 64 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID VS
0 267 0 0x0008 0x4004 - 0 0 -
1 266 0 0x0016 0x4016 0x004 0 1 -
2 265 0 0x0008 0x4004 - 0 0 -
3 264 0 0x0016 0x4016 0x004 0 1 -
4 263 0 0x0008 0x4004 - 0 0 -
5 262 0 0x0008 0x4004 - 0 0 -
6 261 0 0x0008 0x4004 - 0 0 -
7 260 0 0x0026 0x4016 0x004 0 1 -
8 259 0 0x0008 0x4004 - 0 0 -
9 258 0 0x0008 0x4004 - 0 0 -
10 257 0 0x0008 0x4004 - 0 0 -
11 256 0 0x0016 0x4016 0x004 0 1 -
12 255 0 0x0008 0x4004 - 0 0 -
13 254 0 0x0008 0x4004 - 0 0 -
14 253 0 0x0008 0x4004 - 0 0 -
15 252 0 0x0008 0x4004 - 0 0 -
... (48 entries not shown)
I also looked at the smartctl man page, but it wasn't obvious which flag(s) might give more information about sectors.
Update 2 (03/05/19)
Even though I've had several crashes in the last few days, ls -al /var/crash doesn't show any crashes in that time frame:
jessime@jessime-t570:~$ ls -al /var/crash
total 59072
drwxrwsrwt 2 root whoopsie 4096 Mar 5 11:05 .
drwxr-xr-x 15 root root 4096 Jan 31 2018 ..
-rw-r----- 1 jessime whoopsie 37795148 Mar 1 10:39 _usr_bin_gedit.1000.crash
-rw-rw-r-- 1 jessime whoopsie 0 Mar 1 10:39 _usr_bin_gedit.1000.upload
-rw------- 1 whoopsie whoopsie 0 Mar 1 10:40 _usr_bin_gedit.1000.uploaded
-rw-r----- 1 jessime whoopsie 22683033 Feb 27 19:04 _usr_bin_pulseaudio.1000.crash
