Компьютер не восстанавливается после выхода из спящего режима

Проапгрейдил компьютер.
После замены материнской платы при загрузке и выходе из сна стали появляться ошибки AE_NOT_FOUND

Результат работы dmesg | grep AE_NOT_FOUND

[    2.816807] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT0._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) 
[    2.816869] ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT0._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-531) 
[    2.816985] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT2._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) 
[    2.817031] ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT2._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-531) 
[    2.819053] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT3._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) 
[    2.819125] ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT3._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-531) 
[    2.819203] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT2._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) 
[    2.819248] ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT2._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-531) 
[    2.820661] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT1._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) 
[    2.820706] ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT1._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-531) 
[    2.821635] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT0._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) 
[    2.821678] ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT0._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-531) 
[    2.823594] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT3._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) 
[    2.823654] ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT3._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-531) 
[    2.826692] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT1._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) 
[    2.826738] ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT1._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-531)

Сами по себе ошибки не мешали и я даже нашёл способ подавить их вывод, добавив параметр libata.noacpi=1 в переменную GRUB_CMDLINE_LINUX_DEFAULT.

Изучение файла boot.msg наводит на мысль, что источником проблем является обращение к ata. Небольшой кусочек:

<6>[    2.819294] ata4.00: ATA-7: SAMSUNG HD320LJ, BT100-15, max UDMA7
<6>[    2.819411] ata4.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 32), AA
<3>[    2.820661] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT1._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330)
<3>[    2.820706] ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT1._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-531)
<6>[    2.820794] ata2.00: ATA-8: SAMSUNG HD103SJ, 1AJ10001, max UDMA/133
<6>[    2.820928] ata2.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 32), AA
<6>[    2.821319] ata1.00: Features: Trust Dev-Sleep NCQ-sndrcv
<3>[    2.821635] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT1.SPT0._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330)
<3>[    2.821678] ACPI Error: Aborting method \_SB.PCI0.SAT1.SPT0._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-531)
<4>[    2.821750] ata1.00: supports DRM functions and may not be fully accessible

Но проблемы начались после покупки NVMe диска. После установки ОС на этот диск, компьютер перестал восстанавливаться при выходе из спящего режима.

Появляется курсор мыши на чёрном экране и на этом всё. Курсор отвечает на перемещение мыши. Можно зайти в консоль, в ней будет выведено приглашение ввести логин, но после ввода логина ничего не происходит, просто после нажатия на Enter идёт перевод строки. Запроса пароля нет, приглашение командной строки не появляется. Консоль реагирует только на Enter отображая это как переход на новую строку.

Самое интересное, что ОС, установленная на HDD продолжает прекрасно работать, выходить из сна, и который Sleep и который Hibernate.

А вот с SSD NVMe диском происходят вышеописанные проблемы.

Правда на HDD - МBR, а на SSF - EFI

Вопросы:

  1. Имеют ли вышеперечисленные ошибки отношение к такому поведению, или это просто совпадение?
  2. Имеет ли данная проблема решение (кроме как выключать компьютер каждый раз)? Можно ли как-то более детально локализовать проблему?
  3. Есть ли смысл переместить диск в другой слот?
  4. Решит ли проблему размещение загрузчика на другом диске?
  5. Есть ли смысл отказаться от EFI в пользу MBR? Правда у меня этот SSD с двумя ОС и мне бы хотелось разделов больше, чем 4-е.

Спасибо!

Вам нужны шашечки или ехать? Отключение ACPI чтобы не видеть сообщений - это несколько странная логика. Что-то не работает? Какие именно реальные проблемы без использования этого параметра вы наблюдаете?

Это проблема вашего BIOS, так что стандартная рекомендация в таких случаях - обновить до актуальной версии и написать в поддержку.

Тогда зачем вы рассказываете грустную историю о SATA?

По писанию - NVME не отвечает. Может быть много разных причин включая проблемы с конкретной моделью (и версией firmware) вашего NVME диска или с вашей материнской платой. Нет ни информации о вашей системе ни информации о вашем NVME диске.

