LINUX.ORG.RU
Форум — Linux-hardware  

Fedora 40. Intel WiFi AX210 мгновенный выход из suspend

 , , ,


1

3

Приветствую. Помогите разобраться с проблемой. Есть ПК на базе ASUS Prime Z590-A. В один из слотов PCI-E воткнут модуль WiFi+BT на базе Intel AX210. Шнур USB подключается к внутреннему разъему USB на материнской плате. (заранее оговорюсь, что пробовал этот кабель выводить наружу и подключать к внешнему USB порту).

В целом никаких проблем в работе модуля нет. Но, если ПК перевести в режим сна, то он мгновенно просыпается. И происходит это только один раз. Все последующие (до перезагрузки) переходы в сон/пробуждения происходят так как надо.

Перерыл весь гугл, перековырял все настройки BIOS. Ничего не помогает.

На этом же ПК установлена MacOS - в ней поведение аналогичное, и не ограничивается одним разом. Каждый уход в сон сопровождается мгновенным просыпанием. Но для этой системы есть решение. Я загрузчиком подгружаю пару табличек ACPI, делаю патч и проблема со сном уходит. Правда в этом режиме ПК не выходит из сна по нажатию на клавиатуру или мышь, только с кнопки включения на корпусе. И все это справедливо только в реалиях MacOS.

В Windows все работает идеально, никаких проблем со сном нет.

В стартовый топик не приложил никаких логов и выводов dmesg потому что не знаю, что из этого может оказаться полезным.



Последнее исправление: hurmaila (всего исправлений: 1)
← какие есть ещё способы понизить напряжение с 4.2 вольт до 2.5?
HBA-контроллер LSI SAS 9201-16i, вопрос по режим горячей замены →

Ответ на: комментарий от VladMesh

Перезагрузился.

Увел в сон (тут же проснулся), вывод journalctl -b -g suspend:

