(Решено) Исчезновение PCI-устройств после восстановления из сна

knopki	# 7 лет, 7 месяцев назад (отредактировано 7 лет, 2 месяца назад)
Темы: 1 Сообщения: 4 Участник с: 31 августа 2016	Здравствуй, дорогое сообщество! Новоприбывший арчевод здесь, просит помощи. Мой сетап Alienware 15 R2 с последним BIOS (1.3.6), Skylake i7-6700HQ и Samsung 950 Pro NVMe (вот это важно). 00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 07) 00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 07) 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06) 00:04.0 Signal processing controller: Intel Corporation Skylake Processor Thermal Subsystem (rev 07) 00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31) 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal subsystem (rev 31) 00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1 (rev 31) 00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA Controller [AHCI mode] (rev 31) 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #1 (rev f1) 00:1c.4 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #5 (rev f1) 00:1c.5 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #6 (rev f1) 00:1c.6 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #7 (rev f1) 00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9 (rev f1) 00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31) 00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31) 00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31) 00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31) 01:00.0 3D controller: NVIDIA Corporation GM204M [GeForce GTX 970M] (rev ff) 3b:00.0 Ethernet controller: Qualcomm Atheros Killer E2400 Gigabit Ethernet Controller (rev 10) 3c:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) 3d:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01) 3e:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller (rev 01) nvme0 - ssd sda - hdd /boot on nvme0n1p1 swap on lvm on luks on nvme0n1p3 /root and /boot btrfs subvolumes on lvm on luks on nvme0n1p3 /home btrfs subvolume on lvm on luks on bcache (sda6 + nvme0n1p4) Звучит переусложненно, но на самом деле всё просто. Важно тут то, что корневая система на lvm в шифрованном luks на ssd. Промежуточные слои можно опустить, проблема с нижним. NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 ├─sda2 vfat ESP 39B4-82EE ├─sda3 ntfs OS EE106F0129C7BF33 ├─sda4 ntfs WINRETOOLS CA21D5BD3C4F0B5D ├─sda5 ntfs Image E2C9C8F05DC95E5F └─sda6 bcache 17540d53-7b5f-4998-bff7-b4b09f8c7f13 └─bcache0 crypto_LUKS ead98797-7022-4160-829f-8380d5c7bd94 └─luks-bcache LVM2_member uMoCp8-DpCf-L5Ic-jxBq-xx5w-A0He-xT9q59 └─cached-cached_btrfs btrfs cached e6bc23e5-4270-469c-8dee-c56dbb6132d5 /home nvme0n1 ├─nvme0n1p1 vfat F783-E5D0 /boot ├─nvme0n1p2 ext2 0cfcccf4-4c29-4b85-8c61-0c0ddaf444b6 ├─nvme0n1p3 crypto_LUKS 6b364a9a-e599-4c63-96cd-c4e95062c2ac │ └─luks-ssd LVM2_member ZeqGr5-EHP0-poFq-65Ui-6Krw-C4HG-Nou2X4 │ ├─ssd-swap swap 11eb4918-7d7c-4f7a-b1c7-dd912a823637 [SWAP] │ └─ssd-root btrfs root f1bb09de-4090-4c93-9743-4bc748ceb258 /root └─nvme0n1p4 bcache bf7969b5-c292-4a86-9075-81422c72cce4 Kernel: 4.7.2-1-ARCH (с текущим LTS такая же проблема) Boot options: cryptdevice=PARTUUID=97eb0135-251f-4167-b43a-e6c917b19353:luks-ssd:allow-discards root=UUID=f1bb09de-4090-4c93-9743-4bc748ceb258 resume=UUID=11eb4918-7d7c-4f7a-b1c7-dd912a823637 rd.luks.options=discard rw initcall_debug log_buf_len=16M Иксы отключены вообще, чтобы сейчас не воевать в проблемами драйверов графики. Всё происходит исключительно с голой консолью. Проблема Система нормально восстанавливается после systemctl suspend/hibernate/hybrid-sleep, но устройство nvme0 (pci ssd, на котором корневая фс лежит) исчезает. Соответственно, через 10 секунд после восстановления я получаю тонны ошибок btrfs и bcache об ошибках ввода-вывода. Работающие программы продолжают работать, про любые другие я получаю "неверный дескриптор" или "ошибка ввода-вывода", что логично. NVMe SSD работает по PCI, поэтому догадался посмотреть, что там ядро вообще думает на этот счёт. Сразу по пробуждении у меня есть устройства /dev/nvme0 и /sys/bus/pci/devices/0000:3e:00.0. Вероятно, это просто восстановленное состояние. Через несколько секунд (<15) меня заваливает ошибками ввода-вывода и /dev/nvme0 с /sys/bus/pci/devices/0000:3e:00.0 больше нет. Вероятно, что-то происходит или уже произошло и ядро устройство теряет и дальше беда. Я могу сделать echo 1 > /sys/bus/pci/rescan. Тогда опять появляется /sys/bus/pci/devices/0000:3e:00.0. И ещё появляется /dev/nvme1 (номер меняется). Устройство как ни в чем не бывало работает. Ну, только мой слоёный пирог блочных устройств как-то там ссылается в сторону nvme0, а это nvme1 и это никак не помогает. Нашлось бы оно с тем же номером, тоже не помогло, наверное :) Что ещё пробовал: Включал синхронное засыпание echo 0 > /sys/power/pm_async - никакой разницы. Пробовал софт-режим засыпания echo freeze > /sys/power/state - работает, но это не suspend-to-ram и не suspend-to-disk, которые мне нужны. Пробовал через /sys/power/pm_test и echo mem > /sys/power/pm_test тестировать. echo freezer > /sys/power/pm_test - тест проходит echo devices > /sys/power/pm_test - тест проходит echo platform > /sys/power/pm_test - устройство отваливается, как при полном засыпании Что знание об этом мне дало? Да ничего не дало. Что могу показать. Запущенный до засыпания и прибитый после просыпания и груды ошибок journalctl -f > log.txt на флэшку http://knopki.github.io/tmp/nvme0problem/log.txt Лог странный, потому что дальше куча ошибок должна быть, которые journalctl не выдаёт. Вероятно, когда ломается запись в /var/log, то и journalctl перестаёт выдавать сообщения. Фотография journalctl -f на экране через секунду после пробуждения: http://imgur.com/a/JVo5O Фотография journalctl -f на экране через 10 секунд после пробуждения: http://imgur.com/a/v2DbK Вывод analyze_suspend.py из https://01.org/suspendresume : mem_dmesg.txt http://knopki.github.io/tmp/nvme0problem/alien_mem_dmesg.txt mem_ftrace.txt http://knopki.github.io/tmp/nvme0problem/alien_mem_ftrace.txt mem.html http://knopki.github.io/tmp/nvme0problem/alien_mem.html Я сначала грешил на железную проблему. Типа при саспенде питание снимается с чего-то, с чего не должно сниматься. Но проблема же проявляется и тогда, когда система восстанавливается из гибернации. Т.е. состояние восстанавливается нормально, но потом происходит какое-нибудь перечисление устройств или что-то такое и часть pci-устройств теряется. Буду признателен за любую помощь и подсказки, в какую сторону копать и какой грязный хук применять!

