Bug 25357

С ядром 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>.
Добавьте его и перегенерите конфигурацию загрузчика.
Я проверил, при его отсутствии перезагружаемся, что, собственно и
является нормальным поведением, т.к. ядро не знает, куда класть образ
памяти.
Если не поможет, повесьте другую багу.