novicheck, на данный момент идея только одна - пробовать манипулировать параметрами модулей ядра nvme_core и/или nvme при загрузке. Возможно, выставив некое значение для одного из них диск мы-таки сможем увидеть. Нагуглил так сказать спецификацию Вашего диска.
Модель (по данным BIOS): WDC PC SN520 SDAPMUW-128G-1001. На
сайте производителя выложен
pdf с, так сказать, спецификацией. Там же есть раздел техподдержки. Написал им на электронную почту на ломаном английском (другим не обладаю, увы), описал проблему. Спросил про параметры ядра, дал ссылку на данный топик. Может, чего путнего посоветуют. Проблема явным образом кроется только в диске. Ни материнка, ни что-либо еще здесь ни при чем, как мне кажется.
Параметры ядра согласно выводам modinfo для данных модулей:
modinfo nvme
...
depends: nvme-core
...
parm: use_threaded_interrupts:int
parm: use_cmb_sqes:use controller's memory buffer for I/O SQes (bool)
parm: max_host_mem_size_mb:Maximum Host Memory Buffer (HMB) size per controller (in MiB) (uint)
parm: sgl_threshold:Use SGLs when average request segment size is larger or equal to this size. Use 0 to disable SGLs. (uint)
parm: io_queue_depth:set io queue depth, should >= 2
parm: write_queues:Number of queues to use for writes. If not set, reads and writes will share a queue set. (int)
parm: poll_queues:Number of queues to use for polled IO. (int)
###################
modinfo nvme_core
...
parm: multipath:turn on native support for multiple controllers per subsystem (bool)
parm: admin_timeout:timeout in seconds for admin commands (uint)
parm: io_timeout:timeout in seconds for I/O (uint)
parm: shutdown_timeout:timeout in seconds for controller shutdown (byte)
parm: max_retries:max number of retries a command may have (byte)
parm: default_ps_max_latency_us:max power saving latency for new devices; use PM QOS to change per device (ulong)
parm: force_apst:allow APST for newly enumerated devices even if quirked off (bool)
parm: streams:turn on support for Streams write directives (bool)
Первый - исходя из вывода dmesg (тот самый, который отваливается, судя по логу). Второй указан в зависимостях первого. Влияют, ИМХО либо первый, либо второй, либо оба сразу. Некая несовместимость присутствует данных модулей ядра с данною железкой.
Наверное имеет смысл начать с параметра default_ps_max_latency_us модуля nvme_core. Вроде как при загрузке с таким параметром ядра:
nvme_core.default_ps_max_latency_us=0не должно быть задействовано энергосбережение (если я правильно трактую max power saving latency) для диска, таким образом он не будет отключен по ошибке, что, весьма возможно, в нашем случае и происходит. Вместе с тем, можно попробовать иные значения данного параметра, например вместо 0 записать ему 1000, либо 2000, либо 5000.
Кроме того, можно попробовать поманипулировать теми параметрами, которые имеют тип bool (там как бы вариантов меньше - либо 0 либо 1):
nvme_core.multipath=1 nvme_core.multipath=0
nvme_core.force_apst=1 nvme_core.force_apst=0
nvme_core.streams=1 nvme_core.streams=0
nvme.use_cmb_sqes=1 nvme.use_cmb_sqes=0Тест в любом случае один: выбираем параметр, который понравился, прописываем его в grub2 при загрузке, грузимся с ним в режиме LiveUSB (Try Ubuntu without install/Попробовать Ubuntu без установки), и смотрим в выводе dmesg - изменились ли или пропали ли вовсе ошибки, ну и в выводе хоть того же lsblk - стал ли доступен диск. Я бы попробовал позагружаться с предлагаемыми параметрами. Тратить на это время или нет - решать конечно же Вам. Но иного мне пока в голову не лезет. Может, у кого есть иные идеи, поинтереснее.