Samsung M2 NVME enters read only on linux every day, not on Windows

Question

I have a Razer Blade Stealth 2016. The first Ubuntu I installed was Ubuntu 17.04, which gave e this error after 2 weeks of usage. After that, I installed 16.04 and used it for months without any problems, until it produced the same error today. I think it has to do with the ubuntu updates, because I did one recently and one today, just before this problem. Could be a coincidence though.

(I even did some stress tests, by downloading 100s of gb of data lots of times, and having my disk almost full, and I got none of these errors while in 16.04 without updates)

After I run fsck manually, it solves the problem but it happens again after some time.

UPDATE:

It happened again (with the 17.10.1 fresh install with no updates that I was using since the day I started this post. I noticed the problem because I tried to save one of my VMs into disk and it said that my disk was read only. Then I ran:

lz@lz:/var/log$ touch something
touch: cannot touch 'something': Read-only file system


lz@lz:/var/log$ cat syslog
Jan 29 01:07:39 lz kernel: [62984.375393] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0


lz@lz:/var/log$ dmesg
[62984.375393] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.377374] Aborting journal on device nvme0n1p2-8.
[62984.379343] EXT4-fs (nvme0n1p2): Remounting filesystem read-only
[62984.379516] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.381486] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.383484] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.385469] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.387278] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.389262] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.391252] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.393341] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[63285.618078] audit: type=1400 audit(1517195560.393:63): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=22495 comm="cupsd" capability=12  capname="net_admin"

I then rebooted and did fsck /dev/nvm.... It asked me about lots of inodes, I did 'yes' to all, and at a moment it stopped.

https://imgur.com/a/cfbPD (this photo shows the entire output, but not much visible) https://imgur.com/a/VFoPB (this one is better but it cuts a bit of the output)

Here's a video of the entire process: https://photos.app.goo.gl/8ZHF3Un1BOsRwjaz1

I'm going to apply the microcode patch as the answer below suggest, but I don't think it has to do with the problem, as this is happening months before meltdown and spectre. And I had never even installed a microcode update.

I still think it has to do with the problem I described on my post. Can somebody give me details about if it was fixed, in which kernels it is fixed? What should I do?

Anyways, I just applied the suggested correction of adding

nvme_core.default_ps_max_latency_us=5500

to the boot parameters. Going to see how the syste behaves with it.

UPDATE: every time I install a new system, it behaves well until I decide to use the software updater! Then it enters in read-only mode :(

I tried with nvme_core.default_ps_max_latency_us=250 and it didn't work

UPDATE: everything seems to work FINE when I install windows. Even the benchmark tests says everything is ok

UPDATE (03/10/2019)

I still have this problem. It happens once a day, but happens a lot when there' s heavy ssd usage.

I tried with a brand new Samsung 960 EVO 2156gb SSD and the problem persists, so it' s not related to the SSD itself. However I made the mistake of buying one of the same brand and related model. I did not test non samsung SSDs.

Both SSDs run perfect on Windows. I even did LOTS of benchmark tests which stressed them a lot. No problems.

I tried ubuntu 16, 18, 19, Debian 10, Linux Mint. All give the same problem. Can somebody help me find the source of the problem? I spent a LOT on this computer and don' t have money to buy a new one.

My grub file now:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

Answer 1

Intel Microcode 2018-01-08 breaks some systems

When the world famous Meltdown and Spectre security holes were announced in the beginning of 2018 vendors rushed in with fixes. According to Ubuntu Intel asked them to downgrade to older microcode when then the January 8, 2018 Microcode Update broke some systems.

---

List your current Microcode version

To find your current Microcode version use:

$ apt list --installed | grep intel-microcode

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

intel-microcode/now 3.20170707.1~ubuntu16.04.0 amd64 [installed,upgradable to: 3.20180108.0+really20170707ubuntu16.04.1]

In my case the Intel Microcode update for 2018-01-08 is not being used and the original version from 2017-07-07 is being used. When patches for Meltdown were announced bugs started appearing on regular updates on 2018-01-04. Since then I declined all automatic updates in favour of manually installing new mainline kernels instead. That is why I have the older original microcode.

---

Downgrade Microcode for Ubuntu 14.04, 16.04 and 17.10

If you are running 2018-01-08 Intel Microcode you MUST upgrade it to the version released on 2018-01-22.

The problem can be corrected by updating your system to the following package version:

Ubuntu 17.10:

• intel-microcode 3.20180108.0+really20170707ubuntu17.10.1

Ubuntu 16.04 LTS:

• intel-microcode 3.20180108.0+really20170707ubuntu16.04.1

Ubuntu 14.04 LTS:

• intel-microcode 3.20180108.0+really20170707ubuntu14.04.1

To update your system, please follow these instructions: https://wiki.ubuntu.com/Security/Upgrades.

After a standard system update you need to reboot your computer to make all the necessary changes.

Repeat the steps in previous section to check your Intel Microcode version

Install Microcode from Terminal

To install Microcode from Terminal without going through Ubuntu GUI Settings panels use:

sudo apt update
sudo apt install intel-microcode