окт 21 17:13:08 mac-pro ModemManager[1394]: <msg> [sleep-monitor-systemd] system is about to suspend
окт 21 17:13:08 mac-pro lact[2392]: 2024-10-21T14:13:08.856538Z  INFO lact_daemon::suspend: suspend/resume event detected, reloading config
окт 21 17:13:09 mac-pro systemd[1]: Starting systemd-suspend.service - System Suspend...
окт 21 17:13:09 mac-pro systemd-sleep[5104]: Performing sleep operation 'suspend'...
окт 21 17:13:09 mac-pro kernel: PM: suspend entry (deep)
окт 21 17:13:18 mac-pro kernel: printk: Suspending console(s) (use no_console_suspend to debug)
окт 21 17:13:18 mac-pro kernel: PM: suspend devices took 0.287 seconds
окт 21 17:13:18 mac-pro kernel: iwlwifi 0000:05:00.0: Device was reset during suspend
окт 21 17:13:18 mac-pro kernel: PM: suspend exit
окт 21 17:13:18 mac-pro systemd-sleep[5104]: System returned from sleep operation 'suspend'.
окт 21 17:13:18 mac-pro systemd[1]: systemd-suspend.service: Deactivated successfully.
окт 21 17:13:18 mac-pro systemd[1]: Finished systemd-suspend.service - System Suspend.
окт 21 17:13:18 mac-pro audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
окт 21 17:13:18 mac-pro audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
окт 21 17:13:18 mac-pro systemd[1]: Reached target suspend.target - Suspend.
окт 21 17:13:18 mac-pro systemd-logind[1270]: Operation 'suspend' finished.
окт 21 17:13:18 mac-pro systemd[1]: Stopped target suspend.target - Suspend.
окт 21 17:13:18 mac-pro lact[2392]: 2024-10-21T14:13:18.824929Z  INFO lact_daemon::suspend: suspend/resume event detected, reloading config```


Еще раз увел в сон. Заснул. Подождал чуть-чуть, разбудил клавиатурой, снял данные.

```окт 21 17:13:08 mac-pro systemd-logind[1270]: The system will suspend now!
окт 21 17:13:08 mac-pro ModemManager[1394]: <msg> [sleep-monitor-systemd] system is about to suspend
окт 21 17:13:08 mac-pro lact[2392]: 2024-10-21T14:13:08.856538Z  INFO lact_daemon::suspend: suspend/resume event detected, reloading config
окт 21 17:13:09 mac-pro systemd[1]: Starting systemd-suspend.service - System Suspend...
окт 21 17:13:09 mac-pro systemd-sleep[5104]: Performing sleep operation 'suspend'...
окт 21 17:13:09 mac-pro kernel: PM: suspend entry (deep)
окт 21 17:13:18 mac-pro kernel: printk: Suspending console(s) (use no_console_suspend to debug)
окт 21 17:13:18 mac-pro kernel: PM: suspend devices took 0.287 seconds
окт 21 17:13:18 mac-pro kernel: iwlwifi 0000:05:00.0: Device was reset during suspend
окт 21 17:13:18 mac-pro kernel: PM: suspend exit
окт 21 17:13:18 mac-pro systemd-sleep[5104]: System returned from sleep operation 'suspend'.
окт 21 17:13:18 mac-pro systemd[1]: systemd-suspend.service: Deactivated successfully.
окт 21 17:13:18 mac-pro systemd[1]: Finished systemd-suspend.service - System Suspend.
окт 21 17:13:18 mac-pro audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
окт 21 17:13:18 mac-pro audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
окт 21 17:13:18 mac-pro systemd[1]: Reached target suspend.target - Suspend.
окт 21 17:13:18 mac-pro systemd-logind[1270]: Operation 'suspend' finished.
окт 21 17:13:18 mac-pro systemd[1]: Stopped target suspend.target - Suspend.
окт 21 17:13:18 mac-pro lact[2392]: 2024-10-21T14:13:18.824929Z  INFO lact_daemon::suspend: suspend/resume event detected, reloading config
окт 21 17:16:55 mac-pro systemd-logind[1270]: The system will suspend now!
окт 21 17:16:55 mac-pro ModemManager[1394]: <msg> [sleep-monitor-systemd] system is about to suspend
окт 21 17:16:55 mac-pro lact[2392]: 2024-10-21T14:16:55.775650Z  INFO lact_daemon::suspend: suspend/resume event detected, reloading config
окт 21 17:16:56 mac-pro systemd[1]: Starting systemd-suspend.service - System Suspend...
окт 21 17:16:56 mac-pro systemd-sleep[6119]: Performing sleep operation 'suspend'...
окт 21 17:16:56 mac-pro kernel: PM: suspend entry (deep)
окт 21 17:17:26 mac-pro kernel: printk: Suspending console(s) (use no_console_suspend to debug)
окт 21 17:17:26 mac-pro kernel: PM: suspend devices took 0.272 seconds
окт 21 17:17:26 mac-pro kernel: iwlwifi 0000:05:00.0: Device was reset during suspend
окт 21 17:17:26 mac-pro kernel: PM: suspend exit
окт 21 17:17:26 mac-pro systemd-sleep[6119]: System returned from sleep operation 'suspend'.
окт 21 17:17:26 mac-pro systemd[1]: systemd-suspend.service: Deactivated successfully.
окт 21 17:17:26 mac-pro systemd[1]: Finished systemd-suspend.service - System Suspend.
окт 21 17:17:26 mac-pro audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
окт 21 17:17:26 mac-pro audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
окт 21 17:17:26 mac-pro systemd[1]: Reached target suspend.target - Suspend.
окт 21 17:17:26 mac-pro systemd-logind[1270]: Operation 'suspend' finished.
окт 21 17:17:26 mac-pro systemd[1]: Stopped target suspend.target - Suspend.
окт 21 17:17:26 mac-pro lact[2392]: 2024-10-21T14:17:26.744153Z  INFO lact_daemon::suspend: suspend/resume event detected, reloading config```

вывод journalctl -b очень большой. Как тут принято файлы выкладывать? Могу я их загрузить в облако и ссылки дать?
hurmaila
() автор топика
Ответ на: комментарий от hurmaila

Почему ты решил, что проблема именно в этом модуле вифи?

Если вынуть, то хорошо работает сон?

Если со второго раза спит хорошо (и судя по логу), похоже на другую проблему.

А проблемы только именно в такой последовательности? А что потом, через какой промежуток снова надо два раза усыплять?

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

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

hurmaila
() автор топика
Ответ на: комментарий от papin-aziat

Я прошу прощения, ввел в заблуждение. Это когда я со сном в MacOS разбирался, то вытаскивание модуля решало проблему со сном. А тут, оказалось нет. Я вынул модуль, и все равно поведение точно такое же. Что-то другое его будит… но что?

hurmaila
() автор топика
Ответ на: комментарий от hurmaila

Гм… Интересно, что срабатывает один раз и находится в другом положении после перезагрузки…

А как усыпляешь комп?

Если из терминала systemctl suspend?
Если из виртуальной консоли systemctl suspend?

papin-aziat ★★★★★
()
Ответ на: комментарий от hurmaila

Я вынул модуль, и все равно поведение точно такое же. Что-то другое его будит… но что?

Ты уверен, что поведение точно такое же — один раз фейл и далее всё ок?

Если нет, то могу предположить, что шалят ингибиторы, иначе хз.

В любом случае протестировать мой вариант можешь, если не лень. Только у меня проблема была в обратную сторону: рандомно засыпал заново, причину долго объяснять.

Попробуй вставить небольшой таймаут перед сном, чтобы дать отработать всякой фигне.

Надо создать юнит /etc/systemd/system/my_suspend-delay.service с таким содержимым:

[Unit]
Description=DELAY before SUSPEND
Before=sleep.target

[Service]
User=root
Type=oneshot
ExecStart=sleep 5

[Install]
WantedBy=sleep.target

Потом активировать юнит:

sudo systemctl enable my_suspend-delay

Проверить, есть ли задержка в 5 секунд перед полным засыпанием компа. И если да, но это никак не помогло, то удалить юнит:

sudo systemctl disable my_suspend-delay
sudo rm /etc/systemd/system/my_suspend-delay.service
papin-aziat ★★★★★
()
Ответ на: комментарий от hurmaila

Когда проверишь предыдущий вариант и, если не сработает, то причиной может быть клава, мышь или ещё какой-то девайс.

Надо будет запретить им пробуждать комп и, если сработает, то включать поочерёдно.

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

Не, не помогло. Задержка есть, да. Засыпает дольше. Но все равно тут же просыпается.

Я тут еще обратил внимание, что в результате такого вот заспания/просыпания отваливается один из SATA дисков. Но это скорее следствие, чем причина. Потому что отключив этот диск, поведение не изменилось.

А вот это не может быть причиной? У меня установлена ddcutil для регулировки яркости с клавиатуры.

окт 21 19:25:25 mac-pro ddcutil[5670]: busno=10, sleep-multiplier =  2.00. Testing for supported feature 0x10 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: EREMOTEIO(10)]```
hurmaila
() автор топика
Ответ на: комментарий от hurmaila

