NVME I/O issues on IdeaPad 5 15ARE05 Ryzen 7 4700U: Slow writing speed and freeze

I have recently acquired a Ryzen 4700U laptop of the type Ideapad 5 from lenovo. It has the codename 15ARE05.

I have replaced the 512 GB NVME drive with a 1TB Kingston A2000 drive. I am experiencing a number of problems:

  • My system may freeze on intensive disk writes, like compiling stuff from AUR. When this happens I can still interact with the laptop as long as the process does not use the disk. Al actions that require disk io will freeze. I can only recover by hard shutdown (pressing power for 5 secs)
  • When using gnome-disk-utility 3.38.0, I can not access the smart status of the drive, nor can I alter any additional settings like write cache. They are greyed out.
  • When using gnome-disk-utility 3.38.0, I perform a benchmark of the disk. There I see that the readspeed is as expected around 2000 MB/s. Writespeed however is below 400 MB/s whereas it should also be around 2000 MB/s.
  • I also still have windows installed on the disk, (just in case) And in windows I can access smart info just fine + Writespeed is indeed around 2000MB/s.

Is it a known fact that the disk IO chip on this system is not yet fully supported by the kernel 5.9.3 ?
Could there be an incompatibility with the kingston drive in linux?

I have not witnessed the problem with the included 512 GB NVME disk, but I have not ruled it out either as I used it only for a very limited time.

Could anyone with similar hardware perform a test whether they face similar issues?

The freezing is obviously the most serious issue. I can not reproduce logs, because they are not written.

Thank you!

Why are you cross-posting this on Arch BBS?

This issue needs much more info… Memory, build directory size etc.

This is normal…

Unfortunately Disk Uility can only measure data on one PCI lane. NVME drives use multiple PCI lanes, 4 I believe, to increase data throughput. So 4 x 400MB/s sounds correct. A simple way to test is to move a large file, say 10GB or 20 GB and calculate the time it takes. My system did the same thing and the copy test verified that the nvme drive was actually working properly.

16 GB of RAM
Build directory size depends on program, but it happened with different compiles and tends to happen after a while, not straight away, thus with the somewhat larger compiles. It does not happen always. I could at some point compile a program after restarting my system with a different kernel. With that kernel however it has also failed on other instances.

Are you sure? On my desktop system with an NVME drive it comes up with expected values, of over 2000 MB/s. Also there I can access smart status and activate write caching. If this is really the case should it not also be the case for measured read speeds? They are as expected however. I am expecting more like 5x 400MB/s as it is on windows and my desktop system

My apologies, I just tested it on my system with version 3.38.0 and it does now show the correct speeds. An update in the last 9 months must have added nvme support.

The 512 drive performed in the 2000MB range?

I cant confirm. It is not easy to swap drives in this laptop, so I am hesitant to do that for this purpose

Before doing that, try running the speed test from a live ISO…

I don’t suppose you used it long enough to test if the same issue occurred with it?

No unfortunately not. Meanwhile I have found mention of an issue in the ARCH bug system concerning my kingston drive and related to powermanagement. Ik will keep an eye on that.

Blockquote Before doing that, try running the speed test from a live ISO…

Have done that from manjaro and ubuntu live CD. Both the same performance profile.

was mixed up and ended up in arch via the AUR page of a pacgage I tried to install. But I did have an arch install on this system for testing and it exhibits the same problem. I have to redo that install after file corruption

Which is?

The package i do not recall exactly, I believe it was flightgear… But that is not so relevant, because it has happened with a number of different longer compiles from Aur.

At this moment I am runnig the kernel with nvme_core.default_ps_max_latency_us=4000 and I have yet to see any freezes since. It seems to be related to the specific SSD I have. Of all options this one seems to have an issue with linux. That does not expain the slow write speeds however…