Система видит NVMe SSD, но не может работать с ним. Проблема при установке Fedora.

На этой материнке этот nvme работает с другой операционной системой?

Точно «error -25»?

Да, собственно, на этом NVMe сейчас Windows (в её установщике он отображается сразу и с ним можно работать, так что я смогу всё стереть, если понадобится). Да, отображается error -25. В lspci диск тоже есть в виде контроллера.

Ну, попробовать другой дистрибутив, с другой версией ядра.

Так, у меня получается, что -25 это ENOTTY, он же Inappropriate ioctl for device, и от nvme он может были или при ошибке при NVME_IOCTL_SUBSYS_RESET. Как будто какой-то софт, а не ядро, просит reset NVME устройства и облом. Но мне это не понятно, зачем reset при установке, наверное я что-то не то увидел в исходниках...

Без костылей не обойтись.

Очевидно, проблема в драйвере.

У меня что-то похожее было на ноуте. Когда грузился в live образ Arch Linux, то, во-первых, была большая задержка (ну минуты 3 наверное) при загрузке ОС, а во-вторых, один из двух Nvme накопителей в системе не определялся нормально.

Было это как-то связано с дискретной графикой Nvidia, потому что при переключении на встроенную графику AMD в BIOS/UEFI ноутбука Nvme стал определяться нормально и задержка при загрузке пропала. Причем если систему все же установить и установить проприетарный драйвер Nvidia, то проблема исчезает, то есть это как-то было связано с отсутствием проприетарного драйвера Nvidia на live образе.

Не знаю поможет эта информация как-то или нет, но тоже связана с Nvme, поэтому решил поделиться.

secure boot отключен?

Да, никакого secure boot

Блин, да, есть дискретная графика, но у меня десктоп без встройки

Вот что помогло мне (искал в Гугле, в том числе через их ИИ поиск):

1. В Grub нажимаем латинскую e, чтобы войти в edit-режим редактирования
2. В редакторе переходим на строку, в которой есть quiet
3. После quiet дописываем: splash nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pci=noaer pci=nomsi nvme_noacpi=1 nvme_core.quirks=0x<vendorID>:0x<deviceID>:0x40. Вместо <vendorID> и <deviceID> надо подставлять значения для своего диска, у меня это было 1e4b и 1202 соответственно (дешманский NVMe контроллер MAXIO MAP1202)

Лично у меня после этого система загрузилась и распознала диск, дальше всё, что касается NVMe диска, работало так, как и должно было работать из коробки.

Тоже была большая задержка, после прописывания параметров в Grub для загрузки ядра задержка пропала. Дискретная графика тоже Nvidia. После установки проприетарного драйвера, система перестала грузится (и при загрузке последнего меню в Grub, которое rescue, просто тёмный экран с курсором, которым можно двигать). Ставил отсюда: rpmfusion.org. Не знаю, может, я неправильно их поставил…

Пожалуйста, пометь тему, как решённую.

Отметил, спасибо за напоминание. Может, какой-нибудь такой же бедолага, как я, у которого ничего не работает, найдёт…

Также в этой строке должно быть linux

0x40 — это же NVME_QUIRK_QDEPTH_ONE?

И вобще непонятно, как эта магия работает:

nvme_core.quirks

Смотрю https://docs.kernel.org/admin-guide/kernel-parameters.html , там usbcore.quirks= есть, usb-storage.quirks= есть, а nvme_core.quirks= нету.

Если смотреть source/drivers/nvme/host/core.c, то там через module_param() определены всякие nvme_core.default_ps_max_latency_us и пр., но quirks нет.

В некоторых дистрибутивах нужно нажимать TAB для ввода параметров ядра

Есть вот такое. Ну, я не зря подписывал, что использовал гугловский ИИ-поиск =D