А вот это не может быть причиной? У меня установлена ddcutil для регулировки яркости с клавиатуры.

Кто ж знает?! Удаляй, отключай, проверяй. Если не оно, то надо выключать и включать девайсы, которым разрешено будить комп, пока не найдётся злодей.

papin-aziat ★★★★★
()
Ответ на: комментарий от hurmaila

https://wiki.archlinux.org/title/Power_management/Wakeup_triggers#Intel_Haswell_with_LynxPoint(-LP)

Глянь сколько девайсов будят:

cat /proc/acpi/wakeup | grep enabled

Отключать из под рута, например:

$ sudo -i
# echo EHC1 > /proc/acpi/wakeup

Надо ещё разобраться чему соответствуют названия. Трюк работает до перезагрузки.

Вот так ещё можно посмотреть, что будит из usb:

grep . /sys/bus/usb/devices/*/power/wakeup

Когда найдёшь злодея, то надо ему запретить будить комп навсегда. Вариантов как это сделать больше одного.

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

Хрен его знает. Сделал вот так

Device	S-state	  Status   Sysfs node
  ---------------------------------------
  1. PEG1	  S4	*disabled  pci:0000:00:01.0
  2. PEGP	  S4	*disabled  pci:0000:01:00.0
  3. PEG0	  S4	*disabled  pci:0000:00:06.0
  4. PEGP	  S4	*disabled  pci:0000:06:00.0
  5. RP09	  S4	*disabled  pci:0000:00:1d.0
  6. PXSX	  S4	*disabled  pci:0000:0b:00.0
  7. RP10	  S4	*disabled
  8. PXSX	  S4	*disabled
  9. RP11	  S4	*disabled
  10. PXSX	  S4	*disabled
  11. RP12	  S4	*disabled
  12. PXSX	  S4	*disabled
  13. RP13	  S4	*disabled
  14. PXSX	  S4	*disabled
  15. RP14	  S4	*disabled
  16. PXSX	  S4	*disabled
  17. RP15	  S4	*disabled
  18. PXSX	  S4	*disabled
  19. RP16	  S4	*disabled
  20. PXSX	  S4	*disabled
  21. RP01	  S4	*disabled  pci:0000:00:1c.0
  22. PXSX	  S4	*disabled
  23. RP02	  S4	*disabled
  24. PXSX	  S4	*disabled
  25. RP03	  S4	*disabled
  26. PXSX	  S4	*disabled
  27. RP04	  S4	*disabled
  28. PXSX	  S4	*disabled
  29. RP05	  S4	*disabled
  30. PXSX	  S4	*disabled
  31. RP06	  S4	*disabled
  32. PXSX	  S4	*disabled
  33. RP07	  S4	*disabled
  34. PXSX	  S4	*disabled
  35. RP08	  S4	*disabled
  36. PXSX	  S4	*disabled
  37. RP17	  S4	*disabled  pci:0000:00:1b.0
  38. PXSX	  S4	*disabled
  39. RP18	  S4	*disabled
  40. PXSX	  S4	*disabled
  41. RP19	  S4	*disabled  pci:0000:00:1b.2
  42. PXSX	  S4	*disabled
  43. RP20	  S4	*disabled
  44. PXSX	  S4	*disabled
  45. RP21	  S4	*disabled  pci:0000:00:1b.4
  46. PXSX	  S4	*disabled  pci:0000:09:00.0
  47. RP22	  S4	*disabled
  48. PXSX	  S4	*disabled
  49. RP23	  S4	*disabled
  50. PXSX	  S4	*disabled
  51. RP24	  S4	*disabled
  52. PXSX	  S4	*disabled
  53. PEG2	  S4	*disabled  pci:0000:00:01.1
  54. PEGP	  S4	*disabled  pci:0000:04:00.0
  55. PEG3	  S4	*disabled  pci:0000:00:01.2
  56. PEGP	  S4	*disabled  pci:0000:05:00.0
  57. XHCI	  S4	*disabled  pci:0000:00:14.0
  58. XDCI	  S4	*disabled
  59. HDAS	  S4	*disabled  pci:0000:00:1f.3
  60. CNVW	  S4	*disabled
  61. AWAC	  S4	*disabled  platform:ACPI000E:00

все равно первый уход в сон просыпается. Хотя сам по себе метод отключает девайсы от пробуждения. Попробовал сначала только выставить disable для 57. XHCI S4 *disabled pci:0000:00:14.0 и да, от клавы/мыши комп не проснулся

hurmaila
() автор топика
Ответ на: комментарий от hurmaila

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

В бивисе всё на эту тему запретил?

Похоже проблему придётся гуглить.

papin-aziat ★★★★★
()
Ответ на: комментарий от papin-aziat

Да я уже 1,5 месяца (как обновил материнку) с этим воюю, весь гугл перерыл. Поэтому и пришел сюда от безысходности. И да, все что есть в биосе на эту и не только на эту тему пробовал выключать/включать.

Любые мои действия никаким образом не влияют на поведение. Я даже оставлял комп только с сетью, подключался к нему по SSH - отправлял в сон и результат тот же.

Ну разве что я не вынимал видюху и накопители (6 SATA + 4 NVME).

hurmaila
() автор топика
Ответ на: комментарий от hurmaila

Может модуль ядра какой-нибудь загружается или наоборот выгружается после первого сна? (пальцем в небо, не знаю возможно ли такое)

Может глянуть что загружено до и после?

papin-aziat ★★★★★
()
Ответ на: комментарий от hurmaila

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

papin-aziat ★★★★★
()
Ответ на: комментарий от hurmaila

Попробовал задизейблить все pci устройства от просыпания, как пишут по похожему случаю вот тут https://bbs.archlinux.org/viewtopic.php?pid=2061800#p2061800

Не помогло

lspci && grep . /sys/bus/pci/devices/*/power/wakeup
00:00.0 Host bridge: Intel Corporation Device 4c43 (rev 01)
00:01.0 PCI bridge: Intel Corporation Device 4c01 (rev 01)
00:01.1 PCI bridge: Intel Corporation Device 4c05 (rev 01)
00:01.2 PCI bridge: Intel Corporation Device 4c07 (rev 01)
00:06.0 PCI bridge: Intel Corporation Device 4c09 (rev 01)
00:14.0 USB controller: Intel Corporation Tiger Lake-H USB 3.2 Gen 2x1 xHCI Host Controller (rev 11)
00:14.2 RAM memory: Intel Corporation Tiger Lake-H Shared SRAM (rev 11)
00:15.0 Serial bus controller: Intel Corporation Tiger Lake-H Serial IO I2C Controller #0 (rev 11)
00:15.1 Serial bus controller: Intel Corporation Tiger Lake-H Serial IO I2C Controller #1 (rev 11)
00:16.0 Communication controller: Intel Corporation Tiger Lake-H Management Engine Interface (rev 11)
00:17.0 SATA controller: Intel Corporation Device 43d2 (rev 11)
00:1b.0 PCI bridge: Intel Corporation Tiger Lake-H PCIe Root Port #17 (rev 11)
00:1b.2 PCI bridge: Intel Corporation Device 43c2 (rev 11)
00:1b.4 PCI bridge: Intel Corporation Device 43c4 (rev 11)
00:1c.0 PCI bridge: Intel Corporation Tiger Lake-H PCIe Root Port #1 (rev 11)
00:1d.0 PCI bridge: Intel Corporation Tiger Lake-H PCI Express Root Port #9 (rev 11)
00:1f.0 ISA bridge: Intel Corporation Z590 LPC/eSPI Controller (rev 11)
00:1f.3 Audio device: Intel Corporation Tiger Lake-H HD Audio Controller (rev 11)
00:1f.4 SMBus: Intel Corporation Tiger Lake-H SMBus Controller (rev 11)
00:1f.5 Serial bus controller: Intel Corporation Tiger Lake-H SPI Controller (rev 11)
01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch (rev c1)
02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] (rev c1)
03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21/23 HDMI/DP Audio Controller
03:00.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 73a6
03:00.3 Serial bus controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21 USB
04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961/SM963
05:00.0 Network controller: Intel Corporation Wi-Fi 6E(802.11ax) AX210/AX1675* 2x2 [Typhoon Peak] (rev 1a)
06:00.0 Non-Volatile memory controller: Sandisk Corp WD PC SN810 / Black SN850 NVMe SSD (rev 01)
08:00.0 Ethernet controller: Intel Corporation Ethernet Controller I225-V (rev 03)
09:00.0 Non-Volatile memory controller: Sandisk Corp WD Green SN350 240GB (DRAM-less) / SN560E NVMe SSD (rev 01)
0b:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO
/sys/bus/pci/devices/0000:00:01.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:00:01.1/power/wakeup:disabled
/sys/bus/pci/devices/0000:00:01.2/power/wakeup:disabled
/sys/bus/pci/devices/0000:00:06.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:00:14.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:00:16.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:00:17.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:00:1b.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:00:1b.2/power/wakeup:disabled
/sys/bus/pci/devices/0000:00:1b.4/power/wakeup:disabled
/sys/bus/pci/devices/0000:00:1c.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:00:1d.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:00:1f.3/power/wakeup:disabled
/sys/bus/pci/devices/0000:01:00.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:02:00.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:03:00.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:03:00.1/power/wakeup:disabled
/sys/bus/pci/devices/0000:03:00.2/power/wakeup:disabled
/sys/bus/pci/devices/0000:03:00.3/power/wakeup:disabled
/sys/bus/pci/devices/0000:04:00.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:05:00.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:06:00.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:08:00.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:09:00.0/power/wakeup:disabled
/sys/bus/pci/devices/0000:0b:00.0/power/wakeup:disabled
hurmaila
() автор топика
Ответ на: комментарий от hurmaila

