Created attachment 6019 [details] dmesg Сабж собсно: не работает suspend-to-ram в altlinux-p7-sysv-tde-20131225-i586.iso При попытке Меню TDE => Завершить сеанс => Приостановить компьютер уход в Suspend-To-Ram выполняется, компьютер в STR, кнопка питания мигает. Но при попытке вывести компьютер из STR, на мониторе чёрный экран и ожидание, ощущение будто отрабатывается panic=30, после чего компьютер как по reset уходит в перезагрузку. Эта же ситуация и с hibernate-script pm-utils От ядра не зависит. Ситуация и с led-ws, и с std-pae, и с std-def одна и та же. В сборке от 20131104 STR работал через pm-utils и не работало через меню TDE.
Created attachment 6020 [details] hibernate.log
Created attachment 6021 [details] kdm.log
Created attachment 6022 [details] lastlog
Created attachment 6023 [details] messages
Created attachment 6024 [details] Xorg.0.log
Прошлой ночью прочитав про 'На ядро' в http://lists.altlinux.org/pipermail/community/2014-February/681671.html обновил систему через apt-get dist-upgrade update-kernel -t std-def update-kernel -t std-pae с обновлением этих ядер до 3.10.29. Баг исчез. Система нормально выходит из спячек STR и STD с обоими ядрами. И при использовании опций меню TDE и при использовании pm-utils всё нормально. Перегрузил систему без правки конфигов в 'runlevel 2' с led-ws которое у нас в бранче p7 в последнем 3.4.75-led-ws. Отправил в спячку, в память через # pm-suspend Вышел из спячки. Индикаторы не мигают. Чёрный экран. На экране ничего и нигде. Перезагрузка только через SysRq[s+u+b] Требуется обновление ядра в бранче p7 led-ws до версии 3.10.29?
Втащил из Сизифа led-ws 3.10.29 с загрузкой в 'runlevel 2', ситуация та же: тот же чёрный экран с последующим SysRq
(In reply to comment #7) > Втащил из Сизифа led-ws 3.10.29 с загрузкой в 'runlevel 2', ситуация та же: > тот же чёрный экран с последующим SysRq Гм. Ну я могу собрать с std-def, конечно -- но тогда i586 iso опять вылезет за 700M и будем искать, что ещё выкинуть (мегабайт на 20--30 сжатыми, помнится). Давайте Вы как активный пользователь подумаете и определитесь, моё-то дело маленькое -- сообразить, чтоб людям было лучше :-)
*** Bug 29824 has been marked as a duplicate of this bug. ***
Словил зависимость краха при выходе из suspend-to-ram. С этой связкой компьютер нормально выходит из suspend-to-ram: $ uname -r 3.4.80-led-ws-alt0.M70P.1 $ lspci -k|tail -n 15|head -n 3 01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GTS] (rev a1) Subsystem: Micro-Star International Co., Ltd. Device 0891 Kernel driver in use: nvidia $ cat /var/log/Xorg.0.log|grep "NVIDIA GLX" [ 17.781] (II) NVIDIA GLX Module 331.38 Wed Jan 8 19:14:22 PST 2014 $ rpm -qa|grep led-ws|grep drm kernel-modules-drm-led-ws-3.4.80-alt0.M70P.1 kernel-modules-drm-led-ws-3.4.75-alt0.M70P.1 А с этой: $ uname -r 3.4.80-led-ws-alt0.M70P.1 $ lspci -k|tail -n 15|head -n 3 01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GTS] (rev a1) Subsystem: Micro-Star International Co., Ltd. Device 0891 Kernel driver in use: nouveau Крах ядра (мигание индикаторов) panic=30 reboot Причём если подсунуть моему std-pae драйвер nouveau, то ситуация та же: крах ядра panic=30 (auto)reboot А с драйвером nvidia исключительно нормально и опционально и через pm-utils. И с led-ws и с std-pae.
А если std-def / nouveau ? Очень не хочется тянуть драйвер nvidia
То же самое. С этим: $ uname -r 3.10.29-std-def-alt1 $ lspci -k|tail -n 15|head -n 3 01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GTS] (rev a1) Subsystem: Micro-Star International Co., Ltd. Device 0891 Kernel driver in use: nouveau Крашится-выжидание-ребут: Крах ядра (мигание индикаторов) panic=30 reboot А с этой связкой нормально выходит из suspend-to-ram, - и через меню и через pm-utils: $ uname -r 3.10.29-std-def-alt1 $ lspci -k|tail -n 15|head -n 3 01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GTS] (rev a1) Subsystem: Micro-Star International Co., Ltd. Device 0891 Kernel driver in use: nvidia $ glxinfo |grep 'OpenGL version str' OpenGL version string: 3.3.0 NVIDIA 331.38 Так-то ядра с nouveau работают, проблем нет. Проблема только с выходом из спящего, если поднят драйвер nouveau. И главное увидеть ничего нельзя - экран на всех виртуальных терминалах чёрный. Даже если не ждать panic=30, а через SysRq, отследить Att+SysRq+s Att+SysRq+u Att+SysRq+b что происходит и выполнено ли, можно только по индикации активности HDD. Т.е. вслепую.
Коллеги, важно выяснить, наблюдается ли эта бага: -- только при sysv -- только в tde -- только с nouveau ?
(In reply to comment #13) > Коллеги, важно выяснить, наблюдается ли эта бага: +1 Также есть мысль, что пытаться вылизать образ для опытных пользователей до блеска -- задача, которая требует активного участия таковых в форме патчей. Соответственно я целюсь на решение задачи минимизации времени и сил на доводку при установке, но обнулить их вряд ли получится. Т.е. поставить драйвер nvidia и/или ядро и/или sdparm всё же предлагается самостоятельно по мере надобности. Если интерес к стартеркиту будет устойчивый и активный, то можно попытаться сделать из него community-дистрибутив и соответственно вылизывать всеми силами.
Притащил 3.10.32 std-def. Всё также крашится и логов не оставляет в ошибках. Втащил ядро: 3.13.5-un-def-alt1 Вот, уже что-то отвечает. 20:03 - отправлено в спячку 20:04 - будилось из спячки /var/log/kernel/errors (временная вырезка из лога): Feb 27 19:41:08 comp-c2d kernel: [ 2606.122737] nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout Feb 27 20:04:20 comp-c2d kernel: [ 1247.482016] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000000 FAULT at 0x00fd94 Feb 27 20:04:20 comp-c2d kernel: [ 1247.482415] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000000 FAULT at 0x103d94 Feb 27 20:04:20 comp-c2d kernel: [ 1247.492001] nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout Feb 27 20:04:20 comp-c2d kernel: [ 1251.078999] nouveau E[ VM][0000:01:00.0] vm flush timeout: engine 10 Feb 27 20:04:20 comp-c2d kernel: [ 1251.082949] nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout Feb 27 20:04:20 comp-c2d kernel: [ 1254.273819] nouveau E[ PDISP][0000:01:00.0] chid 1 mthd 0x0080 data 0x00000000 0x000b5080 Feb 27 20:04:20 comp-c2d kernel: [ 1254.680614] nouveau E[ VM][0000:01:00.0] vm flush timeout: engine 10 Feb 27 20:04:20 comp-c2d kernel: [ 1255.384005] nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout Feb 27 20:04:22 comp-c2d kernel: [ 1257.310550] nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout
Created attachment 6049 [details] log/kernel/errors
Created attachment 6050 [details] log/kernel/info
Created attachment 6051 [details] log/kernel/warnings
Created attachment 6052 [details] log/syslog/messages
Created attachment 6053 [details] log/pm-suspend.log
Временные вырезки из логов (пять штук выше): 3.13.5-un-def-alt1 20:03 - отправлено в спячку 20:04 - будилось из спячки
Слил последний свежий стартеркит с системдой altlinux-p7-kde4-20140301-i586.iso в котором nouveau в коробке и поставил на второй hdd. Ядро там 3.10.32. Отправил в 'Уснуть в память'. Сказал проснись. Результат тот же: паника ядра. Загрузившись в p7-sysv-tde увидел, что errors в p7-kde4(starterkit) чист. Т.е. ядро падает так быстро при выходе из спячки, что даже не успевает сообщить об этом в errors. Пару-тройку дней тому, грепал гугл выбросами из errors. Поэтому результат уже ожидал ещё до полного сливания синком образа. Установка чтобы увидеть, скорее для собственного успокоения, что всё так же благополучно рушится. И чтобы наверняка отсечь возможно побочное. ИМХО: жду свежее ядро, что-то от 3.14 и выше. А там будем посмотреть.
Видимо, в рамках образа (т.е. изменением ядра на std-def и/или драйвера с nouveau на nvidia) это не решается. Предлагаю объезжать на конкретном хосте, пока с драйвером не прояснится.
(В ответ на комментарий №22) > ИМХО: жду свежее ядро, что-то от 3.14 и выше. > А там будем посмотреть. Просьба проверить на мартовских, там 3.14.35 (могу выложить альфу летних в виде altlinux-p7-sysv-tde-20150601-x86_64.iso или i586). У меня STR работает.
ping
...ну или на 20150905, пока не 20150912: http://nightly.altlinux.org/p7/beta/