# 7 лет, 7 месяцев назад (отредактировано 7 лет, 2 месяца назад)

Сообщения: 4

Участник с: 31 августа 2016

Здравствуй, дорогое сообщество! Новоприбывший арчевод здесь, просит помощи.

Мой сетап

Alienware 15 R2 с последним BIOS (1.3.6), Skylake i7-6700HQ и Samsung 950 Pro NVMe (вот это важно).

00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 07)
00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 07)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
00:04.0 Signal processing controller: Intel Corporation Skylake Processor Thermal Subsystem (rev 07)
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal subsystem (rev 31)
00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1 (rev 31)
00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA Controller [AHCI mode] (rev 31)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #1 (rev f1)
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #5 (rev f1)
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #6 (rev f1)
00:1c.6 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #7 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31)
00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
01:00.0 3D controller: NVIDIA Corporation GM204M [GeForce GTX 970M] (rev ff)
3b:00.0 Ethernet controller: Qualcomm Atheros Killer E2400 Gigabit Ethernet Controller (rev 10)
3c:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
3d:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01)
3e:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller (rev 01)

nvme0 - ssd
sda - hdd
/boot on nvme0n1p1
swap on lvm on luks on nvme0n1p3
/root and /boot btrfs subvolumes on lvm on luks on nvme0n1p3
/home btrfs subvolume on lvm on luks on bcache (sda6 + nvme0n1p4)
Звучит переусложненно, но на самом деле всё просто. Важно тут то, что корневая система на lvm в шифрованном luks на ssd. Промежуточные слои можно опустить, проблема с нижним.