выложил по ссылке https://cloud.krylov.tech/s/xMBRPwr7SJjPJ45

Падает драйвер wifi. Баг, пиши в багзиллу.

Временное решение (скорее всего не сработает). Перед suspend (засыпанием) удалить модули

# modprobe -r iwlwifi iwlmvm

после пробуждения загрузить обратно

#modprobe -a iwlwifi iwlmvm
anonymous
()
Ответ на: комментарий от hurmaila

Недавно была такая же проблема, но у меня нвидиа, вылечило задействование служб nvidia-suspend.service и nvidia-resume.service. После одного из обновлений эти службы почему-то удалились и их пришлось вручную enable

Может что-то подобное есть и для AMD?

Посмотрите, что у вас в ls /usr/lib/systemd/system

dmitry237 ★★★★
()
Последнее исправление: dmitry237 (всего исправлений: 1)
Ответ на: комментарий от hurmaila

Я сужу по объективным данным - выхлоп dmesg. В выложенном dmesg при пробуждении падает модуль iwlwifi. Что происходит без wifi карточки, я ничего не знаю, кроме твоих общих слов.

anonymous
()
Ответ на: комментарий от i586

Полностью выключил ПК. Включил. Выполнил echo 1 > /sys/power/pm_debug_messages Перевол ПК в режим сна. Он проснулся. Собрал полный dmesg с начала загрузки и до конца