Как общая рекомендация - попробовать обновить до актуальной версии BIOS и firmware для вашего NVME, попробовать разные режимы спячки (s2idle, deep, mem).

Не путайте теплое с мягким. EFI - это firmware, MBR - это формат информации о разделах диска. Никаких проблем использовать таблицу GPT с загрузкой в режиме legacy BIOS (или CSM) в Linux нет.

Поскольку очевидно нет доступа к NVME после выхода из сна - какая разница, где находится загрузчик? Важно, где находится операционная система и ваши данные.

Здравствуйте!

Это проблема вашего BIOS, так что стандартная рекомендация в таких случаях - обновить до актуальной версии и написать в поддержку.

У меня установлена последняя доступная версия BIOS с сайта-производителя. Чтобы не думалось, скачал свежайшую прошивку и перепрошил ещё раз: версия и дата прошивки не изменились.

Нет ни информации о вашей системе ни информации о вашем NVME диске.

ОС: OpenSUSE Leap 15.5, Kernel version: 5.14.21-150500.55.7-default (64-bit)
Processors: 24xIntel Xeon CPU-2678 V3 2.5 GHz
Disk model: NX-512 2280

По описанию - NVME не отвечает.

Второй ОС на этом же SSD установлена Windows10, устанавливалась после установки openSUSE. Никаких проблем ни со сном ни с гибернацией - нет. Наводит на мысль о том, что если бы проблема была на 100% в BIOS Windows тоже бы не просыпалась.

попробовать разные режимы спячки (s2idle, deep, mem).

Ушёл гуглить. Если ткнёте носом, где про это почитать, буду призателен.

cat /sys/power/mem_sleep

показывает поддерживаемые режимы, текущий выделен. Изменить можно записав в файл одно из значений, например

echo s2idle > /sys/power/mem_sleep

и протестировать командой

echo mem > /sys/power/state

А вообще нужны логи после выхода из спящего режима. Лучше всего подключить консоль по последовательному порту. Или запустить chroot на инсталляцию на другом диске (по предположению, запущенный процесс не должен зависнуть поскольку не использует файлаы с NVME) и после выхода из спящего режима сохранить там же выдачу dmesg.

Процессор здесь не очень интересен, скорее - производитель и модель notebook’а или системной платы. Но по крайней мере ясно, что это не AMD.

У меня десктоп. Покупал MB на Ali. Производитель HUANANZHI, материнская плата: X99-TF-Q. Ссылка на страницу производителя: HUANANZHI X99-TF-QMotherboard-HUANANZHI

Про режимы сна нагуглил здесь: System Sleep States — The Linux Kernel documentation

Т.е. мне по очереди вписать “s2idle”, “shallow”, “deep” и проверить, что получилось?

В настоящее время у меня в файле mem_seep содержится строка “s2idle [deep]”.

У меня появились новые обстоятельства. Я заметил, что иногда компьютер выходит из состояния сна. А чаще всего зависает, когда запущен редактор Visual Studio Code.

Я пытался повторить подобный кунштюк с HDD диском, но там подвисаний всё равно нет. Содержимое файла mem_sleep такое же, как и в ОС на SSD.

Зато у меня была ситуация, когда после выхода из сна, на экране было выведено всего одно окно и то оно отображалось вверх ногами.

В целом компьютер подвисает после появления курсора мыши, перед тем, как должно появиться окно логина. Но остаётся чёрный экран с курсором мыши. Если долго ничего не трогать, окно логина на секунду появляется и снова чёрный экран.

Как Вы думаете, со вновь открывшимися обстоятельствами, это однозначно недоступность диска или всё-же это просто совпадения?

Это когда два компьютера на Linux связаны друг с другом по последовательному порту? Не думаю, что в разумное время смогу соорудить нечто подобное.

Извините, не очень понял идею. Что такое chroot представляю и даже использовал при восстановлении загрузчика, когда его убила Windows, при запуске с LiveUSB.

Можете расписать подробнее, извиняюсь за невежество.

Это означает, что ваш BIOS (заявляет, что он) поддерживает modern standby и suspend-to-RAM и по умолчанию должен использоваться suspend-to-RAM. Протестировать s2idle имеет смысл.

