Система часто зависает

По ssh заходить не пробовал

А надо бы.

Ах да, случается это только в иксах, как в основных, так и запущенных отдельно

Драйвер видеокарты, может быть, стоит пинать.

Думал об этом, пробовал 2 разные версии. Попробовать откатить на более старые?

Пойду курить man

ssh имя_пьзователя@ip_компьютера

ssh user@192.168.0.101

В предыдущем dmesg после рестарта ничего?

Попробовать откатить на более старые?

Да, на 331.* можно попробовать, в более новых 100% есть глюки, во всяком случае с Optimus-ом.

Как посмотреть предыдущий dmesg?

По ssh подключился, буду пробовать добиться зависания и подключаться еще раз

К сожалению, добиться зависания не удалось. Сейчас нужно ехать. Дальнейшее развитие темы переносится на некоторое время.

Касательно nvidia блоба, после закрытия nvidia-settings в dmesg появляются строка

traps: nvidia-settings[2889] general protection ip:7f5448c69ad0 sp:7fff8f3e8068 error:0 in libpixbufloader-xpm.so[7f5448c68000+6000]

Погуглите linux netconsole и crash kernel.

journalctl -b -1 -k, если уже переехали на systemd

Ну вот, я вернулся. Обновил систему до тестинга, снова завис. Доступа по ssh во время зависания нет.

проверь тупо фс. олсо если трим врубал всякими discard, то выключи и без него погоняй, на многих ssd с кривой прошивкой он к плохому приводит

во всяком случае с Optimus-ом

можно подробности, а то хочу обновиться.

Проблемы в разл. версиях package.mask, кт. у меня на 310M. Воспроизводится с трудом, иногда на 2-ой день. Баг с бесконечной записью в лог вообще может среди недели проявиться. Также можно поймать глюк, выполняя while [ 1 ]; do primus some_command; done где-нибудь на 1000-чной итерации, что модуль выгрузить нельзя даже rmmod. Лично мне это критично, поэтому сижу на 331.89. Багрепортить времени не хватает.

благодарю, особенно не горит. тогда на 331 посижу.

fsck прогонял. На разделе с системой ошибок не было. В /home были, на счет /var не помню, вроде тоже были.

Ок, discard уберу, оставлю только noatime

оставлю noatime

всё таки наркоман. Но от noatime хоть такого уж явного вреда нет

Поставил блоб из репозитория 340.24, проблема никуда не делась.

Будем копать дальше

Прогнал memtest86+ - прошел без ошибок

Перегрев процессора/видеокарты?

Где вывод dmesg в промежуток до и после проишествия?

dmesg в промежуток до и после проишествия

и что, по твоему, это покажет

Проблемы с оборудованием в большинстве случаев дают знать о себе в dmesg и зачастую даже до возникновения заметным проблем в эксплуатации. В идеале, нужен и вывод dmesg сразу после загрузки. Правда, конечно если у него там проблемы с питанием, то ничего не будет в dmesg, с перегревом уже как повезет. Кстати, желательно отключить в bios/efi критическую температуру отключения процессора, если такая стоит.

Мож есть смьісл дополнительно форвардить все логи на другую машину? Вдруг там чтото интересное вспльівет

Можно попробовать. Но опять же он не уточнил как зависает, продолжает ли к примеру играть музыка, если процесс rsyslog будет работать, то почему бы и нет. Но опять же если что-то с ssd, скажем flush, то система бы у него все равно бы вскоре «развисла» и локально в dmesg бы он все прочитал.

Переустанови дебиан.

покажи свои cflags. где-то видел твой трэш с -flto -O3 для всей системы и откючением его для валящихся пакетов

Перегрев процессора/видеокарты?

Нет, холодные

Выхлоп по свежезагруженной машине после проишествия:

http://pastebin.com/tWiBQdm5

Обнови антивирусную программу.

Покажи что до перезагрузки. И убери «nomodeset nouveau.modeset=0» с /etc/default/grub, после не забудь сделать 'update-grub2'

А как я узнаю, что до перезагрузки, если система висит мертвым грузом? nomodeset убрал

/var/log/dmesg*

предыдущий же будет dmesg.0, так?

Скорей всего нет. По времени нужно смотреть. Лучше найди тот участок когда было зависание, и вот все что в этом промежутке и раньше составляет интерес. Разрыв увидеть достаточно легко, даже в случае если неправильно стоит время. Просто ищешь участок до перезагрузки.

-O3 тебе приснилось, -flto не для всей системы, вся информация в том же профиле оверлея, по той же ссылке.

Ничего интересного в dmesg* не нашел, все заканчиваются +- одним и тем же - поднятием сети

flto не для всей системы

оно приводит к косякам в рантайме, несмотря на то, что пишут обратное

например какие-то косяки с konsole и dbus

Друг, спасибо, пробовал всю систему и без flto, когда думал, что из-за этого проблема с Thunar. Оказалось, что баг в сочетании Thunar+Awesome. Других проблем не замечено. В момент, когда пробовал собрать -O2 без к-л флагов, один фиг, баг с nVidia не исчез. Не думаю, что дело в этом.

на телефоне/другом компе по SSH:

tail -f /var/log/messages

и ждать пока не зависнет вновь

Сейчас придут правильно обученные люди и объяснят, что дебиан не может зависать.

Эпопея продолжается. Откат к версии дров 331.89 не помог. Буду пробовать более старые.

у него аппаратный баг, очевидно же. или по твоему дебиан должен работать со сгоревшим компонентами или отключеным от сети шнуром?

Индикатор ЖД во время зависания чего кажет?

Ничего не кажет, но индикатор передачи данных на роутере еще некоторое время моргает.

Ну если не горит и система на Alt+SysRq+B (если kernel.sysrq включён) не реагирует — знач, паника ядра.

а включен ли он по умолчанию в дебиане?