nvme.quirks=    [NVME] A list of quirk entries to augment the built-in
                        nvme quirk list. List entries are separated by a
                        '-' character.
                        Each entry has the form VendorID:ProductID:quirk_names.
                        The IDs are 4-digits hex numbers and quirk_names is a
                        list of quirk names separated by commas. A quirk name
                        can be prefixed by '^', meaning that the specified
                        quirk must be disabled.

                        Example:
                        nvme.quirks=7710:2267:bogus_nid,^identify_cns-9900:7711:broken_msi

Ну, во-первых, этот nvme.quirks, если не путаю, появился с ядром 7.0. В момент написания моего поста он может быть в каких-то патчах, но не в документации https://docs.kernel.org/admin-guide/kernel-parameters.html.

А, во-вторых, nvme.quirks != nvme_core.quirks, в ядре нет ИИ, чтобы распознать, неправильное написание. Да и с nvme_noacpi аналогично, там точка должна стоять. Либо у вас какое-то патченное ядро было, либо хвост вашего рецепта не имеет смысла, и работало что-то из начала. Так мне особо без разницы, просто не нравится тиражирование по форумам длинных непонятных рецептов. Потом надо будет что-то быстро починить и сиди, разбирайся, какие параметры бесполезные, а какие лишние и при этом конфликтуют с уже имеющимися...

Да, я уже понял, что часть команд липовая, хватило pci=nomsi. Работает и ладно, я в первую очередь просто решение искал, чтобы попробовать систему. Пока до сих пор сижу на Линуксе, пишу только уже с другого дистрибутива.

Правда пишут, что может быть негативное влияние от pci=nomsi, но я пока не заметил, но периодически возвращаюсь к вопросу, чтобы разобраться, как оставить msi, и при этом чтобы этот несчастный NVMe SSD работал, на другом диске (от ADATA, а не SiliconPower) с другим контроллером на той же системе - ноль проблем

Как я понимаю, негативное влияние от nomsi — снижение производительности. Если не лень, можете позапускать тесты fio на ADATA с nomsi и без.

Так, везде написано, что MSI для одного устройства, а не для всех, должен отключать драйвер. Какой-либо опции, отключающей MSI для произвольного устройства нет, только если в драйвере реализовали. Просмотрел под диагонали драйвер nvme, вроде, там нет такой опции, чтобы MSI/MSIX отключить и нет QUIRK'а делающего это. Где-то пишут, что вместо nomsi можно попробовать ″nvme.poll_queues=4″.

Непонятно куда копать и чего ждать. Если это конфликт дискретной nvidia и этого конткретного MAXIO, то, скорее всего, его в новых версиях ядра и не поправят, так как не заметят. Можно начать писать баг-репорты, но там могут попросить поставить последнюю версию ядра, наложить патчи, пересобрать ядро...

Ядро 7.0.2. Свежее, но точно не максимально возможное и не релиз-кандидат. Попробую nvme.poll_queues=4 как-нибудь. Ещё я не упомянул, что железо тут довольно древнее (LGA1156, i7 870), если знакомы с установкой NVMe на legacy-системы, то OpROM injection должно быть тоже знакомо. С Windows 10 проблем на этой же машине вообще нет, поэтому я отмёл этот вариант…

OpROM injection

Лучше опишите подробнее. А то одини BIOS модят (и перешивают флешку на материнке), другие что-то USB-флешку складывают... Ну и на древности могут быть проблеммы с MSIX, может Win10 не пытавется MSI-X на nvme включить, только MSI, но это так, пальцем в небо. Вот, то что у вас такая древность, ещё понижает шансы, что кто-нибудь что-то в ядре поправит в нужную сторону.

Ну, и новое не всегда лучше, может имеет смысл посмотреть старые ядра, начиная с 3.10-3.15, откуда-нибудь типа такого https://pingvinus.ru/distributions/releases выбирать дистр (установщик дистра) исключительно на попробовать как там это NVME себя покажет. Можно, конечно, самому собирать старые ядра, но, ИМХО, готовый дистр взять проще.

