В процессе попытки решить проблему со ждущим режимом, пришёл к выводу, что мне надо попробовать использовать TRACE_RESUME, чтобы отловить этот глюк. Нашёл упоминание об этом в этой теме на лоре, где тоже обсуждалась проблема со ждущим режимом.
Вот здесь описывается его применение. Не знаю, поможет ли это мне, но попытаться можно.
Похоже что надо собрать ядро с поддержкой TRACE_RESUME, как упоминалось той теме.

По ссылке, приведённой выше, написано
- enable PM_DEBUG, and PM_TRACE
Ну в общем, вот что я делал:
Взял пакет linux c ABS. Если я всё правильно понял, надо отредактировать файл config.x86_64 (для 64-битной системы).
В конфиге присутствовала строка CONFIG_PM_DEBUG=y. Я добавил ещё строку CONFIG_PM_TRACE=y, подправил название пакета в PKGBUILD и попробовал собрать и загрузиться с полученным ядром.
В системе должен по идее появиться файл /sys/power/pm_trace. Его как не было, так и с вновь собранным ядром нет.
Что-то я видимо не то делаю. Подскажите, как же это всё-таки правильно сделать?
minoshi
И у всех пакетов поле “установленная версия” заполнено ? Пробуем версию 2.10 отсюда, к себе на сайт пока не выкладывал
У всех, кроме пакетов из AUR. У них установленная версия не пишется вообще
Новая версия воспринимает все пакеты, как уже установленные. В поле “установленная версия” дублируется информация из “доступная версия”, и все пакеты отображаются в фильтре “установленные”
Кажется, поторопился я сказать, что в убунте всё работает. Недостаточно много видно я там ждущий режим включал, когда проверял. В общем, там тоже есть этот баг, так что на убунту надежды нет.
Остаётся надеяться на этот TRACE_RESUME.
Тоже безрезультатно.
В убунте такого нет. Вот опции из убунты:
linux	/boot/vmlinuz-2.6.38-8-generic root=UUID=3580e262-ef35-43dc-b62c-15f701526073 ro   quiet splash vt.handoff=7

Нашёл тут идентичную моей проблему (тоже арч, каталист и те же симптомы). Решения для себя я там правда не нашёл.
В той теме говорят, что это скорее всего связано с загруженными модулями.
Там что-то писали про TRACE_RESUME, надо будет посмотреть по поводу того, что это и с чем его едят.
И ещё можно попробовать сравнить lsmod в убунте с lsmod в арче. Попробую, отпишусь.
minoshi
А какие настройки Вам нужно сохранять?
Ну вообще имеет смысл сохранять всё, что есть в Settings → Other
Я, например, если хочу что-то удалить, в большинстве случаев использую параметры -Rnsc, каждый раз лезть в настройки для установки этих параметров не очень хочется.
Хотя ещё лучше сделать эти параметры параметрами по умолчанию, но перед каждой установкой/удалением дать возможность их изменить. И делать не комбинации из разных параметров (как pacman -Rsc), а сделать отдельный чекбокс для каждого параметра в пакмане/йогурте, примерно так:

RiD
А можно как-то подробнее описать этап, на котором виснет?
Вначале вроде бы успешно уходит в suspend, но когда пытаюсь включить, экран не загорается, звук не появляется, ни на что не реагирует, и по видимому начинает грузить процессор чем-то, так как через несколько секунд кулер начинает работать сильнее.
Зависания происходят и если суспендиться из иксов, и из консоли через pm-suspend (независимо от того, запущены ли иксы).

Ещё некоторые особенности суспенда из консоли. Если засуспендиться из консоли (при запущенных иксах), то при включении экран не включается вообще, включается только после перехода в иксы, а если вернуться в консоль, то там только серый фон (если что-то набрать, то оно нормально отображается, и после команды clear всё восстанавливается)
Если засуспендиться, когда иксы не запущены, тоже экран не загорается при включении, включается при запуске исков, но если после этого переключиться на консоль, то там будет только чёрный фон и вообще отображаться при ничего не будет.
Впрочем, может быть это отношения к сабжу и не имеет.