Да, хотя как вы видите shallow ваша система не поддерживает.

Это выглядит как недоступность диска. А чтобы сказать что-то более определенное нужны логи.

Если проблемы в недоступности NVME диска при выходе из спящего режима, то chroot позволяет запустить процесс, который не будет использовать NVME. Как вы сказали, у вас есть другая инсталляция на HDD. Тогда предполагая, что /dev/sdXXX - корневой раздел этой системы, что-то вроде

mount /dev/sdXXX /mnt
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
chroot /mnt

и после выхода из спящего режима в этом же сеансе

dmesg > ./dmesg.out

Делать это все надо в текстовой консоли, поскольку GUI у вас будет недоступен. Если получится сгенерировать файл dmesg.out - выгрузите на https://susepaste.org/.

Увы, диагностика проблем со спящим режимом - это всегда нетривиальная задача. Без выдачи на консоль это сделать практически невозможно. Если у вас есть второй компьютер, можете попробовать netconsole. Тогда не нужен специальный кабель.

Спасибо за обстоятельный ответ!

Не совсем понял, в какой момент надо делать всё вышеперечисленное? После загрузки с NVME открыть терминал по Ctrl+Alt+F1, в терминале выполнить всё вышеперечисленное и отправить систему “спать”?

Да. По крайней мере, я бы попробовал так :slight_smile:

1 Like

Собственно, еще один вариант - загрузиться с HDD и выложить выдачу dmesg после выходя из спящего режима. Если предположение о проблемах с NVME правильное, то там все равно должны быть видны сообщения, относящиеся к нему.

И, кстати - вы пишете

Зависания нет, а доступ к NVME есть?

Спасибо! Попробую на досуге.

Не проверял. Обязательно гляну. Также нашёл лаптоп с дебианом. Пойду почитаю про netconsole.

Доступ к NVME есть. Вызов sudo fdisk -l показывает наличие диска как до сна, так и после сна.

Загрузился, выдача после выхода из спящего режима: https://paste.opensuse.org/pastes/25e23889876a

Это сработало. Выдача dmesg с кучей ошибок: https://paste.opensuse.org/pastes/ecf0a4932d95

К сожалению, моего понимания не хватает для интерпретации всего этого. Как Вы думаете, с этим можно будет что-то сделать? Или придётся пользоваться Гибернацией, благо она работает? Просто гибернация это не очень интересно, из-за длительного времени загрузки. Один профит - можно продолжать работу на том месте, где остановился, а не открывать приложения заново.

У меня есть сильное подозрение, что это потому, что NVME не используется. Если его смонтировать, запустить какой-нибудь нагрузочный тест (например, fio), и уйти в спячку - скорее всего, будет та же проблема.

Как и предполагалось

nvme 0000:02:00.0: AER: PCIe Bus Error: severity=Uncorrected (Fatal), type=Inaccessible, (Unregistered Agent ID)

Inaccessible и unregistered agent ID означают, что устройство в данный момент не видно.

Попробуйте параметр ядра

pcie_aspm=off
1 Like

Уже попробовал, нагуглил тотчас после получения лога. Не помогло. Как и параметр s2idle Он не то, чтобы не действует, но кулеры крутятся, какие именно мне было лень системник вскрывать. Но я подумал, что это не дело.

А кто является виновником проблемы? Материнская плата или диск? Мне чисто вписать предупреждение в карточку товара на Али. Мол если у вас ОС отличная от Windows, эти поделки брать не надо.

Запустил fio c такой конфигурацией:

[readtest]
blocksize=4k
filename=/dev/nvme0n1
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=32

(конфиг скопипастил с тырнетов)

Результат интересный. С запущенным тестом ушёл в сон. Пробудился. Тест продолжается. Ещё раз ушёл в сон. Пробудился. И вот тут диск пропал. Лог прилагаю: https://paste.opensuse.org/pastes/d81958c41166

Не знаю. Что происходит - ядро ожидает, что BIOS выполняет необходимые действия по отключению и (в первую очередь) включению устройства, но включения не происходит. Может быть, BIOS делает что-то не так, может быть устройство. Попробуйте этот же NVME на другой системе с другой материнской платой.

