What does it mean that disabling the NVMe devices's write cache
often but apparently not always helps? It it just reducing the
chance of the problem occurring or accidentally working around it?
For consumer NAND device you basically can't disable the volatile
write cache. If you do disable it, that just means it gets flushed
after every write, meaning you have to write the entire NAND
(super)block for every write, causing a huge slowdown (and a lot of
media wear). This will change timings a lot obviously. If it
doesn't change the timing the driver just fakes it, which reputable
vendors shouldn't be doing, but I would not be entirely surprised
about for noname devices.
--- Comment #49 from Bruno Gravato ---
* Not totally sure, but it seems most or everyone affected is
using a Ryzen 8000 CPU -- and now one user showed up that mentioned
a DeskMini x600 with a Ryzen 7000 CPU is not affected (see ticket
for details). But that might be due to other aspects. A former
colleague of mine who can reproduce the problem will later test if
a different CPU line really is making a difference.
One other different aspect for that user besides the 7000 series CPU
is that he's using a wifi card as well (that sits in a M.2 wifi slot
just below the main M.2 disk slot), so I wonder if that may play a
role? I think most of us have no wifi card installed. I think I have
a M.2 wifi card on my former NUC, I'll see if it's compatible with
the deskmini and try it out.
The other reason could be some disk models aren't affected... I think
Stefan reported no issues on a Firecuda 520.
--- Comment #51 from Ralph Gerstman --- > A missing network might prevent the failure during install - at leastI had to disable it in BIOS. Just not connecting it has no effect
in Ubuntu> 22.10 - but can happen anyway. Enabling network seems to
raise the chance.