NAME                        FSTYPE      LABEL      UUID                                   MOUNTPOINT
sda
├─sda1
├─sda2                      vfat        ESP        39B4-82EE
├─sda3                      ntfs        OS         EE106F0129C7BF33
├─sda4                      ntfs        WINRETOOLS CA21D5BD3C4F0B5D
├─sda5                      ntfs        Image      E2C9C8F05DC95E5F
└─sda6                      bcache                 17540d53-7b5f-4998-bff7-b4b09f8c7f13
  └─bcache0                 crypto_LUKS            ead98797-7022-4160-829f-8380d5c7bd94
    └─luks-bcache           LVM2_member            uMoCp8-DpCf-L5Ic-jxBq-xx5w-A0He-xT9q59
      └─cached-cached_btrfs btrfs       cached     e6bc23e5-4270-469c-8dee-c56dbb6132d5   /home
nvme0n1
├─nvme0n1p1                 vfat                   F783-E5D0                              /boot
├─nvme0n1p2                 ext2                   0cfcccf4-4c29-4b85-8c61-0c0ddaf444b6
├─nvme0n1p3                 crypto_LUKS            6b364a9a-e599-4c63-96cd-c4e95062c2ac
│ └─luks-ssd                LVM2_member            ZeqGr5-EHP0-poFq-65Ui-6Krw-C4HG-Nou2X4
│   ├─ssd-swap              swap                   11eb4918-7d7c-4f7a-b1c7-dd912a823637   [SWAP]
│   └─ssd-root              btrfs       root       f1bb09de-4090-4c93-9743-4bc748ceb258   /root
└─nvme0n1p4                 bcache                 bf7969b5-c292-4a86-9075-81422c72cce4

Kernel: 4.7.2-1-ARCH (с текущим LTS такая же проблема)
Boot options: cryptdevice=PARTUUID=97eb0135-251f-4167-b43a-e6c917b19353:luks-ssd:allow-discards root=UUID=f1bb09de-4090-4c93-9743-4bc748ceb258 resume=UUID=11eb4918-7d7c-4f7a-b1c7-dd912a823637 rd.luks.options=discard rw initcall_debug log_buf_len=16M

Иксы отключены вообще, чтобы сейчас не воевать в проблемами драйверов графики. Всё происходит исключительно с голой консолью.

Проблема
Система нормально восстанавливается после systemctl suspend/hibernate/hybrid-sleep, но устройство nvme0 (pci ssd, на котором корневая фс лежит) исчезает. Соответственно, через 10 секунд после восстановления я получаю тонны ошибок btrfs и bcache об ошибках ввода-вывода. Работающие программы продолжают работать, про любые другие я получаю "неверный дескриптор" или "ошибка ввода-вывода", что логично.

NVMe SSD работает по PCI, поэтому догадался посмотреть, что там ядро вообще думает на этот счёт. Сразу по пробуждении у меня есть устройства /dev/nvme0 и /sys/bus/pci/devices/0000:3e:00.0. Вероятно, это просто восстановленное состояние. Через несколько секунд (<15) меня заваливает ошибками ввода-вывода и /dev/nvme0 с /sys/bus/pci/devices/0000:3e:00.0 больше нет. Вероятно, что-то происходит или уже произошло и ядро устройство теряет и дальше беда.
Я могу сделать echo 1 > /sys/bus/pci/rescan. Тогда опять появляется /sys/bus/pci/devices/0000:3e:00.0. И ещё появляется /dev/nvme1 (номер меняется). Устройство как ни в чем не бывало работает. Ну, только мой слоёный пирог блочных устройств как-то там ссылается в сторону nvme0, а это nvme1 и это никак не помогает. Нашлось бы оно с тем же номером, тоже не помогло, наверное :)

Что ещё пробовал:
Включал синхронное засыпание echo 0 > /sys/power/pm_async - никакой разницы.
Пробовал софт-режим засыпания echo freeze > /sys/power/state - работает, но это не suspend-to-ram и не suspend-to-disk, которые мне нужны.

Пробовал через /sys/power/pm_test и echo mem > /sys/power/pm_test тестировать.
echo freezer > /sys/power/pm_test - тест проходит
echo devices > /sys/power/pm_test - тест проходит
echo platform > /sys/power/pm_test - устройство отваливается, как при полном засыпании
Что знание об этом мне дало? Да ничего не дало.