OpROM - модуль для legacy BIOS, запускается при POST, грузит код с MBR, передавая управление загрузчику.

Специально докинул OpROM для ADATA (точно такой же, как для SiliconPower, но с другими PCIvendorID / PCIdeviceID) и загрузился в LiveCD со стоковыми параметрами ядра, чтобы поставить их в более менее равные условия, когда в BIOS есть OpROM для обоих дисков.

И нет, всё так же. Думаю всё же дело в самом контроллере MAP1202. В файловом менеджере и установщике по прежнему видно только один диск (ADATA). Попробовал физически поменять их местами, свапнув на слотах 0000:02:00.0 <−> 0000:0a:00.0, чтобы исключить влияние топологии старой материнской платы, но LiveCD перестала грузится, при этом уведомляя о проблеме с SiliconPower на 0000:02:00.0. Если убрать pci=nomsi, то система отказывается работать с ним, при этом такое было и когда в системе он был один единственный. Замена на pci=noacpi не даёт никакого эффекта. И вот непонятно, почему один не работает с MSI, а второму работается нормально…

[liveuser@CachyOS ~]$ sudo dmesg | grep nvme

[    0.000000] Command line: BOOT_IMAGE=/arch/boot/x86_64/vmlinuz-linux-cachyos-lts archisobasedir=arch archisosearchuuid=2026-03-08-13-36-02-00 cow_spacesize=10G copytoram=auto module_blacklist=pcspkr i915.modeset=1 amdgpu.modeset=1 nvme_load=yes initrd=/arch/boot/x86_64/initramfs-linux-cachyos-lts.img
[    0.047139] Kernel command line: BOOT_IMAGE=/arch/boot/x86_64/vmlinuz-linux-cachyos-lts archisobasedir=arch archisosearchuuid=2026-03-08-13-36-02-00 cow_spacesize=10G copytoram=auto module_blacklist=pcspkr i915.modeset=1 amdgpu.modeset=1 nvme_load=yes initrd=/arch/boot/x86_64/initramfs-linux-cachyos-lts.img
[    0.047295] Unknown kernel command line parameters "archisobasedir=arch archisosearchuuid=2026-03-08-13-36-02-00 cow_spacesize=10G copytoram=auto nvme_load=yes", will be passed to user space.
[    2.766565]     nvme_load=yes
[    4.674266] nvme nvme0: pci function 0000:02:00.0
[    4.674269] nvme nvme1: pci function 0000:0a:00.0
[    4.794371] nvme nvme0: allocated 64 MiB host memory buffer (16 segments).
[    4.816199] nvme nvme0: 8/0/0 default/read/poll queues
[    4.825290]  nvme0n1: p1 p2 p3
[  132.676094] nvme nvme1: Device not ready; aborting reset, CSTS=0x1
[  134.849659] nvme 0000:0a:00.0: timed out waiting for pending transaction; performing function level reset anyway
[  141.274741] nvme 0000:0a:00.0: not ready 1023ms after FLR; waiting
[  142.619522] nvme 0000:0a:00.0: not ready 2047ms after FLR; waiting
[  145.010246] nvme 0000:0a:00.0: not ready 4095ms after FLR; waiting
[  149.941109] nvme 0000:0a:00.0: not ready 8191ms after FLR; waiting
[  158.757750] nvme 0000:0a:00.0: not ready 16383ms after FLR; waiting
[  175.641398] nvme 0000:0a:00.0: not ready 32767ms after FLR; waiting
[  210.456327] nvme 0000:0a:00.0: not ready 65535ms after FLR; giving up
[  213.146058] nvme 0000:0a:00.0: probe with driver nvme failed with error -25
[  371.294676] nvme nvme0: using unchecked data buffer
[  371.356001] block nvme0n1: No UUID available providing old NGUID
[  393.438342] BTRFS: device fsid e9785c64-c2a8-4d8b-9cb2-a25436aa7a97 devid 1 transid 812 /dev/nvme0n1p3 (259:3) scanned by pool-1 (2614)
[  393.438954] BTRFS info (device nvme0n1p3): first mount of filesystem e9785c64-c2a8-4d8b-9cb2-a25436aa7a97
[  393.438966] BTRFS info (device nvme0n1p3): using crc32c (crc32c-lib) checksum algorithm
[  393.443862] BTRFS info (device nvme0n1p3): enabling ssd optimizations
[  393.443866] BTRFS info (device nvme0n1p3): turning on async discard
[  393.443867] BTRFS info (device nvme0n1p3): enabling free space tree

