Система виснет редко, но метко

vasek	# 1 год, 8 месяцев назад (отредактировано 1 год, 8 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	slend3r ну вот никакая из комбинаций и не работала в том числе не работала и комбинация на перегрузку? - если да, то виснет ядро. Тогда можно добавить в файл /etc/sysctl.d/99-sysctl.conf параметр `kernel.panic=10` что заставит выполнить перегрузку после 10с в случае зависания ядра. ... заодно и проверится, виснет ли ядро. EDIT 1 - сейчас провел эксперимент: закоментировал параметр kernel.panic=10, перегрузился для верняка (иногда хоть и активируешь парамет в текущей загрузке, но у меня не всегда срабатывает) и отправил ядро в kernel panic комбинацией Alt+SysRq+c (можно и командой, но дольше писать) - система зависла, никакие комбинации не работают, выключение только через питание. Загрузился - в логах ни чего похожего не нашел. Вернул на место параметр kernel.panic=10. Если имеешь тоже самое, то похоже на панику ядра --- но вот от чего? - выяснить на раз-два не получится. Ошибки не исчезают с опытом - они просто умнеют

# 1 год, 8 месяцев назад (отредактировано 1 год, 8 месяцев назад)

Сообщения: 11320

Участник с: 17 февраля 2013

slend3r
ну вот никакая из комбинаций и не работала

в том числе не работала и комбинация на перегрузку? - если да, то виснет ядро. Тогда можно добавить в файл /etc/sysctl.d/99-sysctl.conf параметр

kernel.panic=10

что заставит выполнить перегрузку после 10с в случае зависания ядра. ... заодно и проверится, виснет ли ядро.

EDIT 1 - сейчас провел эксперимент: закоментировал параметр kernel.panic=10, перегрузился для верняка (иногда хоть и активируешь парамет в текущей загрузке, но у меня не всегда срабатывает) и отправил ядро в kernel panic комбинацией Alt+SysRq+c (можно и командой, но дольше писать) - система зависла, никакие комбинации не работают, выключение только через питание. Загрузился - в логах ни чего похожего не нашел. Вернул на место параметр kernel.panic=10.
Если имеешь тоже самое, то похоже на панику ядра --- но вот от чего? - выяснить на раз-два не получится.

Ошибки не исчезают с опытом - они просто умнеют

slend3r	# 1 год, 8 месяцев назад
Темы: 5 Сообщения: 36 Участник с: 14 сентября 2020	vasek в том числе не работала и комбинация на перегрузку? да, эта комбинация не работала, я про то и писал. Проверил мать, вздутых конденсаторов не обнаружил, все кабели вроде нормально подключены. По старой памяти прошёлся ластиком по оперативке. Обнаружил включенным тумблер ASUS EPU (это вроде что-то про уменьшение потребления энергии, но хрен знает насколько эффективная вещь), выключил его. Причём, помнится, что включал его я как раз летом от баловства. В биосе поставил все параметры на дефолтные. Будем посмотреть, спасибо за помощь.

slend3r

# 1 год, 8 месяцев назад

Темы: 5

Сообщения: 36

Участник с: 14 сентября 2020

vasek
в том числе не работала и комбинация на перегрузку?

да, эта комбинация не работала, я про то и писал.

Проверил мать, вздутых конденсаторов не обнаружил, все кабели вроде нормально подключены. По старой памяти прошёлся ластиком по оперативке. Обнаружил включенным тумблер ASUS EPU (это вроде что-то про уменьшение потребления энергии, но хрен знает насколько эффективная вещь), выключил его. Причём, помнится, что включал его я как раз летом от баловства.
В биосе поставил все параметры на дефолтные.
Будем посмотреть, спасибо за помощь.

vasek	# 1 год, 8 месяцев назад (отредактировано 1 год, 8 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	slend3r Будем посмотреть Фиксируй для себя хотя бы включение каких то приложений, после которых (может и не сразу) все зависает. Заодно и смотри - сработает ли автоматически перегрузка после зависона. Кстати, можешь проверить комбинацию (Alt+SysRq+c) и на нормальной системе, в смыле, работает ли эта комбинация вообще (с прописанным параметром kernel.panic=10), предварительно заверши все запущенные под собой приложения. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 1 год, 8 месяцев назад (отредактировано 1 год, 8 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

slend3r
Будем посмотреть