https://cloud.krylov.tech/s/Jd6GicaGWLCCfdn

Затем еще раз перевел в режим сна, он ожидаемо уснул. Я подождал около 40 секунд. Разбудил его с клавиатуры. Собрал еще раз полный dmesg

https://cloud.krylov.tech/s/iQyqrSGrs5LEQBE

hurmaila
() автор топика
Ответ на: комментарий от hurmaila

Оба лога одинаковы до разницы в timestamp’ах. В обоих падает (не просыпается?) iwlwifi.

Осюда вывод: проблема в кривом ACPI, материнке или в другом подключенном устройстве. Но wifi однозначно некорректно отрабатывает засыпание-просыпание.

anonymous
()
Ответ на: комментарий от anonymous

про ACPI похоже. Так как именно правкой таблиц ACPI аналогичная проблема мной решалась для MacOS. Там я применял следующую таблицу и патч:

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

Добавлена таблица SSDT-GPRW.aml

DefinitionBlock ("", "SSDT", 2, "DRTNIA", "GPRW", 0x00000000)
{
    External (XPRW, MethodObj)    // 2 Arguments

    Method (GPRW, 2, NotSerialized)
    {
        If (_OSI ("Darwin"))
        {
            If ((0x6D == Arg0))
            {
                Return (Package (0x02)
                {
                    0x6D, 
                    Zero
                })
            }

            If ((0x0D == Arg0))
            {
                Return (Package (0x02)
                {
                    0x0D, 
                    Zero
                })
            }
        }

        Return (XPRW (Arg0, Arg1))
    }
}

