Arch Linux

dlaube

Member

Registered: 2017-09-08

Posts: 12

NVMe SSD going down when accessing

Hello Arch Forum,

I have a serious problem when trying to install arch on my new notebook (Acer V5-591G with added Samsung NVMe 960 Evo 256GB). This is my only device right now, so copy paste error messages is pretty tricky to do. Posting this from preinstalled Windows 10.
Symptoms: After booting live cd from usb i see nvme0 in /dev/. dmesg does not report any errors.
Trying to partition the drive with parted -> IO Error on pci bus on the pci bridge -> nvme0 gone -> dmesg shows some error regarding the ssd (enabled 0x0...00 to 0x0...02, removed after failed probe: -19).

I already added pci=nomsi or pci=noaer to boot options (pressing e on grub adding the options). Also tried adding nvme-core.nvme_core.default_ps_max_latency_us=6000 or 0.

The SSD works fine on Windows, so i don't suspect a hardware fault.

Is there anything i can also try?

Greetings
Daniel

ooo

Member

Registered: 2013-04-10

Posts: 1,638

Re: NVMe SSD going down when accessing

I'm quite sure you should be partitioning e.g. the /dev/nvme0n1.
/dev/nvme0 isn't the actual block device.

There might be some other issue but that's something you definitely should try.

Welcome to forums.

dlaube

Member

Registered: 2017-09-08

Posts: 12

Re: NVMe SSD going down when accessing

Hi

no i shouldn't partition nvme0 but thats another story. Here are the things i do to show you whats wrong:
1.  ls /dev/nvme* -> /dev/nvme0 /dev/nvme0n1 /dev/nvme0n1p1 ....
2. mount /dev/nvme0n1 /mnt ->
  blk_update_request: I/O error, dev nvme0n1, sector 488....
  SQUASHFS error: squashfs_read_data failed to read block 0x0
  squashfs: SQUASHFS error: unable to read squashfs_super_block

(basicly any command that tries to read data from nvme ssd shows these symptoms.)
3. ls /dev/nvme* -> no matches found: /dev/nvme*

dmesg output:
nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0xffff
nvme 000:09:00.0: enabling device (000 -> 0002)
nvme nvme0: Removing after probe failure status: -19
nvme0n1: detected capacity change from 25000..... to 0

then comes the error from above with squashfs (seems reasonable because nvme0n1 is gone then)

So its another issue. lspci prints the pci device even after nvme0n1 is not there anymore.

Greetings

ooo

Member

Registered: 2013-04-10

Posts: 1,638

Re: NVMe SSD going down when accessing

Apparently there's an active ubuntu bug with similar issues on Samsung SSD 960 EVO drive.

Also tried adding nvme-core.nvme_core.default_ps_max_latency_us=6000 or 0.

That won't work because of the redundant "nvme-core." at the beginning.

Try:

nvme_core.default_ps_max_latency_us=0

That should prevent ASPT from transitioning to lower power states, and works around the issue according to the bug report above.

2. mount /dev/nvme0n1 /mnt ->
  blk_update_request: I/O error, dev nvme0n1, sector 488....
  SQUASHFS error: squashfs_read_data failed to read block 0x0
  squashfs: SQUASHFS error: unable to read squashfs_super_block

You don't mount /dev/nvme0n*, as it is the device. You mount the partition, e.g. nvme0n1p1.
Just like you don't mount the /dev/sda device, but /dev/sda1 partition.

Also, please use code tags when posting code/logs etc.
https://wiki.archlinux.org/index.php/Co … s_and_code

dlaube

Member

Registered: 2017-09-08

Posts: 12

Re: NVMe SSD going down when accessing

nvme_core.default_ps_max_latency_us=0

works fine but disabling deepest powert saving mode is not optimal for a notebook.

6000 does not work. I might try lower values (i think that this value describes some kind of polling interval, e.g. 0 means don't sleep, 6000 means wake up the controller every 6000ms)
The bug report also suggests a value of 1500, will try that later.

Thanks for your help

ooo

Member

Registered: 2013-04-10

Posts: 1,638

Re: NVMe SSD going down when accessing

nvme_core.default_ps_max_latency_us=0

works fine but disabling deepest powert saving mode is not optimal for a notebook.

Unfortunately that seems to be the only solution, until whatever is causing the issue is fixed. Hoever, I'd imagine the power savings from ASPT would be few decimals of watt at best, so disabling it shouldn't make major difference.

6000 does not work. I might try lower values (i think that this value describes some kind of polling interval, e.g. 0 means don't sleep, 6000 means wake up the controller every 6000ms)

You could easily look up the actual meaning with modinfo, or quick web search. It's even explained in arch wiki NVMe page. It's not good to make assumptions of what some variable means.