Фиксируй для себя хотя бы включение каких то приложений, после которых (может и не сразу) все зависает.
Заодно и смотри - сработает ли автоматически перегрузка после зависона.
Кстати, можешь проверить комбинацию (Alt+SysRq+c) и на нормальной системе, в смыле, работает ли эта комбинация вообще (с прописанным параметром kernel.panic=10), предварительно заверши все запущенные под собой приложения.

Ошибки не исчезают с опытом - они просто умнеют

vasek	# 1 год, 8 месяцев назад (отредактировано 1 год, 8 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	slend3r Проверил мать, вздутых конденсаторов не обнаружил, все кабели вроде нормально подключены. По старой памяти прошёлся ластиком по оперативке. Если причина в kernel panic (что еще нужно установить), то возможными причинами могут быть: - модули ядра (работают в одном адресном пространсве с ядром) - глючит какое то устройство, как правило также завязано на ядерный модуль - питание - память (нужно тестить и подольше) Обычно хорошо умеют делать анализ kernel panic разработчики - логов, как правило, практически нет, но есть механизм для анализа, но не так то просто это выполнить - во первых, нужно для этого иметь специалное ядро (как правило ставят два ядра) для получения дампа, а во вторых иметь специальные утилиты для анализа этого дампа. Так что этот способ довольно сложен и его можно отбросить. Есть более простой способ, но он и менее информативен - использование ramoops. Хотя он и прост, но требует определенных знаний, так что и это способ в принципе тоже можно отбросить. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 1 год, 8 месяцев назад (отредактировано 1 год, 8 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

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

Если причина в kernel panic (что еще нужно установить), то возможными причинами могут быть:
- модули ядра (работают в одном адресном пространсве с ядром)
- глючит какое то устройство, как правило также завязано на ядерный модуль
- питание
- память (нужно тестить и подольше)
Обычно хорошо умеют делать анализ kernel panic разработчики - логов, как правило, практически нет, но есть механизм для анализа, но не так то просто это выполнить - во первых, нужно для этого иметь специалное ядро (как правило ставят два ядра) для получения дампа, а во вторых иметь специальные утилиты для анализа этого дампа. Так что этот способ довольно сложен и его можно отбросить.
Есть более простой способ, но он и менее информативен - использование ramoops. Хотя он и прост, но требует определенных знаний, так что и это способ в принципе тоже можно отбросить.

Ошибки не исчезают с опытом - они просто умнеют

vasek	# 1 год, 8 месяцев назад
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Выше писал, что в случае kernel panic, логов нет, но можно снять дамп vasek … логов, как правило, практически нет, но есть механизм для анализа, но не так то просто это выполнить - во первых, нужно для этого иметь специалное ядро (как правило ставят два ядра) для получения дампа, а во вторых иметь специальные утилиты для анализа этого дампа. … Есть более простой способ, но он и менее информативен - использование ramoops. Сегдня решил проверить, что там изменилось в части снятия дампа при падении ядра и выяснил 1. При использовании механизма Kdump сейчас можно обойтись и стандартным ядром, то есть все нужные флаги сейчас стоят по дефолту (раньше нужно было пересобирать ядро). Попробовал - все довольно просто, дамп упавшего ядра снимается (объем около 5G), но вот с его анализом не все так просто - у меня не получилось, есть нюансы. То есть, как и предполагал, этот способ можно отбросить. 2. В части получения просто лога дампа ядра с использованием ramoops - здесь тоже немного изменилось и в лучшую сторону, то есть тоже стало проще - сейчас не нужно заниматься декодированием лога, на выходе уже раскодированный лог, привожу частичный вывод (kernel panic получал с помощью sysrq) DBGC ====1607692518.864611-D Panic#1 Part1 SB device found, idVendor=03f0, idProduct=311d, bcdDevice= 0.01 <6>[ 2743.985079] usb 2-1.6: New USB device strings: Mfr=0, Product=0, SerialNumber=0 …….. <6>[ 2841.863714] sysrq: Trigger a crash <0>[ 2841.863722] Kernel panic - not syncing: sysrq triggered crash <4>[ 2841.863736] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.9.12-arch1-1 #1 <4>[ 2841.863740] Hardware name: Hewlett-Packard HP ProBook 4530s/167C, BIOS 68SRR Ver. F.07 04/21/2011 <4>[ 2841.863744] Call Trace: <4>[ 2841.863753] <IRQ> <4>[ 2841.863771] dump_stack+0x6b/0x83 <4>[ 2841.863781] panic+0x112/0x2e8 <4>[ 2841.863791] ? printk+0x68/0x7f <4>[ 2841.863801] sysrq_handle_crash+0x16/0x20 <4>[ 2841.863808] __handle_sysrq.cold+0x43/0x106 <4>[ 2841.863816] sysrq_filter+0x1f8/0x420 …….. Имеея этот лог трудно что то установить однозначно - это же не полный дамп ядра. Но получить этот лог не сложно и польза будет только в случае, если в Call Trace будет хотя бы отдаленное упоминание о функции, по которой можно хоть как то догадаться о возможной причине. Но можно точно будет установить, что причина зависания - падение ядра. Это я к тому, что если при очередном зависании комп пойдет на перегрузку (если, конечно, прописал kernel.panic=10), то лог дампа можно и считать. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 1 год, 8 месяцев назад

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Выше писал, что в случае kernel panic, логов нет, но можно снять дамп

