ATI Radeon HD 6370M + catalyst = нестабильная работа suspend
| mehanoid |
|
Темы:
28
Сообщения:
382
Участник с: 27 апреля 2010
|
Не так давно приобрёл себе ноут HP ProBook 4720s (с видеокартой ATI Radeon HD 6370M) Вроде всё настроил, вроде всё работает. Но потом понял, что ждущий режим работает нестабильно. Не всегда выходит из него. То есть тут как повезёт, может девять раз выйти нормально, а на десятый раз зависнуть при попытке выхода. А может и с первого или второго раза отказаться выходить из него. Пытался найти решение в гугле и вики, так и не нашёл, но как выяснилось экспериментальным путём, дело в драйвере catalyst. C xf86-video-ati всё работает нормально. Решил попробовать посмотреть, как всё работает в “готовых упакованных” дистрибутивах. В Chakra Project оказалось всё так же, как у меня в арче. В Ubuntu всё работает нормально, даже с каталистом. В ArchBang работает нормально, до тех пот, пока не поставишь сatalyst. Попробовал скопировать себе в арч xorg.conf из Ubuntu, с ним иксы не завелись. Что ещё придумать, не знаю. Может кто-нибудь что-нибудь посоветовать? PS. Использовать свободный драйвер не предлагайте, с ним моя карточка пока что ещё плохо работает. |
| RiD |
|
|
Темы:
30
Сообщения:
400
Участник с: 27 июня 2011
|
Как вариант: Попробовать в ядре указать дефолтный раздел, с которого восстанавливаться. Power managment and ACPI options -> Hibernation (aka ‘suspend to disk’) -> Default resume partition. Но вряд ли это поможет, как мне кажется.. |
| mehanoid |
|
|
Темы:
28
Сообщения:
382
Участник с: 27 апреля 2010
|
Это для hibernation, с ним я вроде пока проблем не заметил. Правда я им раньше обычно не пользовался никогда. Глючит suspend to RAM. Можно в принципе начать использовать hibernation вместо suspend, но просто это намного медленней. А нет никаких идей, почему же в убунте всё работает? Если что-то работает в одном дистрибутиве, теоретически ведь можно заставить это работать и в другом, в частности, в любимом арчике (наверное?) |
| RiD |
|
|
Темы:
30
Сообщения:
400
Участник с: 27 июня 2011
|
А можно как-то подробнее описать этап, на котором виснет? Бегло прогуглив английский интернет, я выделил три проблемы. 1) С фреймбуфером. 2) С политикой процессора 3) С usb и прочей подключенной ерундой Про фреймбуфер пишет арч вики, кстати. Предлагает его отключить, добавив vga=0(или gfxpayload=text) к опциям загрузки ядра. С этого предлагаю начать. Далее предлагалось предварительно переключаться на performance или powersave перед suspend. И отключать usb.. Это я к тому, что про манипуляции с xorg.conf практически ничего не встретилось.. Это конечно не аргумент, но я бы начал поиск с разницы в конфигах ядра. |
| mehanoid |
|
|
Темы:
28
Сообщения:
382
Участник с: 27 апреля 2010
|
RiDВначале вроде бы успешно уходит в suspend, но когда пытаюсь включить, экран не загорается, звук не появляется, ни на что не реагирует, и по видимому начинает грузить процессор чем-то, так как через несколько секунд кулер начинает работать сильнее. Зависания происходят и если суспендиться из иксов, и из консоли через pm-suspend (независимо от того, запущены ли иксы). Ещё некоторые особенности суспенда из консоли. Если засуспендиться из консоли (при запущенных иксах), то при включении экран не включается вообще, включается только после перехода в иксы, а если вернуться в консоль, то там только серый фон (если что-то набрать, то оно нормально отображается, и после команды clear всё восстанавливается) Если засуспендиться, когда иксы не запущены, тоже экран не загорается при включении, включается при запуске исков, но если после этого переключиться на консоль, то там будет только чёрный фон и вообще отображаться при ничего не будет. Впрочем, может быть это отношения к сабжу и не имеет. RiDЭто не помогает, а вообще, как я понял, фреймбуфер и не включается по умолчанию (изображения туксов при включении в консоли нет, они вроде как при фреймбуфере должны появляться) RiDИмеется ввиду политика частоты процессора, устанавливаемая через cpufrequtils? Попробовал, и с performance, и с powersave зависания тоже случаются. RiDА что имеется ввиду под “отключать”? Зависает не зависимо от того, подключено ли что-то по usb. Или модули какие-то выгрузить? Правда ещё встроенные устройства есть. Вот вывод lsusb при отсутствии подключенных устройств: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Ещё вот тут я кое-что находил про суспенд с каталистом 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:Я попробовал так сделать на всякий случай (заменив /bin/chvt на /usr/bin/chvt. Что означает S2RAM_QUIRKS_SOURCE=“s2ram” не знаю), не помогло тоже. Впрочем, неудивительно, раз зависает и из консоли. |
| RiD |
|
|
Темы:
30
Сообщения:
400
Участник с: 27 июня 2011
|
А hpet=disable тоже в груб, какой даст результат? Совет с английского убунту форума, хотя судя по гуглу “hpet=disable suspend ati” многим помогает. Кстати, интересно, есть ли эта опция в ядре убунту. Так как отключается она безболезненно.. |
| mehanoid |
|
|
Темы:
28
Сообщения:
382
Участник с: 27 апреля 2010
|
Тоже безрезультатно. В убунте такого нет. Вот опции из убунты: 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 в арче. Попробую, отпишусь. |
| mehanoid |
|
|
Темы:
28
Сообщения:
382
Участник с: 27 апреля 2010
|
Кажется, поторопился я сказать, что в убунте всё работает. Недостаточно много видно я там ждущий режим включал, когда проверял. В общем, там тоже есть этот баг, так что на убунту надежды нет. Остаётся надеяться на этот TRACE_RESUME. |
| mehanoid |
|
|
Темы:
28
Сообщения:
382
Участник с: 27 апреля 2010
|
Собрал я ядрышко с поддержкой TRACE_RESUME. Сделал, как тут написано. Команда “echo 1 > /sys/power/pm_trace” должна была включить режим отладки, позволяющий сохранить информацию о сбоящем модуле в лог в случае фейла при выходе из ждущего режима. Однако после этого режима ждущий режим начинает работать нормально. Странно. Если после этого сделать “echo 0 > /sys/power/pm_trace”, то зависать опять начинает. В общем, можно считать, наверное, что решение нашлось, правда какое-то кривое. Сбоящий модуль так я и не нашёл, и, видать, придётся пока посидеть на самосборном ядре. Может, потом с какими-нибудь апдейтами что-нибудь изменится. В любом случае большое спасибо за помощь. Буду рад, если кто-то предложит что-нибудь получше. |
| koshon |
|
|
Темы:
19
Сообщения:
102
Участник с: 15 августа 2009
|
Товарищи! Нет, не так.. соплеменники, имеющие у себя ATI. Я внесу сюда свою лепту. Она попроще решения mehanoid'а, но кто знает решит ли это проблему у всех… Ну вот долго ли, коротко, отходя от предисловия докладываю. Создается файл с произвольным названием в папке /etc/pm/sleep.d со следующим содержанием: HIBERNATE_RESUME_POST_VIDEO=yes SUSPEND_MODULES="fglrx" Замечание: я файл назвал так, на чем у меня заканчивался log-файл pm'а, а именно 99video. Возможно околотаким способом можно будет справиться и с др. модулями, но тут я уже хз что прописывать. Ну там есть еще 90alsa, но при просмотре его в текстовом отображает как бинарник. В целом все, кланяюсь. |