LINUX.ORG.RU

Беда с suspend'ом

 ,


0

1

Добрый вечер! После последнего обновления системы, мой ноутбук(Asus x201e) стал вести себя очень странно при погружении в suspend и обратно. Уже давно, я, используя systemd настроил кнопку питания на suspend, что бы лишний раз не открывать/закрывать крышку, так как большую часть времени я работаю с ним дома. После обновления системы, я обратил внимание что теперь переключение в ждущий режим занимает 5-6 секунд(раньше это происходило мгновенно).
С некоторой вероятностью, компьютер может вообще не погрузится в спящий режим, или зависнуть на минуту, или насовсем. То же самое может произойти и при его пробуждении. Как то раз, проснувшись посреди ночи я обнаружил что ноутбук самопроизвольно проснулся, на экране не было ничего, работала только подсветка. Так же и не было реакции на попытки переключится в tty2. И вот сейчас, придя домой, я обнаружил что ноутбук «спит», но уровень заряда акуумулятора составляет всего 4%, хотя когда я уходил, он был заряжен практически полностью.
Пробовал откатится на lts вертку ядра(3.14.39-1-lts), но ничего не изменилось.
Сейчас, после его «зависания» на минуту, нашел в dmesg следующее:

[25318.707811] Freezing of tasks failed after 20.009 seconds (1 tasks refusing to freeze, wq_busy=0):
[25318.707833] nfsv4.1-svc     D 0000000000000000     0  1697      2 0x00000000
[25318.707842]  ffff8800bf1b7d90 0000000000000046 ffff8800bf1b7cb0 ffff8800bf1acf00
[25318.707850]  00000000000131c0 ffff8800bf1b7fd8 00000000000131c0 ffff8800bf1acf00
[25318.707856]  ffffffffa0320c48 ffff8800782cea00 0000000000000000 ffffffffa03277c0
[25318.707862] Call Trace:
[25318.707913]  [<ffffffffa0320c48>] ? xprt_release+0x268/0x2f0 [sunrpc]
[25318.707933]  [<ffffffffa03277c0>] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
[25318.707950]  [<ffffffffa03273a0>] ? rpc_release_resources_task+0x30/0x40 [sunrpc]
[25318.707966]  [<ffffffffa032837d>] ? __rpc_execute+0x1dd/0x440 [sunrpc]
[25318.707977]  [<ffffffff8107835b>] ? lock_timer_base.isra.35+0x2b/0x50
[25318.707986]  [<ffffffff814ff719>] schedule+0x29/0x70
[25318.707993]  [<ffffffff814fe7cf>] schedule_timeout+0x12f/0x240
[25318.708001]  [<ffffffff81077a00>] ? ftrace_raw_event_tick_stop+0x200/0x200
[25318.708008]  [<ffffffff810b1597>] ? prepare_to_wait+0x57/0x90
[25318.708023]  [<ffffffffa099ccfa>] nfs41_callback_svc+0x1aa/0x1e0 [nfsv4]
[25318.708029]  [<ffffffff810b18f0>] ? __wake_up_sync+0x20/0x20
[25318.708041]  [<ffffffffa099cb50>] ? nfs4_callback_svc+0x60/0x60 [nfsv4]
[25318.708048]  [<ffffffff8108db38>] kthread+0xd8/0xf0
[25318.708055]  [<ffffffff8108da60>] ? kthread_create_on_node+0x1a0/0x1a0
[25318.708062]  [<ffffffff8150bf58>] ret_from_fork+0x58/0x90
[25318.708068]  [<ffffffff8108da60>] ? kthread_create_on_node+0x1a0/0x1a0

[25318.708089] Restarting kernel threads ... done.
[25318.708205] Restarting tasks ... done.
Даже не знаю, что там кроме ядра может отвечать за suspend системы? И при чем там nfsv4.1-svc? NFS шары у меня таки используются.

★★

Последнее исправление: cetjs2 (всего исправлений: 2)

NFS с саспендом — это, насколько я понимаю, прямой путь в боль и страдания. Как минимум сетевое подключение останавливается.

Я не в курсе, как работает NFS, но у тебя из dmesg следует, что один из процессов (ответственных за него) лочится в ядре. Попробуй перед саспендом отмонтировать NFS-шары, что ли.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Да, действительно, стоило отмонтировать шары, как все стало хорошо. Другое дело что те же самые проблемы меня посещали за пределами дома(когда шары не были доступны), и мне даже в голову не пришло отмонтировтаь их.
Теперь осталось выяснить, в чем причина что лочит саспенд.

shooter93 ★★
() автор топика
Ответ на: комментарий от intelfx

Странно, у меня таких проблем с NFS не было ни разу, хотя я NFS на железке не отмонтирую никогда, так как NFS-root. Ядро, правда, 3.10.

slapin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.