Зависание после ждущего режима

[RoDoN]

Вот логи и lsmod для загрузки с ядрами 3.4.14-pf и 3.14.5, ждущий нигде не работает
При попытке сохранения в каталог почему-то иксы на нетбуке не могут загрузиться, т.е. замирает на темном светящемся экране, курсор мыши не появляется, нажатие Ctrl+Alt+Backspace перегружает иксы и опять темный экран, сохраненку в файл попробую сделать позже.

З.Ы. На стационаре сохранение в каталог работает нормально.

[Pro]

давай попробуем btusb в черный список поместить
acer_wmi тоже под подозрением...

[RoDoN]

btusb и acer_wmi отправил в черный список, но ничего не изменилось , проверял на ядре 3.14.5

При попытке сохранения в каталог почему-то иксы на нетбуке не могут загрузиться

Разобрался, оказывается на разделе с системой 700...800 метров свободных из 20 Гб мало, т.к. ROX показывает 0 (3,2%), освободил еще 500 метров, ROX показал 260 Мб (5,8%) свободных и сохранение в каталог заработало нормально.

З.Ы. Я офигиваю от этой арифметики со свободным местом  .

[Pro]

фиг с ней с арифметикой, убирай модули из черного списка и пробуй параметры загрузки:
acpi_backlight=vendor acpi_osi=Linux acer_wmi.blacklist=yes

(последний параметр тоже acer_wmi в черный список добавит)

[RoDoN]

acpi_backlight=vendor acpi_osi=Linux acer_wmi.blacklist=yes

Чуда не произошло, при загрузке долго, т.е. несколько раз, ругалось на то, что для backlight нужен acer_wmi, потом ругался NM, висело минуту с обратным отсчетом времени, в конце-концов все-таки появился раб.стол, но около минуты не было реакции ни на мышь, ни на клаву, сеть через NM не запускается, хоть и видит две сети Wi-Fi, но не может подключиться. Из ждушего опять вышел через отбрасывание батарейки

(последний параметр тоже acer_wmi в черный список добавит)

Не добавило его в черный список, см. lsmod, а если добавить в /etc/modprobe.d, то тогда добавляет.

[Pro]

Предыдущие изменения отменить
Еще вариант:
в параметрах загрузки убрать quiet, усыплять из командной строки (pm-suspend или systemctl suspend) но предварительно
сделать echo "1" > /sys/power/pm_trace и смотреть логи на предмет ругани

[RoDoN]

Код

live@pra:~$ echo "1" > /sys/power/pm_trace
bash: /sys/power/pm_trace: Отказано в доступе
live@pra:~$ sudo echo "1" > /sys/power/pm_trace
bash: /sys/power/pm_trace: Отказано в доступе

[DdShurick]

sudo echo

[RoDoN]

Не работает, см.3-ю строчку

[Pro]

попробуй права поменять для pm_trace видимо на запись нету

[RoDoN]

Попробовал запускать в терминале:
1. pm-suspend
2. systemctl suspend
3. pm-suspend с параметрами --quirk-dpms-on --quirk-vbemode-restore --quirk-vbestate-restore
результат все тот же, плачевный.
Пробовал без иксов в консоли pm-suspend - тоже самое.

Посмотрел, а файла такого /sys/power/pm_trace у меня вообще нет и создать в ROX-е не дает.

[RoDoN]

Сравнил файлы pm-suspend.log, полученные при работе с ядрами 3.11.3-pf и 3.14.5 (они во вложении, я только для более удобного сравнения перестроил строки модулей по алфавиту), так вот заметил отличия:
с ядром 3.11.3-pf загружены mperf и pcspkr, которых нет при загрузке с 3.14.5:

Код

mperf                    707  1 acpi_cpufreq
pcspkr                  1020  0 

с ядром 3.14.5 загружены 6lowpan_iphc и gpio_sch, которых нет при загрузке с 3.14.53.11.3-pf:

Код

6lowpan_iphc            3420  1 bluetooth
gpio_sch                1804  0 

З.Ы. с ядром 3.11.3-pf ждущий режим работает, а с 3.14.5 - нет.

[Pro]

mperf исключен из ядра
pcspkr я отключил чтобы не пиликал лишний раз.

6lowpan_iphc это что-то для блютуса в любом случае проблема не в этих двух модулях.

[RoDoN]

УРРРААААА!!!!
Победил, во всяком случае для ядра 3.14.5 сейчас заработало как надо, а нужно было всего лишь отправить в blacklist модуль gpio_sch и все!

Интересно для чего нужен gpio_sch?

UPD: Проверил с ядром 3.14.4-pf3 - тоже все нормально работает  

[Pro]

поздравляю,
Say yes here to support GPIO interface on Intel Poulsbo SCH. The Intel SCH contains a total of 14 GPIO pins. Ten GPIOs are powered by the core power rail and are turned off during sleep modes (S3 and higher). The remaining four GPIOs are powered by the Intel SCH suspend power supply. These GPIOs remain active during S3. The suspend powered GPIOs can be used to wake the system from the Suspend-to-RAM state.