~> sudo lspci -vnn -s 0a:00.00
0a:00.0 Non-Volatile memory controller [0108]: ADATA Technology Co., Ltd. XPG GAMMIXS1 1L, XPG GAMMIX S5, LEGEND 710 / 740, SWORDFISH NVMe SSD (DRAM-less) [1cc1:5766] (rev 01) (prog-if 02 [NVM Express])
        Subsystem: ADATA Technology Co., Ltd. XPG GAMMIXS1 1L, XPG GAMMIX S5, LEGEND 710 / 740, SWORDFISH NVMe SSD (DRAM-less) [1cc1:5766]
        Flags: bus master, fast devsel, latency 0, IRQ 19
        Memory at f7ffc000 (64-bit, non-prefetchable) [size=16K]
        Memory at f7ffa000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
        Capabilities: [70] Express Endpoint, IntMsgNum 0
        Capabilities: [b0] MSI-X: Enable- Count=9 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [148] Device Serial Number 00-00-00-01-00-4c-e0-00
        Capabilities: [158] Secondary PCI Express
        Capabilities: [178] Latency Tolerance Reporting
        Capabilities: [180] L1 PM Substates
        Capabilities: [190] Vendor Specific Information: ID=0001 Rev=1 Len=038 <?>
        Kernel driver in use: nvme
        Kernel modules: nvme

~> sudo lspci -vnn -s 02:00.00
02:00.0 Non-Volatile memory controller [0108]: MAXIO Technology (Hangzhou) Ltd. NVMe SSD Controller MAP1202 (DRAM-less) [1e4b:1202] (rev 01) (prog-if 02 [NVM Express])
        Subsystem: MAXIO Technology (Hangzhou) Ltd. NVMe SSD Controller MAP1202 (DRAM-less) [1e4b:1202]
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at f7bfc000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
        Capabilities: [70] Express Endpoint, IntMsgNum 31
        Capabilities: [b0] MSI-X: Enable- Count=9 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [148] Device Serial Number 00-00-00-00-00-00-00-00
        Capabilities: [158] Alternative Routing-ID Interpretation (ARI)
        Capabilities: [168] Secondary PCI Express
        Capabilities: [1d4] Latency Tolerance Reporting
        Capabilities: [1dc] L1 PM Substates
        Capabilities: [1ec] Vendor Specific Information: ID=0002 Rev=4 Len=100 <?>
        Capabilities: [2ec] Vendor Specific Information: ID=0001 Rev=1 Len=038 <?>
        Kernel driver in use: nvme
        Kernel modules: nvme

Специально докинул OpROM для ADATA

Ну, тогда вобще без OpROM попробуйте. Загрузки с NVME накопителя не будет, но ядро (Линукс) грузить с флешки/SATA, то он NVMe должен увидеть и работать с ним. Тогда будет понятнее, как-то связана проблема с OpROM или нет.

Получилось отключить MSI/MSI-X на проблемном контроллере, добавив вот это в udev и mkinitcpio, тут надо править адрес устройства 0000:0a:00.0 под конкретный случай:

~> sudo cat /etc/udev/rules.d/99-nvme-msix-disable.rules
ACTION=="add", SUBSYSTEM=="pci", KERNELS=="0000:0a:00.0", ATTR{msi_bus}="0"

