Обновил по случаю ядро до 2.6.38-std-def-alt1 и обнаружил, что ноут перестал просыпаться после pm-hibernate. Несколько перезагрузок показали, что дело именно в ядре, т.к. с 2.6.37-std-def-alt1 засыпает и просыпается нормально, но после 2.6.38 перестает работать и с 2.6.37. Последние слова перед глухим зависанием: PM: Loading and decompressing image data (xxxx pages) ... done PM: Read xxx kbytes in x.xx seconds (xx MB/s) Suspending console(s) (use no_console_suspend to debug)
С ядром 2.6.38-un-def-alt2 тоже наглухо виснет. Как это хозяйство продиагностировать?
А вот на 2.6.38-pure-emerald-alt9 заснул и проснулся!
(В ответ на комментарий №0) > Обновил по случаю ядро до 2.6.38-std-def-alt1 и обнаружил, > что ноут перестал просыпаться после pm-hibernate. > Несколько перезагрузок показали, что дело именно в ядре, > т.к. с 2.6.37-std-def-alt1 засыпает и просыпается нормально, > но после 2.6.38 перестает работать и с 2.6.37. > > Последние слова перед глухим зависанием: > > PM: Loading and decompressing image data (xxxx pages) ... done > PM: Read xxx kbytes in x.xx seconds (xx MB/s) > Suspending console(s) (use no_console_suspend to debug) У меня ситуация с точностью до наоборот. Поблема существовала с std-def > 2.6.32 и пропала на 2.6.38.
(В ответ на комментарий №3) > Поблема существовала с std-def > 2.6.32 и пропала на > 2.6.38. А можете попробовать pure-emerald?
(В ответ на комментарий №4) > (В ответ на комментарий №3) > > Поблема существовала с std-def > 2.6.32 и пропала на > > 2.6.38. > > А можете попробовать pure-emerald? Пробовал, еще до std-def-2.6.38 работало.
Возможно, это: git://git./linux/kernel/git/rafael/suspend-2.6 Есть в pure-emerald и в 2.6.39-rc1
(В ответ на комментарий №6) > Возможно, это: > git://git./linux/kernel/git/rafael/suspend-2.6 > Есть в pure-emerald и в 2.6.39-rc1 Возможно. Просто сейчас осваивать сборку ядер нет возможности. Установил 2.6.38-std-def-alt2, так же не просыпается.
Похоже, что это сломано в апстриме. Пробовал собирать 2.6.39-pure-emerald-alt1.rc2.1 из гита товарища gns@ - результат был также отрицательный, а в 2.6.39-pure-emerald-alt1.rc3 уже починено.
(В ответ на комментарий №8) > Похоже, что это сломано в апстриме. > Пробовал собирать 2.6.39-pure-emerald-alt1.rc2.1 из гита товарища gns@ - > результат был также отрицательный, > а в 2.6.39-pure-emerald-alt1.rc3 уже починено. Вопрос в том, где это починено: в ванильном 2.6.39 или патчах pure-emerld.
(В ответ на комментарий №9) > (В ответ на комментарий №8) > > Похоже, что это сломано в апстриме. > > Пробовал собирать 2.6.39-pure-emerald-alt1.rc2.1 из гита товарища gns@ - > > результат был также отрицательный, > > а в 2.6.39-pure-emerald-alt1.rc3 уже починено. > > Вопрос в том, где это починено: в ванильном 2.6.39 или патчах pure-emerld. Думаю, что это следующее изменение: https://lkml.org/lkml/2011/4/6/340
(В ответ на комментарий №10) > (В ответ на комментарий №9) > > (В ответ на комментарий №8) > > > Похоже, что это сломано в апстриме. > > > Пробовал собирать 2.6.39-pure-emerald-alt1.rc2.1 из гита товарища gns@ - > > > результат был также отрицательный, > > > а в 2.6.39-pure-emerald-alt1.rc3 уже починено. > > > > Вопрос в том, где это починено: в ванильном 2.6.39 или патчах pure-emerld. > > Думаю, что это следующее изменение: > https://lkml.org/lkml/2011/4/6/340 Да, там длинная дискуссия: http://comments.gmane.org/gmane.linux.kernel/1121281
(In reply to comment #9) > (В ответ на комментарий №8) > > Похоже, что это сломано в апстриме. > > Пробовал собирать 2.6.39-pure-emerald-alt1.rc2.1 из гита товарища gns@ - > > результат был также отрицательный, > > а в 2.6.39-pure-emerald-alt1.rc3 уже починено. > > Вопрос в том, где это починено: в ванильном 2.6.39 или патчах pure-emerld. pure-emerald неванильный ровно на fs/aufs/ и, исторически, tp_smapi.
Ха, ну вот: http://git.altlinux.org/people/boyarsh/packages/?p=kernel-image.git;a=shortlog;h=cfd4cd745a5e1243ac87a28c69c13c3be3884283 2011-03-27 Yinghai Lu x86: Cleanup highmap after brk is concluded std-def alt2 - это .38.2, а pure-emerald 2.6.38-alt9 - .38 и там этого ешё нет.
(В ответ на комментарий №8) > Похоже, что это сломано в апстриме. > Пробовал собирать 2.6.39-pure-emerald-alt1.rc2.1 из гита товарища gns@ - > результат был также отрицательный, > а в 2.6.39-pure-emerald-alt1.rc3 уже починено. Что касается 2.6.39-pure-emerald-alt1.rc3 и ранних. Как не работало в ранних так и не работает suspend в ядре, да и в иных тоже. Выражается се в том, что по выполнению команды заснуть комп таки засыпает, но вот обратно уже (на команду: эй, проснись), уходит на перезагрузку. Тоже самое происходит, когда я пытаюсь сотворить hibernate. Это вообще говоря есть критический клоп.
Вы пробовали std-def-2.6.38-alt3? Считается, что в нем это должно быть исправлено. И вы уверены, что попробовали именно pure-emerald-alt1.rc3, а не более раннее? :)
у меня на std-def-2.6.38-alt3 просыпается и засыпает на диск нормально.
Спасибо, работает.
(В ответ на комментарий №15) > Вы пробовали sstd-def-2.6.38-alt3? Считается, что в нем это должно быть > исправлено. > И вы уверены, что попробовали именно pure-emerald-alt1.rc3, а не более раннее? > :) Попробовал-таки наконец 2.6.38-std-def-alt3 и 2.6.39-pure-emerald-alt1.rc5. В ждущий режим засыпают отлично, однако, когда начинают просыпаться уходят на перезагрузку. Так что проблема ещё не решена.
Что за железо, на котором уходит в перезагрузку ? BIOS последний ?
Created attachment 4913 [details] HWInfo log
(В ответ на комментарий №19) > Что за железо, на котором уходит в перезагрузку ? BIOS последний ? С версии 2.6.30 ядра, на котором всё работало, ничего в не менял и железо ни биос.
Дык эта, fixed же.
(В ответ на комментарий №22) > Дык эта, fixed же. Ну у вас возможно поправлен, а у меня нет. Перепопробовал на ядре 2.6.39-std-def-alt2. плод такой же, во время просыпания комп уходит на перезагрузку.
(В ответ на комментарий №23) > Ну у вас возможно поправлен, а у меня нет. Перепопробовал на ядре > 2.6.39-std-def-alt2. плод такой же, во время просыпания комп уходит на > перезагрузку. В приложенном Вами hwinfo.log в строке с параметрами запуска ядра я не увидел параметр resume=<имя устройства swap>. Добавьте его и перегенерите конфигурацию загрузчика. Я проверил, при его отсутствии перезагружаемся, что, собственно и является нормальным поведением, т.к. ядро не знает, куда класть образ памяти. Если не поможет, повесьте другую багу.