vasek
… логов, как правило, практически нет, но есть механизм для анализа, но не так то просто это выполнить - во первых, нужно для этого иметь специалное ядро (как правило ставят два ядра) для получения дампа, а во вторых иметь специальные утилиты для анализа этого дампа. …
Есть более простой способ, но он и менее информативен - использование ramoops.

Сегдня решил проверить, что там изменилось в части снятия дампа при падении ядра и выяснил
1. При использовании механизма Kdump сейчас можно обойтись и стандартным ядром, то есть все нужные флаги сейчас стоят по дефолту (раньше нужно было пересобирать ядро).
Попробовал - все довольно просто, дамп упавшего ядра снимается (объем около 5G), но вот с его анализом не все так просто - у меня не получилось, есть нюансы.
То есть, как и предполагал, этот способ можно отбросить.
2. В части получения просто лога дампа ядра с использованием ramoops - здесь тоже немного изменилось и в лучшую сторону, то есть тоже стало проще - сейчас не нужно заниматься декодированием лога, на выходе уже раскодированный лог, привожу частичный вывод (kernel panic получал с помощью sysrq)

DBGC
====1607692518.864611-D
Panic#1 Part1
SB device found, idVendor=03f0, idProduct=311d, bcdDevice= 0.01
<6>[ 2743.985079] usb 2-1.6: New USB device strings: Mfr=0, Product=0, SerialNumber=0
……..
<6>[ 2841.863714] sysrq: Trigger a crash
<0>[ 2841.863722] Kernel panic - not syncing: sysrq triggered crash
<4>[ 2841.863736] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.9.12-arch1-1 #1
<4>[ 2841.863740] Hardware name: Hewlett-Packard HP ProBook 4530s/167C, BIOS 68SRR Ver. F.07 04/21/2011
<4>[ 2841.863744] Call Trace:
<4>[ 2841.863753]  <IRQ>
<4>[ 2841.863771]  dump_stack+0x6b/0x83
<4>[ 2841.863781]  panic+0x112/0x2e8
<4>[ 2841.863791]  ? printk+0x68/0x7f
<4>[ 2841.863801]  sysrq_handle_crash+0x16/0x20
<4>[ 2841.863808]  __handle_sysrq.cold+0x43/0x106
<4>[ 2841.863816]  sysrq_filter+0x1f8/0x420
……..

Имеея этот лог трудно что то установить однозначно - это же не полный дамп ядра. Но получить этот лог не сложно и польза будет только в случае, если в Call Trace будет хотя бы отдаленное упоминание о функции, по которой можно хоть как то догадаться о возможной причине.
Но можно точно будет установить, что причина зависания - падение ядра.

Это я к тому, что если при очередном зависании комп пойдет на перегрузку (если, конечно, прописал kernel.panic=10), то лог дампа можно и считать.

Ошибки не исчезают с опытом - они просто умнеют

slend3r	# 1 год, 8 месяцев назад
Темы: 5 Сообщения: 36 Участник с: 14 сентября 2020	vasek, спасибо ещё раз! буду смотреть...

slend3r	# 1 год, 1 месяц назад (отредактировано 1 год, 1 месяц назад)
Темы: 5 Сообщения: 36 Участник с: 14 сентября 2020	Так, прошло уже полгода, докладываю. Увы, система всё также виснет в произвольные моменты несколько раз в месяц, даже когда я вообще компом не пользуюсь. Заметил такую ситуацию: kernel.panic=10, прописанный в /etc/sysctl.d/99-sysctl.conf , при таком зависании не работает: система не ребутается через 10 секунд. А ребутается она через минуту-две... При том, что эксперимент с Alt+SysRq+C работает на ура: через 10 секунд ребут как штык. Пока не знаю, куда и смотреть. Надеюсь, что от таких выкрутасов жесткие диски не покрошатся... А может это как-то быть связанным с тем, что у меня все приложения запускаются через firejail?