И надо добавить в секцию FILES в файле /etc/mkinitcpio.conf (тут у меня первым идёт другой файлик для монитора, к этой теме он отношения не имеет):

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=(/lib/firmware/edid/custom.bin /etc/udev/rules.d/99-nvme-msix-disable.rules)

В итоге GPU и ADATA работают с MSI/MSI-X, а MAP1202 работает через легаси-прерывания:

~> sudo lspci -vv -s 01:00.0 | grep -E "Capabilities:|MSI"
	Interrupts: pin B disabled, MSI(X) routed to IRQ 46
	Capabilities: [60] Power Management version 3
	Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [78] Express (v2) Legacy Endpoint, IntMsgNum 0
	Capabilities: [100 v1] Virtual Channel
	Capabilities: [258 v1] L1 PM Substates
	Capabilities: [128 v1] Power Budgeting <?>
	Capabilities: [420 v2] Advanced Error Reporting
	Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
	Capabilities: [900 v1] Null
	Capabilities: [bb0 v1] Physical Resizable BAR
~> sudo lspci -vv -s 02:00.0 | grep -E "Capabilities:|MSI"
	Interrupts: pin B disabled, MSI(X) routed to IRQ 45, 47-54
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
	Capabilities: [70] Express (v2) Endpoint, IntMsgNum 0
	Capabilities: [b0] MSI-X: Enable+ Count=9 Masked-
	Capabilities: [100 v2] Advanced Error Reporting
	Capabilities: [148 v1] Device Serial Number 00-00-00-01-00-4c-e0-00
	Capabilities: [158 v1] Secondary PCI Express
	Capabilities: [178 v1] Latency Tolerance Reporting
	Capabilities: [180 v1] L1 PM Substates
	Capabilities: [190 v1] Vendor Specific Information: ID=0001 Rev=1 Len=038 <?>
~> sudo lspci -vv -s 0a:00.0 | grep -E "Capabilities:|MSI"
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
	Capabilities: [70] Express (v2) Endpoint, IntMsgNum 31
	Capabilities: [b0] MSI-X: Enable- Count=9 Masked-
	Capabilities: [100 v2] Advanced Error Reporting
	Capabilities: [148 v1] Device Serial Number 00-00-00-00-00-00-00-00
	Capabilities: [158 v1] Alternative Routing-ID Interpretation (ARI)
	Capabilities: [168 v1] Secondary PCI Express
	Capabilities: [1d4 v1] Latency Tolerance Reporting
	Capabilities: [1dc v1] L1 PM Substates
	Capabilities: [1ec v1] Vendor Specific Information: ID=0002 Rev=4 Len=100 <?>
	Capabilities: [2ec v1] Vendor Specific Information: ID=0001 Rev=1 Len=038 <?>

Ну и /proc/cmdline без всякого лишнего.

В тесте KDiskMark подросло RND4K (Q32T1, Q1T1) для ADATA до (521 MB/s, 50 MB/s). Потестил ещё другой ПК на AM5 с другим NVMe от ADATA под Виндой 10 - (860 MB/s, 68 MB/s), но там Винда работает через SCSI-трансляцию (и это не лечится без перехода на Windows 11 с фиксом или на Linux, эти приросты есть в интернете, был даже небольшой шум по этому поводу) - ну пусть это будет фора. Тесты SEQ где-то 1600 MB/s и 3000-3500 MB/s, но они мне не интересны. Шины PCIe 2.0 x4 и PCIe 3.0 x4 соответственно.

Проверял портативную Windows на этом же ПК под LGA1156, а также другие компьютеры с другими дисками с этим же контроллером MAP1202 и установленными Windows - во всех случаях IRQ отрицательные, то есть MSI/MSI-X работают.

Значит, даже этот диск может работать с MSI/MSI-X даже на этой плате - Windows 11 Heren’s PE под этой платой это делает, Windows 10 на других ПК с этим контроллером тоже, а Линукс почему-то пока что нет…