Подгруженная таблица работает только, если применить патч:

<key>ACPI</key>
	<dict>
		<key>Patch</key>
		<array>
			<dict>
				<key>Base</key>
				<string></string>
				<key>BaseSkip</key>
				<integer>0</integer>
				<key>Comment</key>
				<string>Change GPRW to XPRW, needs SSDT-GPRW.aml</string>
				<key>Count</key>
				<integer>0</integer>
				<key>Enabled</key>
				<true/>
				<key>Find</key>
				<data>R1BSVwI=</data>
				<key>Limit</key>
				<integer>0</integer>
				<key>Mask</key>
				<data></data>
				<key>OemTableId</key>
				<data></data>
				<key>Replace</key>
				<data>WFBSVwI=</data>
				<key>ReplaceMask</key>
				<data></data>
				<key>Skip</key>
				<integer>0</integer>
				<key>TableLength</key>
				<integer>0</integer>
				<key>TableSignature</key>
				<data></data>
			</dict>
		</array>
	</dict>

Данное решение я утащил на «буржуйском» форуме. Поверхностно то, что оно делает я понимаю, но не более. Вот если бы кто-то мог подсказать, возможно ли применение аналогичного решения для Fedora и если да, то как

hurmaila
() автор топика
Ответ на: комментарий от hurmaila

Этот патч просто запрещает пробуждение от любых событий, включая клавитуру и мышь. Проще в биосе настроить, если биос непорезанный.

anonymous
()

Наверняка проблема аппаратная. Или драйверная, что почти то же самое.
Типа такой: при перезагрузке регистры какого-то устройства сбрасываются в начальное состояние. А потом драйвер это устройство не совсем корректно инициализирует. А при первом уходе/выходе из сна всё встаёт на своё место.
Я вот пользуюсь кривоватым драйвером для HDMI-audio на одноплатнике. При первом воспроизведении любого звука после презагрузки слышно скрип и бульканье, только в одном канале и с пониженной в 2 раза частотой звука. А со второго воспоризвдения - всё идеально до самой перезагрузки!

PeleWin
()
← какие есть ещё способы понизить напряжение с 4.2 вольт до 2.5?
Linux-hardware
HBA-контроллер LSI SAS 9201-16i, вопрос по режим горячей замены →