Зависает ARCH

Workout
Флэш вешает систему,откатывайтесь.
Уточняйте - у вас вешает.

Как вариант, если включено аппаратное ускорение видео - отключите.
Подниму эту старую тему. У меня похожая ситуация, но решения не помогли.

Кратко: неожиданно зависает комп. Клава не откликается даже на Alt + SysRq + ... Но курсор мыши двигается. Если зависает при просмотре фильма/музыку в VLC, или ролик на ютубе, звук не прерывается. По крайней мере 15 минут, дольше не ждал.

Что делал: мерил параметры загрузки проца и памяти, температуру. За секунду до зависания ничего сверхестественного не происходит.

Месяц назад поменял память с 4 Гб на 16 (2х8) Гб. Винт поменял на SSD. Мать, проц i5-2310 и видео GTX 550 Ti остались прежние. Арч единственная система. Закономерности от списка работающих программ не выявил. Может зависнуть и при рендере в блендере и при простое. В последние два раза было при просмотре ролика на ютубе.

cat /proc/sys/kernel/sysrq = 1, реакции на комбинации Alt + SysRq или Ctrl + Alt + F1-12 нет.

В логах Xorg ничего, в journalctl -b перед зависанием только добрые слова, варнингов, алертов, эрроров нет.

Помогите!

UPD: видеокарта
01:00.0 VGA compatible controller: NVIDIA Corporation GF116 [GeForce GTX 550 Ti] (rev a1)
	Subsystem: ASUSTeK Computer Inc. GF116 [GeForce GTX 550 Ti]
	Kernel driver in use: nouveau
Начни с теста ОЗУ и проверь напряжения блока питания.
abc
Клава не откликается даже на Alt + SysRq + … Но курсор мыши двигается.
Вот это странно - если уж зависает, то зависает полностью.
В части SysRq (Alt+SysRq+<>) - как пишут
Клавиша SysRq - единственная прямая связь с ядром, которая работает всегда, если работает ядро, так как соответствующие комбинации напрямую перехватываются ядром и соответствующий код является частью драйвера клавиатуры
И если уж комбинации SysRq не работают, то проблема в ядре, что маловероятно, а если работают, то причина скорее всего в железе или, с меньшей долей вероятности, в системе.
Проверь работает ли комбинация в нормальной системе, для чего запусти команду journalctl -f и набери комбинацию Alt+SysRq+h. Должен получить следующий вывод
arch kernel: sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash© terminate-all-tasks(e) … и так далее …
В следующий раз в зависшей системе набери комбинацию Alt + SysRq и и с интервалом в 2-3 секунды нажми последовательно: R E I S U B
Если работает, то проблема скорее всего в железе или что то с системой - и нужно будет анализировать дальше.
abc
Месяц назад поменял память с 4 Гб на 16 (2х8) Гб. Винт поменял на SSD.
Проблемы начались после всех замен или были и до этого?
Если после, то разумно предположить, что причина обусловлена заменой и, вероятнее всего, заменой памяти - или попалась память с деффектом или новая память имеет немного другие параметры. Все это, конечно предположения, но другой информации пока нет.
Можно для начала проанализировать параметры памяти, поработать поочередно с каждой планкой памяти отдельно (а не обе сразу), плюс к этому можно потестить эти планки памяти, как советует RusWolf.
То, что курсор все равно двигается меня тоже удивляет. Первым делом думал на проблемы с икс сервером и видеокартой.

Утром подцепил проводную клавиатуру, теперь Alt + SysRq работает, когда зависает. На работающей системе с беспроводной клавы тоже работает. Видимо в момент зависания связь у беспроводной теряется.

Проблемы были и до замены памяти и диска. Замена была плановой. После замены ОС переустанавливал. До переустановки тоже зависал. Поэтому, я думаю, проблему в арче можно исключить? Хотя.. Летом второй системой стояла семерка для игр. На ней зависаний не было, WOT шла на настройках выше средней. Арч уже тогда зависал.

БП в порядке, выдает должное.

Сейчас качаю лайв сиди, попробую с флешки посидеть.
была такая-же история
Vadim
Установил openbox на Arch x64,при запуске через startx всё включается и работает.Если выйти из сеанса и запустить опять startx - серый экран без курсора,на кнопки не реагирует,REISUB не действует.
Снёс systemd ,установил openrc и всё стало нормально,почти два месяца всё работает вообще без глюков.Аж скучно.
systemd-глючная хрень.
Linux Forever!
abc
Видимо в момент зависания связь у беспроводной теряется.
Все понятно - не знал, что у тебя беспроводная клавиатура - с ней это вполне возможно.
Раз наблюдалось и до апгрейда и после переустановки системы, то наиболее вероятная причина это железо + драйвера (раз в винде все нормально).
Чтобы выяснить конкретного виновника, придется много посидеть и проанализировать (например, отключая поочередно не нужное, можно попробовать сменить драйвер на видеокарту). А вообще это довольно утомительная и неблагодарная работа.
Можно попробовать увеличить логирование (параметр загрузки debug), может что и напишет.
Вот если бы примерно знать момент зависания, можно было бы включить запись всех системных событий (sysdig), но это уж слишком большой объем логов (за несколько минуток набегает несколько сот мегабайт), хотя можно идти постепенно, применя фильтрацию, чтобы сократить объем логов. Но, повторюсь, это очень нудная работа и можно утонуть в этом объеме информации.
UPD - насколько я понял стандартный мониторинг здесь не годится
abc
мерил параметры загрузки проца и памяти, температуру. За секунду до зависания ничего сверхестественного не происходит.
Но можно попробовать посмотреть нестандартными утилитами, например, если нагрузка памяти и cpu в норме (плюс к этому в винде все нормально), но всеравно есть же виновник/процесс, который вешает систему и он должен себя как то проявить. Можно попробовать применить профилировщики, типа perf top - показывает в реальном времени какие функции/процессы в системе генерируют больше всего нагрузки. Привожу примерный вывод
  1,09%  libc-2.26.so                    [.] __strcmp_sse2_unaligned
   1,06%  firefox                         [.] malloc
   0,94%  libpthread-2.26.so              [.] __pthread_mutex_lock
   0,85%  firefox                         [.] free
   0,73%  perf                            [.] __hists__insert_output_entry
   0,69%  libc-2.26.so                    [.] __memmove_sse2_unaligned_erms
   0,67%  libpthread-2.26.so              [.] __pthread_mutex_unlock_usercnt  
Конечно, вероятность найти виновника небольшая, так как не понятно, захватит ли эта утилита информацию в момент зависания, но попробовать можно и это намного проще чем sysdig.
abc, а попробуй при следующем зависании набать комбинацию Alt + SysRq + f - вызывает oom_kill чтобы убить процессы, которые кушают много памяти
Выжди минут 5 и посмотри вернется ли система к нормальному состоянию.
Конечно, с большой долей вероятности что проблема не в памяти, но исключить/проверить нужно.
С лайв флешки Убунту за три часа не зависла, нагружал 4 ядра почти по 100%, из 16 Гб памяти больше половины забил. Перешел на арч, завис через пару минут.

Alt + SysRq + f не помог, ждал более 10 минут.
UPD: упустил один важный момент. На компьютере 3 пользователя. Один из них (не мой) грузится автологином без пароля. Есть несолько программ в автозапуске. Обычно я из закрываю и переключаюсь на свой аккаунт. Сейчас убрал автозапуск гимпа, вивальди и радио. Жду.
 
Зарегистрироваться или войдите чтобы оставить сообщение.