Bug 29685

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/