Что могу показать.
Запущенный до засыпания и прибитый после просыпания и груды ошибок journalctl -f > log.txt на флэшку http://knopki.github.io/tmp/nvme0problem/log.txt
Лог странный, потому что дальше куча ошибок должна быть, которые journalctl не выдаёт. Вероятно, когда ломается запись в /var/log, то и journalctl перестаёт выдавать сообщения.

Фотография journalctl -f на экране через секунду после пробуждения: http://imgur.com/a/JVo5O
Фотография journalctl -f на экране через 10 секунд после пробуждения: http://imgur.com/a/v2DbK

Вывод analyze_suspend.py из https://01.org/suspendresume :
mem_dmesg.txt http://knopki.github.io/tmp/nvme0problem/alien_mem_dmesg.txt
mem_ftrace.txt http://knopki.github.io/tmp/nvme0problem/alien_mem_ftrace.txt
mem.html http://knopki.github.io/tmp/nvme0problem/alien_mem.html

Я сначала грешил на железную проблему. Типа при саспенде питание снимается с чего-то, с чего не должно сниматься. Но проблема же проявляется и тогда, когда система восстанавливается из гибернации. Т.е. состояние восстанавливается нормально, но потом происходит какое-нибудь перечисление устройств или что-то такое и часть pci-устройств теряется.

Буду признателен за любую помощь и подсказки, в какую сторону копать и какой грязный хук применять!

knopki	# 7 лет, 7 месяцев назад
Темы: 1 Сообщения: 4 Участник с: 31 августа 2016	Дошло, что jorunalctl -b мне не показывает ничего интересного, потому что journald на диск записать ничего не может. Поменял ему Storage на volatile, стало интереснее. journalctl --system -f http://knopki.github.io/tmp/nvme0problem/journal.txt dmesg -w http://knopki.github.io/tmp/nvme0problem/dmesg.txt Меня напрягает в логе то, что sda при восстановлении перезапускается, а про nvme тишина.

knopki

# 7 лет, 7 месяцев назад

Темы: 1

Сообщения: 4

Участник с: 31 августа 2016

Дошло, что jorunalctl -b мне не показывает ничего интересного, потому что journald на диск записать ничего не может. Поменял ему Storage на volatile, стало интереснее.
journalctl --system -f http://knopki.github.io/tmp/nvme0problem/journal.txt
dmesg -w http://knopki.github.io/tmp/nvme0problem/dmesg.txt

Меня напрягает в логе то, что sda при восстановлении перезапускается, а про nvme тишина.

vasek	# 7 лет, 7 месяцев назад (отредактировано 7 лет, 7 месяцев назад)
Темы: 47 Сообщения: 11742 Участник с: 17 февраля 2013	knopki Сразу по пробуждении у меня есть устройства /dev/nvme0 и /sys/bus/pci/devices/0000:3e:00.0. Вероятно, это просто восстановленное состояние. Через несколько секунд (<15) меня заваливает ошибками ввода-вывода и /dev/nvme0 с /sys/bus/pci/devices/0000:3e:00.0 больше нет. Вероятно, что-то происходит или уже произошло и ядро устройство теряет и дальше беда. Я могу сделать echo 1 > /sys/bus/pci/rescan. Тогда опять появляется /sys/bus/pci/devices/0000:3e:00.0. И ещё появляется /dev/nvme1 (номер меняется). Устройство как ни в чем не бывало работает. Могу и ошибаться, но судя по этим действиям, устройство /dev/nvme0.... после suspend действительно отваливается и причина я думаю в модуле nvme … (или он отваливается или с ним проблемы после выхода). echo 1 > /sys/bus/pci/rescan вынуждает выполнить новое сканирование всех шин PCI и повторно открыть ранее удаленные устройства. А потому у тебя и появляется устройство с другим номером …... Что могу посоветовать 1. Посмотреть наличие модуля nvme перед тем как выполнить заново сканирование PCI устройств … 2. Попробовать выгрузить модуль перед suspend …., для этого - создать файл /etc/pm/config.d/unload_modules (имя любое ….) - прописать в файле SUSPEND_MODULES="nvme" (если были опции, то вместе с этими опциями) Ну и перегрузиться перед пробой .... UPD.... /sys/bus/pci/rescan Description: Writing a non-zero value to this attribute will force a rescan of all PCI buses in the system, and re-discover previously removed devices. Depends on CONFIG_HOTPLUG. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 7 лет, 7 месяцев назад (отредактировано 7 лет, 7 месяцев назад)

Темы: 47

Сообщения: 11742

Участник с: 17 февраля 2013

