Не работает suspend
В федоре 17, сусе rc и убунте 12.04 не работает суспенд. Комп сразу после суспенда включается вновь. В сусе 11.4 12.1 работает
Куда смотреть, где чинить?
Если в 11.4 и 12.1 работает, то не плохо бы написать в багзилу, а так не сталкивался, не знаю решения.
Видео карточка какая?
Это ж скрипт делает? Найди в нем строчку «performing suspend» и посмотри что он делает. Скорее всего делает что-то не то.
P. S. Комманда poweroff нормально отрабатывает?
nvidia встроеная 7025
в федоре свободный драйвер в бубунте блоб
[code]# run the sleep hooks
log «$(date): Running hooks for $ACTION.»
if run_hooks sleep «$ACTION $METHOD»; then
# Sleep only if we know how and if a hook did not inhibit us.
log «$(date): performing $METHOD»
sync
«do_$METHOD» || r=128
log «$(date): Awake.»
else
log «$(date): Inhibit found, will not perform $METHOD»
fi[/code]
что тут «не то» можно делать?
P. S. Комманда poweroff нормально отрабатывает?
комп выключается, думаю что нормально
В багзиле бубунты похожие логи есть. но там тишина.
Правда? Вот это новость! Всегда работало, а тут не работает. Как так? Не верю!
Вот так так. Называется умным словом регрессия.
Открою маленький секрет — оно так и будет, и неизвестно как долго.
Так что учите Си, плюсы и вперед чинить суспенд. Благо код открыт.
Нифига ты резкий. Много так начинил?
Не чинил вообще. Но другого выхода нету же?
С проприетарными драйверами от nv пробовали уйти в суспенд?навеяло Тыц!
Есть конечно же) После 2009 линукс как-то упорно ломают. надо шиндовс 8 глянуть)
шиндовс 8 кстати сейчас не ок (ставил на нетбук, виснет постоянно). нужен суспенд — ставь 7.
Счас блоб и суся 12.1 — суспендится на ура
блоб в бубунте не работает. счас вроде ядро 3.1 а там 3.2
Работало сначала, но с последнем ядром (3.4.5) все поломали.
Лично я заморозился и сижу на 3.4.3
Добавить acpi_sleep=nonvs в параметры ядра.
В федоре не помогло. В бубунте тоже.
Ладно, оставим пока скрипты.
0. Перед экспериментами рекомендую повыдергивать все USB/PCMCIA устройства, и в идеале делать из-под консоли (по-моему комманды hibernate-ram или s2ram), дабы уменьшить количество возможных мешающих факторов.
00. Убедись что у тебя в ядре включено вот это:
Просмотрел твой dmesg. Вот что нашел интересного:
1. «[ 67.688026] r8169 0000:03:00.0: Refused to change power state, currently in D0» Что говорит о том, что сетевуха быкует (может быть причиной). Я бы попробовал в ядре выключить эту сетевуху вообще (ну, или вручную выгрузить модуль перед тем как суспендить если он отдельный), чтобы посмотреть в ней ли проблема. И/или здесь рекомендуют поставить новые прошивки, даже описан способ для Ubuntu (правда, 2011 год) — вроде людям помогло.
Вообще, у тебя с сетевухой проблемы, очем говорит хотябы вот эта строка: «[7.635038] r8169 0000:03:00.0: vpd r/w failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update.»
2. Вот две интересные записи.
«[ 0.111982] PCI: Ignoring host bridge windows from ACPI; if necessary, use „pci=use_crs“ and report a bug»
«[ 0.115497] pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with ‘pcie_aspm=force’»
Вряд ли, но попробуй добавить эти параметры к ядру.
3. Вот здесь рекомендуют перед засыпанием запустить вот эти две комманды:
3. В процессу блуждания еще нашел рекомендацию в файле «/usr/lib/pm-utils/sleep.d/45pcmcia» закомментировать строку «/sbin/pccardctl eject»
Учитывая, что в SuSe все работал изначально, думаю, что причиной является именно пункт 1.
Источник
Система не выходит из suspend
LMDE, система не выходит из suspend. Точнее, просыпаться она пытается, но не более. Раскручиваются кулеры, просыпается ЖД, но на мониторе остаётся wait mode.
Откуда начинать копать?
P.S. Hibernate работает отлично.
Вывод lspci
Честно говоря, Suspend и Hibernate у меня из самых нелюбимых топиков. А потому дам лишь направление. В некоторых местах могу ошибаться, так что пробуй, проверяй в wiki.
Во-первых дистр и комп? Потому как первым делом нужно читать wiki по дистру, а комп поможет нагуглить подобную проблему. Если у тебя sony vaio, то это отдельная песня, там почти всегда свои особенности.
Хотя нет, вышесказанное — вторым делом, а первым делом нужно читать логи. как /var/log/messages (system,log, если Ubuntu), по-моему еще pm-utils создает что-то типа /var/log/pm-* . Читать, находить фразы, которые могу относиться к проблеме, гуглить. Да и сюда логи неплохо бы выложить (pastebin.com в помощь).
но на мониторе остаётся wait mode.
Что значит wait mode? Экран зажегся? По консолям переключается? Может просто видеосистема не поднялась. Если все плохо — Alt+Shift+sysRq+B работает (признак того, что ядро работает)?
Если ядро живое, то скорее всего просто не поднялось какое-то устройство. Тогда проблему решает rmmod + modprobe соответствующего драйвера (если он скомпилен драйвером, неплохо бы ему быть скомпиленым модулем). А постоянное решение — прописать эти модули в . по-моему в /etc/hibernate/blacklisted-modules или /etc/pm/config.d/modules, не уверен.
Еще ты должен знать что данная функция от DE (LMDE в твоем случае) никак не зависит. DE просто вызывает соответствующую команду. То есть для чистоты эксперимента ты должен попробовать усыпить ноут с помощь командной строки (команда s2ram ЕМНИП). А сам пакет, который позволяет делать всякие настройки (как, например, выгружать модули) называется pm-utils.
Принцип такой, в деталях я мог что-то напутать. А прочитать детальней можно в wiki твоего дистра или. Лучшее wiki под данному вопросу я видел у Arch. Обращай особое внимание на разделы про suspend-to-ram и Troubleshooting.
Hope this helps.
Спасибо за ответ 🙂
LMDE это и есть дистрибутив. Linux Mint Debian Edition.
Wait mode это как я и написал — система вроде бы стартует, т.е. я слышу шум кулеров, трещание ЖД, но экран продолжает моргать лампочкой, как при выключенном системнике, ожидая сигнала от видеоподсистемы.
Смотрел /val/log/pm-suspend.log, там всё хорошо. Пойду курить Arch-wiki 🙂
но экран продолжает моргать лампочкой, как при выключенном системнике, ожидая сигнала от видеоподсистемы.
Нужно определить, это просто экран не включился, или система не поднялась. Моя рекомендация базируется на следующем: пока ядро работает, Magic Combination работает. Поэтому, 1) убедись что, например, парезагрузка, работает перед suspend, 2) проверь что она работает после suspend, когда экран черный. Если работает в обоих случаях — копать в сторону «не поднялся видеодрайвер» или «не включился экран». Если не работает — сложнее, я бы копал в сторону параметров ядра, режимов выключения (если таковые есть), dsdt и т. п.
Про Magic Combination здесь: http://ru.wikipedia.org/wiki/SysRq
Перезагрузка: Alt + SysRq + B
Сброс буферов диска: Alt + SysRq + S
Перезагрузка — жесткая, как при reset, так что перед этим сбрось буферы диска.
Если не работает, проверяй включена ли вообще эта фича:
$ cat /proc/sys/kernel/sysrq
Должно быть 1. Если 0, то
$ echo «1» > /proc/sys/kernel/sysrq
И проверь опять.
Если не получается, проверь как ты зажимаешь. Alt + SysRq + S значит, что ты зажимаешь 3 кнопки: Alt, Shift, SysRq , и с этими зажатыми кнопками нажимаешь s .
Это должно работать, если нет — это проблема и ее нужно решать (никогда не видел чтобы не работало).
Также, если просто не включился экран, то простое выключение по кнопке Pоwer должно работать. Короче проверь с SysRq и с кнопкой Power. Если Power работат, то это точно что просто не включился экран или не поднялся видеодрайвер, тогда это просто.
$ cat /proc/sys/kernel/sysrq
Должно быть 1. Если 0, то
Но спасибо, дальше план действий намечен, буду ковырять.
Источник
Ноутбук не выходит из спящего, иногда и из ждущего режима
Иногда при выходе из ждущего на экране выходит:
А из спящего вообще не выходит. В hibernate.log ничего интересного, последний suspend из которого не вышел компьютер, а просто включился как-бы заново:
Swap: 4384764 кб Оболочка: kde
Давай сначала с hibernate разберемся.
Сначала:
— по возможности сбрось BIOS в дефолтные значения, если можешь; выставь только то, что нужно.
— по возможности выйми все USB и PCMCIA девайсы;
— сделай `cat /dev/null > /var/log/messages ` (непосредственно перед перезагрузкой)
— перегрузись
a) Дай `free -m ` (непосредственно перед hibernate)
b) Сделай hibernate, включи (я так понял, что будет заново загружаться) и дай ПОЛНЫЕ /var/log/messages и hibernate.log .
c) Дай текущий конфиг ядра
d) Параметры ядра в загрузчике
e) Дай вывод `fdisk -l /dev/sda ` (у тебя ж система на sda?)
— Bios сбосил, кроме FAN Control — Normal — Была подключена только мышь беспроводная, выдернул — Файл /var/log/messages был пустой, но был /var/log/messages.1 — его я и очистил — перезагрузился А) $ free -m
d) grub.cfg часть с текущим ядром:
e) fdisk -l /dev/sda/
Может, ему в параметры ядра нужно resume=/dev/sda6 передать.
a) Ok.
b) Игнорь /var/log/messages.1 — это архив прошлого /var/log/messages
/var/log/messages не может быть пустой после загрузки. Еще раз последовательность действий: 1) очищаешь 2) перегружаешься 3) уводишь в hibernate 4) включаешь, загружаешься 5) выкладываешь на pastebin.com
c) Уфф. У меня с работы закрыт доступ в google docs, посмотрю дома. В следующий раз пользуйся чем-то полегковесней, например, pastebin.com
d) Совет post-factum выше скорее всего поможет.
e) Ok.
—
Если добавление опции к ядру не поможет — дай содержимое этих файлов, если они есть:
/etc/initramfs-tools/conf.d/resume
/etc/uswsusp.conf
/etc/default/acpi-support
Подскажите пожалуйста, куда конкретно вставить это? После какой-то строки или в первую строку?
b) /var/log/message как не странно был даже до нулла пуст. Может где-то логи надо включить? c) Спасибо что сказали про такой сайт, вставил туда — http://pastebin.com/VzkfQHGV d) Сейчас разбирусь только куда вставлять) не очень понял.
/var/log/messages Наверное ты пустой файл создал без s. Логи, конечно, можно выключить, но я не видел ни одного дистрибутива где бы это было сделано по умолчанию.
К сожалению файл который существует называется messages, я в сообщении букву забыл.
Спасибо, но не помогло.
Выкладываю тогда содержимое запрошенных файлов: /etc/initramfs-tools/conf.d/ — пустая папка.
. Ну и далее процесс записи в свап идёт.
Упс, я с тегами напортачил.
Покопал немного по твоей проблеме.
Сначала немного теории (полная английская версия тут). Есть три бекенда («движка» или «метода» или софта) для hibernate и suspend: kernel (родной в ядре), uswsusp и tuxonice (только hibernate). Какой использует — заведует служба pm-utils (фронтэнд). Какой использовать указывается в переменной SLEEP_MODULE в каком-то из файлов в каталоге /etc/pm/ (и его подкаталогах), но если там ничего нет, то дефолтный можно посмотреть в /usr/lib/pm-utils/defaults . Теоретически запуск pm-hibernate или pm-suspend будет запускать соответствующую функцию нужного нужный бекенда.
(1) Выясни есть ли у тебя файл с переменной SLEEP_MODULE в каталоге/подкаталогах /etc/pm/ , если нет — найди эту переменную в /usr/lib/pm-utils/defaults и расскажи что там написано.
У uswsusp для hibernate используется команда s2disk, для suspend — s2ram .
Что касается s2ram . Я не могу определить используется ли он для засыпания, поэтому (2) попробуй поусыплять ноут командой s2ram : получается? Всегда просыпается или как раньше иногда с зависанием?
Из сообщения в твоем первом посте видно что какое-то устройство PNP0C0D:00 не просыпается. Это устройство по идее можно будет определить из лога ядра /var/log/messages но что-то у тебя с ним тяжело выходит; поэтому пока ты тестируешь s2ram (3) выдай хотябы вывод команды dmesg (он будет большой — на pastebin.com). Если с железом у тебя все ок, его должно хватить для понимания кто такой PNP0C0D:00.
На всякий случай оставлю этот линк здесь; тут варианты решения на случай если договориться тет-а-тет с устройством не получится.
Теперь что касается s2disk. Из hibernate.log в твоем первом посте можно понять что для hibernate изначально используется именно он. Как я понял, в Ubuntu он настраивается командой dpkg-reconfigure uswsusp , и ошибок там быть не может. Мне кажется проблема в том, что у тебя установлен tuxonice, и именно он пытается восстановиться при следующем включении, а не uswsusp.
Давай попробуем с tuxonice.
Вот здесь человек рассказывает как ставил tuxonice. (4) Проверь, пожалуйста, установлены ли у тебя каике-то из пакетов tuxonice-userui, linux-generic-tuxonice, linux-headers-generic-tuxonice . Если установлено linux-generic-tuxonice, а что-то другое нет, доставь остальное. Если linux-generic-tuxonice не установлено — ничего не делай, просто отпишись. (5) Еще одна проверка на tuxonice — в выводе комманды uname -rv должно присутствовать «tuxonice»; есть?. Если ты что-то доустанавливал — попробуй команду hibernate . Если не работает, то я вижу две возможных проблемы: 1) не указана партиция для сохранения образа и 2) метод комперсии.
1) (6) Посмотри файл /etc/hibernate/tuxonice.conf и убедись что там есть строка ‘SuspendDevice swap:/dev/sda6’ . Если нет — добавь. И вообще дай его содержимое сюда. Попробуй запусти команду ` hibernate -F /etc/hibernate/tuxonice.conf `. Если все еще не работает, (7) Найди в этом файле строку ‘ Compressor lzo ‘ и замени на ‘ Compressor none ‘ . Еще раз запусти ` hibernate -F /etc/hibernate/tuxonice.conf `.
Так, по результатам, я надеюсь увидеть содержимое переменной SLEEP_MODULE, ответ всегда ли просыпается после s2ram, вывод dmesg (а то и /var/log/messages), подтверждение что у тебя tuxonice и вывод команды uname -rv, и если у тебя таки tuxonice — содержимое файла /etc/hibernate/tuxonice.conf , а то и работающий hibernate по крайней мере из консоли. Давай пока так.
В первую очередь хочу сказать Вам огромнейшее спасибо за такое большое внимание!
1) В /etc/pm/ только 3 файла и в них нету переменной: config.d power.d sleep.d sudo grep -rn SLEEP_MODULE /usr/lib/pm-utils/defaults
2) s2ram всегда просыпается. Раз 10 пробовал. 🙂 Но слышал что опасен ждущий режим для оперативы.
4) нечего из tuxonice не установлено и linux-generic-tuxonice тоже.
5) uname -rv 3.4.4-030404-generic #201206221555 SMP Fri Jun 22 20:03:28 UTC 2012
6) /etc/hibernate/tuxonice.conf соответственно нету.
Сейчас времени не особо много, пока так:
1) Ok, значит используется kernel (хотя логи говорят обратное — разберемся позже)
2) Ок. Значит нужно его сделать дефолтным. Чуть позже поищу как.
3) Чуть позже проанализирую, хотя пока все работает (в частности не проявляется проблема ждущего режима описанная в первом сообщении), особых причин для анализа нет.
4) Ок. Забываем про tuxonice и команду hibernate.
5) Ok, tuxonice нет.
6) Ok.
Теперь давай попробуем с hibernate. Я попрошу тебя просто переинсталлить uswsusp ( ЕМНИМ в Ubuntu это делается командой ` sudo apt-get install uswsusp `, но можешь делать так как ты обычно инсталлишь проги) и усыпить комп командой s2disk. Отпишись что получилось.
В первую очередь хочу сказать Вам огромнейшее спасибо за такое большое внимание!
На этом мир держится. Можно на «ты».
Удалил и установил uswsusp, при удалении и установке выходила ошибка:
Далее уснул командой s2disk. И при просыпании вылезли ошибки на чёрном экране сначала что-то про USB — запомнить я не успел, штук 6 похожих. Затем на чёрном фоне вылезло окно класического стиля GTK: «Ubuntu is running in low-graphics mode» — в котором я нечего не мог сделать, так как мышка не работала, на enter не реагировало, но среагировало на Esc, и появился как-бы процесс загрузки (который можно увидеть при старте Ubuntu, если нажать соответствующие клавишы), но в нём не запускались иксы, а при нажатии клавиш печатались символы разные. Пришлось перезагрузить.
Сейчас опять переустановил также и нормально проснулся из s2ram.
Ноутбук сам ушел в ждущий режим (видимо это был метод kernel), и затем при выходе из него на экране была куча надписей (ошибок), вот часть из них сфотографировал (в логах их не нашел, messages также пустой, так что не зря сфотографировал): http://bit.ly/OGux0z
Лог ядра можно увидеть командой dmesg. Файл с классическим названием /var/log/messages на 95% состоит из лога ядра плюс туда пишут свои логи системные службы и некоторые другие приложения. То есть он содержит чуть больше информации. Еще достоинство этого файла — это файл, а значит после перезагрузки он просто будет дописываться, тогда как лог ядра по умоланию находится в памяти и после перезагрузки теряется. Как я понял отсюда, в Ubuntu этот файл называется /var/log/syslog . Проверь, есть ли у тебя такой файл. Если нет — просмотри другие файлы в каталоге /var/log ; критерий поиска — содержимое должно очень напоминать то, что выводит команда dmesg. Этот файл просто незаменим при решении проблем с загрузкой, с железом и драйверами и некоторых других.
(1) Сообщи, нашел ли ты файл и как он называется.
Пока я буду считать что он называется /var/log/syslog .
Удалил и установил uswsusp, при удалении и установке выходила ошибка:
Как я понял — ничего страшного. По крайне мере пока так будем считать.
Давай проверим стал ли uswsusp дефолтным. Но, поскольку я не знаю как оценить разницу, просмотри файлы в /etc/pm/ в поисках файла с переменной SLEEP_MODULE, там должно быть что-то типа SLEEP_MODULE=«uswsusp» ; говорят это должен быть файл /etc/pm/config.d/00_sleep-module , но если его нет — просмотри все. Если не найдешь ничего, создай файл /etc/pm/config.d/00_sleep-module и внеси туда 2 строки:
SLEEP_MODULE=«uswsusp»
и одну пустую (некоторые программы не любят, когда последний символ не перевод строки, поэтому я просто всегда перестраховываюсь).
Убедись, что pm-suspend должен делать то же (ну, почти), что и s2ram, а pm-hibernate — то же, что и s2disk. На самом деле могут быть различия в процессе, но результат должен быть один. По крайней мере, поскольку s2ram у тебя точно работал, pm-suspend точно должен работать.
(2) Сообщи что ты в каком файле нашел переменную SLEEP_MODULE, если не нашел — дописал ли, и как отработали после этого pm-suspend и pm-hibernate.
Далее уснул командой s2disk. И при просыпании вылезли ошибки на чёрном экране сначала что-то про USB — запомнить я не успел, штук 6 похожих
На самом деле это шаг вперед, так как по крайней мере мы уже загружаемся с сохраненного образа. Нюансы могут быть в том, что не все железо нормально возобновляет работу (это обычно у suspend) или не все драйвера/модули ядра нормально подымаются (как правило у hibernate), Судя по тому, что ты описываешь, у тебя не поднялся драйвер видяхи. На самом деле pm-hibernate может это решить, так что проверь работу pm-hibernate.
Действия, когда не работает либо suspend либо hibernate: мне нужен лог системы и список подгруженных модулей ядра до и после suspend/hibernate.
С логом системы все просто. Если ты нашел его (предположительно /var/log/syslog ), то он каждый раз дописывается, просто после перезагрузки выложи его на pastebin.com .
Подгруженные модули ядра можно увидеть командой lsmod . Тут тоже все несложно: когда система коряво поднялась (и она в этом состоянии), запусти из-под рута:
$ lsmod > after.txt
(просто lsmod выведет информацию на экран). А потом, после перезагрузки, сделай ` lsmod > before.txt ` (в нормальном состоянии перечень подгруженных модулей всегда одинаков), и выложи мне содержимое этих файлов. Судя по твоему описанию проблемы после hibernate , в after.txt будет отсутствовать в частности модуль i915 . Потом мы аккуратно расскажем pm-hibernate, что такие-то модули нужно перед гибернацией выгружать, а после — подгружать заново, и по идее все будет хорошо.
Еще: когда у тебя появляется, как ты говоришь, окно «Ubuntu is running in low-graphics mode», просто переключись в соседний терминал (Ctrl+Alt+F2 или Ctrl+Alt+F3), залогинься под рутом, запусти ` lsmod > after.txt `, а потом перегрузись в нормальную систему и вышли эти 2 файла файлы + /var/log/syslog .
(3) Жду подтверждения что все работает или описание симптомов проблемы и содержимое before.txt, after.txt и /var/log/syslog .
на экране была куча надписей (ошибок), вот часть из них сфотографировал
Проблема с модулем watchdog, хотя по опыту скажу, что не обязательно с ним; остальное не информативно. Рассчитываю, что после перехода на uswsusp такого не будет.
Там есть пару проблем, не знаю насколько они влияют. Одно только уточнение: у тебя год в системе 2012 стоит?
Источник
