knopki |
|
Темы:
1
Сообщения:
4
Участник с: 31 августа 2016
|
Здравствуй, дорогое сообщество! Новоприбывший арчевод здесь, просит помощи. Мой сетап Alienware 15 R2 с последним BIOS (1.3.6), Skylake i7-6700HQ и Samsung 950 Pro NVMe (вот это важно).
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. Промежуточные слои можно опустить, проблема с нижним.
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 |
|
Темы:
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 |
|
Темы:
47
Сообщения:
11743
Участник с: 17 февраля 2013
|
knopkiМогу и ошибаться, но судя по этим действиям, устройство /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 |
|
Темы:
1
Сообщения:
4
Участник с: 31 августа 2016
|
Модуль nvme присутствует и до, и после. Операцию с SUSPEND_MODULES проделал, но не уверен, что правильно - не увидел никакого отклика в логах. Зато начал играться с Arch Live и обнаружил интересное. Полагаю, проблема глубже. Выяснилось, что пропадет не только NVMe, а сразу несколько устройств:
Более того, сразу после восстановления есть примерно 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 |
|
Темы:
1
Сообщения:
4
Участник с: 31 августа 2016
|
Найден виновник торжества: acpiphp Временный костыль: acpiphp.disable=1 в параметры загрузки. Подробности нахождения: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1655100 |