Вообще довольно странная ситуация сложилась: Винда 10 из коробки могёт в MSI/MSI-X для этих дисков, НО там из коробки трансляция NVMe−>SCSI, которая реально режет скорость. Это убрали только в серверных редакциях Windows 11 в конце прошлого года, добавив нативный NVMe драйвер, но включать его надо через костыли и реестр для домашних редакций, и тогда будет и нативная скорость, и поддержка MSI/MSI-X. Но… Windows 11, бррр.

Линукс чисто в теории должен обеспечить всё сразу и из коробки, и он это делает, если использовать любой другой нормальный контроллер, а не MAP1202, который почему-то не хочет работать с MSI-X под Линукс…

ATTR{msi_bus}=«0»

Это вот уже интерестно, постараюсь запомнить.

а не MAP1202, который почему-то не хочет работать с MSI-X под Линукс

Точно не помню, но, вроде, у меня был NVMe на MAP1202 и работал нормально, и в интернете тоже не особо гуглится про несовместимость Линукс и MAP1202. Возможно, у вас какая-то другая ревизия MAP1202 или какая-то кривоватая прошивка в самом SSD, чем у большинства владельцев MAP1202. Под Линуксом не редкость, что одна версия/ревизия железяки работает нормально, а другая нет. И пока владелец такой вот железяки не упрётся и не напишет патч, всё так и останется :(

А виндовый драйвер мог писать производитель MAP1202 и он знает лучше поведение своего контроллера и его ревизий. Но это не точно :)

На другом ПК с этим же контроллером той же 01-ой ревизии на SSD другого вендора (Patrior вместо SiliconPower, хотя сомневаюсь, что это на что-то влияет) под Windows 10 отрицательные IRQ, то есть MSI/MSI-X работает

Под Линуксом не редкость, что одна версия/ревизия железяки работает нормально, а другая нет. И пока владелец такой вот железяки не упрётся и не напишет патч, всё так и останется :(

Печально…

одна версия/ревизия железяки

Что забавно у меня есть другой точно такой же NVMe SSD от того же самого SiliconPower в очередном другом компьютере (можно сказать, что они «из одного помёта», так как покупались буквально в одной корзине, в одном магазине и в один момент) - ревизия обозначена та же самая 01-ая, а контроллер вообще другой и имеет другие VendorID/DeviceID… У них ничего общего вообще нет, кроме брендинга и номера ревизии, а также (маловероятно) чипов памяти. Ну, впрочем, это разнообразие компонентов ожидаемо для дешевых SSD, но, блин, хоть бы ревизию поменяли бы, она же, вроде, должна быть аппаратным идентификатором начинки, как мне казалось, иначе какой смысл в ней

М-да…

{ PCI_DEVICE(0x1e4B, 0x1202),   /* MAXIO MAP1202 */
		.driver_data = NVME_QUIRK_BOGUS_NID, },

        /*
	 * Reports garbage in the namespace identifiers (eui64, nguid, uuid).
	 */
	NVME_QUIRK_BOGUS_NID			= (1 << 18),

Дак там много таких в linux/drivers/nvme/host/pci.c.

Reports garbage in the namespace identifiers

NVMe namespaces — это же фишка серверных накопителей, на бытовых разрабы отдыхают и не особо заботятся, чтобы накопитель корректно показывал что он поддерживает единственный namespace. Плюс, подобные (некритичные для производительности) квирки легко назначают не глядя. Допустим, если какая-то единственная модель накопителя на этом контроллере так себя вела, то просто всем по pci id, не интерестно разбираться что на других ревизиях/прошивках.

Понял. Изменить ответ не могу, тут сброшу:

Можно по айдишникам диска, без явного указания шины и слота:

ACTION=="add", SUBSYSTEM=="pci", ATTRS{vendor}=="0x1e4b", ATTRS{device}=="0x1202", ATTR{msi_bus}="0"