slend3r

# 1 год, 1 месяц назад (отредактировано 1 год, 1 месяц назад)

Темы: 5

Сообщения: 36

Участник с: 14 сентября 2020

Так, прошло уже полгода, докладываю.
Увы, система всё также виснет в произвольные моменты несколько раз в месяц, даже когда я вообще компом не пользуюсь.
Заметил такую ситуацию: kernel.panic=10, прописанный в /etc/sysctl.d/99-sysctl.conf , при таком зависании не работает: система не ребутается через 10 секунд. А ребутается она через минуту-две...
При том, что эксперимент с Alt+SysRq+C работает на ура: через 10 секунд ребут как штык. Пока не знаю, куда и смотреть. Надеюсь, что от таких выкрутасов жесткие диски не покрошатся...

А может это как-то быть связанным с тем, что у меня все приложения запускаются через firejail?

anode	# 1 год, 1 месяц назад
Темы: 7 Сообщения: 982 Участник с: 30 августа 2011	vasek объем около 5G А єто не многова-то для дампа ядра?

vasek	# 1 год, 1 месяц назад (отредактировано 1 год, 1 месяц назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	anode А єто не многова-то для дампа ядра? не удачно выразился - если быть точным, то это полный дамп памяти системы ... это, как правило, анализируют разработчики, ... но исследоавать этот дамп не так то и просто ... плюс к нему нужно расжатое ядро, а вот оно то и составляет около 80М ... и плюс соотвествующие утилиты. Сам дамп снимал несколько раз, но до самого анализа дело так и не доходило ......... бросал, и переходил на малый дамп/лог падения (типа Call Trace) порядка 128К EDIT 1 - уточнение в части термина дамп ядра - почему использовал такой термин? В DOC это называется так - dump of the system kernel’s memory, перевести в лоб можно и так - дамп памяти ядра системы … чтобы меньше писать, написал просто дамп ядра. Хотя по идее лучше подходит выражение дамп памяти системы … хотя, если быть точным, это тоже не совсем так … и выходит, что лучше использовать первоисточник dump of the system kernel’s memory Перевод в части использования Kdump `Kdump - это стандартный механизм Linux для сброса содержимого памяти машины при сбое ядра. Kdump использует kexec для быстрой загрузки ядра для захвата дампа, когда необходимо сделать дамп памяти ядра системы (например, при возникновении паники).` PS - хотя термин дамп памяти ядра системы, после осознания, стал нравится больше ... все-таки дамп памяти системы это не то ... Ошибки не исчезают с опытом - они просто умнеют

vasek

# 1 год, 1 месяц назад (отредактировано 1 год, 1 месяц назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

anode
А єто не многова-то для дампа ядра?

не удачно выразился - если быть точным, то это полный дамп памяти системы ... это, как правило, анализируют разработчики, ... но исследоавать этот дамп не так то и просто ... плюс к нему нужно расжатое ядро, а вот оно то и составляет около 80М ... и плюс соотвествующие утилиты.
Сам дамп снимал несколько раз, но до самого анализа дело так и не доходило ......... бросал, и переходил на малый дамп/лог падения (типа Call Trace) порядка 128К

EDIT 1 - уточнение в части термина дамп ядра - почему использовал такой термин?
В DOC это называется так - dump of the system kernel’s memory, перевести в лоб можно и так - дамп памяти ядра системы … чтобы меньше писать, написал просто дамп ядра.
Хотя по идее лучше подходит выражение дамп памяти системы … хотя, если быть точным, это тоже не совсем так … и выходит, что лучше использовать первоисточник dump of the system kernel’s memory
Перевод в части использования Kdump

Kdump - это стандартный механизм Linux для сброса содержимого памяти машины при сбое ядра. Kdump использует kexec для быстрой загрузки ядра для захвата дампа, когда необходимо сделать дамп памяти ядра системы (например, при возникновении паники).

PS - хотя термин дамп памяти ядра системы, после осознания, стал нравится больше ... все-таки дамп памяти системы это не то ...

Ошибки не исчезают с опытом - они просто умнеют

chronos	# 1 год, 1 месяц назад
Темы: 3 Сообщения: 518 Участник с: 15 марта 2012	Что то у меня подозрения что проблема электрическая. Проверьте кондеры на вздутие в БП если он старый, далее неплохо бы прозвонить цепи питания проца и памяти.