Единственное, что можно сделать со стороны Linux - найти правильную последовательность действий и добавить в ядро исключение для вашего устройства. Но это точно выходит за рамки этого форума. Если вы готовы вести диалог на английском и тестировать патчи ядра - вам надо в список рассылки (mailto:linux-nvme@lists.infradead.org) и можно параллельно https://bugzilla.kernel.org/

На самом деле диск пропадал в обоих случаях:

[  224.749484] nvme 0000:02:00.0: can't change power state from D3hot to D0 (config space inaccessible)
[  284.865276] pcieport 0000:00:01.1: AER: Multiple Uncorrected (Fatal) error received: 0000:02:00.0
[  284.865284] nvme 0000:02:00.0: AER: PCIe Bus Error: severity=Uncorrected (Fatal), type=Inaccessible, (Unregistered Agent ID)
[  284.865291] nvme nvme0: frozen state error detected, reset controller
[  285.049012] pcieport 0000:00:01.1: AER: Root Port link has been reset (0)
[  285.049025] nvme nvme0: restart after slot reset
[  285.088294] nvme nvme0: 8/0/0 default/read/poll queues
[  285.089325] pcieport 0000:00:01.1: AER: device recovery successful

и второй раз

[  314.535205] nvme 0000:02:00.0: can't change power state from D3hot to D0 (config space inaccessible)
[  314.585248] nvme nvme0: frozen state error detected, reset controller
[  314.585403] nvme nvme0: failed to set APST feature (-4)
[  314.585407] nvme nvme0: Removing after probe failure status: -4
[  314.598920] nvme0n1: detected capacity change from 1000215216 to 0
[  314.746880] pcieport 0000:00:01.1: AER: Root Port link has been reset (0)
[  314.746886] nvme nvme0: restart after slot reset
[  314.748323] pcieport 0000:00:01.1: AER: device recovery successful

Проблема в том, что во втором случае это произошло в момент, когда с диском шла работа, и диск “выдернули” из под файловой системы.
[ 314.598920] nvme0n1: detected capacity change from 1000215216 to 0

Потом он появился, но с точки зрения ядра, это уже был “другой” диск.

:roll_eyes:

Я пробую этот NVMe на этой же мат плате, но под управлением Windows 10. Ради чисты эксперимента все остальные диски выдернул, хотя они SATAшные. Из сна выходит. Попробовал ОС Deepin, там та же ерунда. И с выводом ошибок BIOS и с невыходом из сна. Ядро одно и тоже. Осталось только попробовать другую MB с openSUSE или Deepin. Чтобы локализовать проблему. NVMe + OS или MB + OS.

Я-то готов, но будут ли готовы собеседники тратить время на не очень компетентного товарища с ужасной грамматикой? С какой стороны подступиться к обсуждению?

Это не редкость.

И это тоже.

Проверьте сначала актуальную версию ядра.

/repositories/Kernel:/stable/standard - openSUSE Download

Это текущий stable. Есть два ядра - kernel-default (все патчи SUSE) и kernel-vanilla (“чистое” ядро без патчей).

/repositories/Kernel:/HEAD/standard - openSUSE Download

Это текущая версия, которая находится в разработке. Аналогично, два пакета.

Если проблема воспроизводится на kernel-vanilla - надо идти в список рассылки. Если vanilla работает, а kernel-default нет - надо идти в https://bugzilla.opensuse.org/.

Ну и если окажется, что kernel-default оттуда тоже работает - также в https://bugzilla.opensuse.org/.

Имейте в виду, что эти ядра не подписаны ключом SUSE, так что проще всего отключить Secure Boot.

В любом случае, пишете в заголовке что-то вроде “NVME NX-512 on motherboard X99-TF-Q missing after resume from suspend to RAM”, описываете ситуацию и прикладываете собранные файлы dmesg.

И это тоже не забудьте сказать.

1 Like

Китайская плата + китайский накопитель. Глюки, возможно, исправлены не будут.
Делая по-простому: можно продать это железо и купить более совместимое.
Т.е. решить вопрос деньгами.