knopki
Сразу по пробуждении у меня есть устройства /dev/nvme0 и /sys/bus/pci/devices/0000:3e:00.0. Вероятно, это просто восстановленное состояние. Через несколько секунд (<15) меня заваливает ошибками ввода-вывода и /dev/nvme0 с /sys/bus/pci/devices/0000:3e:00.0 больше нет. Вероятно, что-то происходит или уже произошло и ядро устройство теряет и дальше беда.
Я могу сделать echo 1 > /sys/bus/pci/rescan. Тогда опять появляется /sys/bus/pci/devices/0000:3e:00.0. И ещё появляется /dev/nvme1 (номер меняется). Устройство как ни в чем не бывало работает.

Могу и ошибаться, но судя по этим действиям, устройство /dev/nvme0.... после suspend действительно отваливается и причина я думаю в модуле nvme … (или он отваливается или с ним проблемы после выхода).
echo 1 > /sys/bus/pci/rescan вынуждает выполнить новое сканирование всех шин PCI и повторно открыть ранее удаленные устройства. А потому у тебя и появляется устройство с другим номером …...
Что могу посоветовать
1. Посмотреть наличие модуля nvme перед тем как выполнить заново сканирование PCI устройств …
2. Попробовать выгрузить модуль перед suspend …., для этого
- создать файл /etc/pm/config.d/unload_modules (имя любое ….)
- прописать в файле SUSPEND_MODULES="nvme"
(если были опции, то вместе с этими опциями)
Ну и перегрузиться перед пробой ....
UPD....
/sys/bus/pci/rescan
Description: Writing a non-zero value to this attribute will force a rescan of all PCI buses in the system, and re-discover previously removed devices. Depends on CONFIG_HOTPLUG.

Ошибки не исчезают с опытом - они просто умнеют

knopki	# 7 лет, 7 месяцев назад (отредактировано 7 лет, 7 месяцев назад)
Темы: 1 Сообщения: 4 Участник с: 31 августа 2016	Модуль nvme присутствует и до, и после. Операцию с SUSPEND_MODULES проделал, но не уверен, что правильно - не увидел никакого отклика в логах. Зато начал играться с Arch Live и обнаружил интересное. Полагаю, проблема глубже. Выяснилось, что пропадет не только NVMe, а сразу несколько устройств: `3b:00.0 Ethernet controller: Qualcomm Atheros Killer E2400 Gigabit Ethernet Controller (rev 10) 3c:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) 3d:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01) 3e:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller (rev 01)` Более того, сразу после восстановления есть примерно 12 секунд, когда устройства перечисляются и даже работают нормально (проверил на примере чтения nvme). И где-то на 12-й секунде они исчезают. И никаких сообщений. Больше всего смущает, что так бывает и при саспенде, и при гибернации. Нашел это: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1568703 Такие же симптомы, тот же вендор, скорее всего такой же или близкий NVMe, тот же Wi-Fi. И никакого решения. Вот это тоже похоже очень https://bugzilla.kernel.org/show_bug.cgi?id=112121

knopki

# 7 лет, 7 месяцев назад (отредактировано 7 лет, 7 месяцев назад)

Темы: 1

Сообщения: 4

Участник с: 31 августа 2016

Модуль nvme присутствует и до, и после.
Операцию с SUSPEND_MODULES проделал, но не уверен, что правильно - не увидел никакого отклика в логах.

Зато начал играться с Arch Live и обнаружил интересное. Полагаю, проблема глубже.

Выяснилось, что пропадет не только NVMe, а сразу несколько устройств:


3b:00.0 Ethernet controller: Qualcomm Atheros Killer E2400 Gigabit Ethernet Controller (rev 10)
3c:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
3d:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01)
3e:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller (rev 01)

Более того, сразу после восстановления есть примерно 12 секунд, когда устройства перечисляются и даже работают нормально (проверил на примере чтения nvme). И где-то на 12-й секунде они исчезают. И никаких сообщений. Больше всего смущает, что так бывает и при саспенде, и при гибернации.

Нашел это: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1568703
Такие же симптомы, тот же вендор, скорее всего такой же или близкий NVMe, тот же Wi-Fi. И никакого решения.

Вот это тоже похоже очень https://bugzilla.kernel.org/show_bug.cgi?id=112121

knopki	# 7 лет, 2 месяца назад
Темы: 1 Сообщения: 4 Участник с: 31 августа 2016	Найден виновник торжества: acpiphp Временный костыль: acpiphp.disable=1 в параметры загрузки. Подробности нахождения: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1655100