RiD
Про фреймбуфер пишет арч вики, кстати. Предлагает его отключить, добавив vga=0(или gfxpayload=text) к опциям загрузки ядра.
С этого предлагаю начать.
Это не помогает, а вообще, как я понял, фреймбуфер и не включается по умолчанию (изображения туксов при включении в консоли нет, они вроде как при фреймбуфере должны появляться)

RiD
2) С политикой процессора

Далее предлагалось предварительно переключаться на performance или powersave перед suspend.
Имеется ввиду политика частоты процессора, устанавливаемая через cpufrequtils? Попробовал, и с performance, и с powersave зависания тоже случаются.

RiD
И отключать usb.
А что имеется ввиду под “отключать”? Зависает не зависимо от того, подключено ли что-то по usb. Или модули какие-то выгрузить?
Правда ещё встроенные устройства есть. Вот вывод lsusb при отсутствии подключенных устройств:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 05c8:0403 Cheng Uei Precision Industry Co., Ltd (Foxlink) Webcam
Bus 002 Device 003: ID 148f:1000 Ralink Technology, Corp.

Ещё вот тут я кое-что находил про суспенд с каталистом
On T60-20076RG (Core2Duo 2GHz, ATI X1400) with OpenSUSE 11.1 and fglrx 8-12 the following had to be done to get suspend to RAM always resume:
Add S2RAM_QUIRKS_SOURCE=“s2ram” to file /etc/pm/config.d/config
Create an executable script /etc/pm/sleep.d/00text containing:
#!/bin/bash

case “$1” in
hibernate|suspend)
/bin/chvt 1
;;
thaw|resume)
/bin/chvt 7
;;
esac
Я попробовал так сделать на всякий случай (заменив /bin/chvt на /usr/bin/chvt. Что означает S2RAM_QUIRKS_SOURCE=“s2ram” не знаю), не помогло тоже. Впрочем, неудивительно, раз зависает и из консоли.
Супер! За хоткеи отдельное спасибо.

Небольшие замечания по поводу работы с yaourt. При сборке пакета из aur задаёт вопрос “Continue?”, но нажатие кнопки yes приводит к вызову редактирования PKGBUILD, то есть вопрос в данном случае некорректен. И почему-то при нажатии yes редактор вызывается два раза.
Можно добавить ещё опцию, чтобы при вопросах о редактировании PKGBUILD он автоматически отвечал yes (или no).

А сохранение настроек планируется?
Это для hibernation, с ним я вроде пока проблем не заметил. Правда я им раньше обычно не пользовался никогда.
Глючит suspend to RAM.
Можно в принципе начать использовать hibernation вместо suspend, но просто это намного медленней.

А нет никаких идей, почему же в убунте всё работает? Если что-то работает в одном дистрибутиве, теоретически ведь можно заставить это работать и в другом, в частности, в любимом арчике (наверное?)
Не так давно приобрёл себе ноут HP ProBook 4720s (с видеокартой ATI Radeon HD 6370M)
Вроде всё настроил, вроде всё работает. Но потом понял, что ждущий режим работает нестабильно. Не всегда выходит из него. То есть тут как повезёт, может девять раз выйти нормально, а на десятый раз зависнуть при попытке выхода. А может и с первого или второго раза отказаться выходить из него.
Пытался найти решение в гугле и вики, так и не нашёл, но как выяснилось экспериментальным путём, дело в драйвере catalyst. C xf86-video-ati всё работает нормально.
Решил попробовать посмотреть, как всё работает в “готовых упакованных” дистрибутивах. В Chakra Project оказалось всё так же, как у меня в арче. В Ubuntu всё работает нормально, даже с каталистом. В ArchBang работает нормально, до тех пот, пока не поставишь сatalyst.
Попробовал скопировать себе в арч xorg.conf из Ubuntu, с ним иксы не завелись. Что ещё придумать, не знаю.
Может кто-нибудь что-нибудь посоветовать?

PS. Использовать свободный драйвер не предлагайте, с ним моя карточка пока что ещё плохо работает.