Kernel Panic в материнке Intel

Если у дебиана включено по умолчанию сохранение логов через journald, то после успешной загрузки смотри лог предыдущей загрузки

journalctl -b -1

Просто так гадать смысла нет.

Ух ты, уже интересно! :)
Эта команда выдала такое -

journalctl -b -1
Specifying boot ID or boot offset has no effect, no persistent journal was found.

/etc/systemd/journald.conf Storage=persistent потом systemctl reboot

Intel не велит ставить X3470 на H57 Express.

Посмотрел .../journald.conf, в нем все строки, если я правильно понимаю здесь символ #, вроде закомментированы -

[Journal]                                                                              
#Storage=auto                                                                          
#Compress=yes                                                                          
............................
#LineMax=48K                                                                           
#ReadKMsg=yes    

Storage=persistent

Intel не велит ставить X3470 на H57 Express.

Почему не велит? Прежде чем ставить его, сверялся с докой, вроде никаких противпоказаний нет.

Так написано в официальной таблице совместимости Intel.

Что за таблица, можно глянуть?

https://www.intel.com/content/dam/support/us/en/documents/boardsandkits/deskt...
не вижу там поддержку Xeon-ов

Дейсвительно нет. Вот незадача :-(
Что же это получается - сначала Intel при выпуске материнки пишет, что Xeon с ней совместим, а потом уже, задним числом, опровергает ранее сказанное ей же??

Ведь я не с бухты-барахты воткнул Xeon, где-то же сначала прочел, что он подходит, вот только запамятовал, где именно.

И что же теперь делать - обратно менять Xeon на i3, или обратиться к сборщикам ядра Debian, может они какой-то патч дадут?

Или это бесполезно, потому что несовместить на уровне «железо-железо»?

В любом случае ты эту проблему вряд ли решишь. Увидишь ошибку и что. Я бы пробовал старые версии того же дебиана, может этот баг из новых версий ядра.

если я правильно понимаю здесь символ #, вроде закомментированы

Как ты до трёх звёзд дофлудился?

Увидишь ошибку и что.

Ну как что... Конечно, сам эту проблему не решу, но может сборщики ядер разберутся?
Что я им должен сообщить после паники - кусок лога перед паникой?

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

Если бы паника постоянно происходила, разобраться было бы легче, но она происходит нестабильно, через неизвестно сколько дней.

Поскольку включил предложенное сохранение логов через journald.conf, понаблюдаю пока.

если я правильно понимаю здесь символ #,

Да не дофлудился, дело в другом. Обычно символ # в конфигах да, означает комментирование.
Но когда открыл конфиг journald.conf и увидел, что в нем у ВСЕХ строк впереди стоит #, то засомневался в назначении этого символа.
Может, он в этом конфиге что-то другое означает.
Иначе зачем такой конфиг, у которого ВСЕ, штук 30 строк, закомментированы? Показалось странным, вот и спросил.

Legioner

Ура! Сервак снова упал. В смысле не ура, а хреново, но зато теперь журналирование было включено, и запустил команду

journalctl -b -1

Прокрути в самый конец. shift+G. Там будут последние события перед падением (если, конечно, они успели записаться в лог).

Конечно, прокручивал, но только ничего крамольного в них не заметил.

Получается, в Линуксе нет гарантированного способа запомнить в логах те события, которые пробегают по экрану перед kernel panic ?

Ну если он на диск не успевает сбрасывать логи перед тем, как сдохнуть, то я таких способов не знаю. Наверное как-то можно в серийный порт засунуть логгирование, чтобы он печатал не на экран, а в серийный порт, но я так не делал и не очень представляю, откуда начинать. Может кто поумней напишет чего.

М-да. Отчего это зависит - успеет или не успеет?

В офтопе есть возможность сбросить дамп перед падением, чтобы потом спокойно его анализировать. Тут такого похожего нет?

Legioner:

Всё, после включения усиленного журналирования кажется, удалось подловить этот коварный момент!
Во всяком случае некоторые строки логов на экране были закрашены жутким красным цветом.
Например: BUG-1, BUG-2.

Есть и полный конфиг - https://pastebin.com/Mk8aUaJs

Что скажете по этим следам, уважамые знатоки?

Ну первым делом я бы прогнал мемтест.

Как раз перед этим и проганял Memtetst 86 :-)

В Safe режиме он сутки крутился и ничего не нашел.
В Multitrade или как там назывался запускать отказался и намертво вис, кмк, это нормально?

Можно: документация на плату и/или чипсет лежит на сайте intel.

Получается, в Линуксе нет гарантированного способа запомнить в логах те события, которые пробегают по экрану перед kernel panic ?

При этом понять, что толком приосходит невозможно, поскольку на мониторе сначала пробегает несолько сотен строк, быстро уходящих навверх, и лишь затем происход останавка на странице с Kernel Panic.

Есть очень грязный хак:

1. установи консольный шрифт максимально мелкого размера
2. включи на телефоне запись видео, желательно с повышенным fps (я тыкал со 120)
3. запиши kernel-panic на видео, видео проигрывай покадрово

Но это, увы, работает только когда знаешь, когда конкретно kernel panic будет…

Но мелкий шрифт все равно можно поставить, если паника не очень длинная - может помочь.

Можно поставить символы от ядра и включить kdump.

Ещё можно заставить ядро срать в серийную консоль, подцепиться к серийному порту и писать все, что оно туда высрало хоть на самописец)

Ещё можно включить магию sysrq и тогда при панике можно будет его заставить повторить последние записи, но это если повезёт.

Кароче вариантов я тебе накидал, гугли.

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

мемтестов много. Попробуй другие.

https://www.raymond.cc/blog/test-your-ram-with-microsoft-windows-memory-diagnostic/

Я когда-то микрософтовским нашёл проблему, которую memtest не находил.

Можно: документация на плату и/или чипсет лежит на сайте intel.

Лежит, и что с того? Там о kernel panic ни слова.

Есть очень грязный хак:
Но это, увы, работает только когда знаешь, когда конкретно kernel panic будет…
Но мелкий шрифт все равно можно поставить, если паника не очень длинная - может помочь.

В том-то и дело, что непонятно, когда он появляется.
К тому же пробегало экранов с 5, вряд ли мелкий шрифт позволит увидеть всё.

Можно поставить символы от ядра и включить kdump.

kdump и так болтается в процессах, его не так просто отключить без последствий.
И как действовать дальше?

Ещё можно включить магию sysrq и тогда при панике можно будет его заставить повторить последние записи, но это если повезёт.

Т.е шансов немного, ладно.

Насчет серийной консоли. Допустим, откопал штыри RS232 на материнке, а что к ним подключать, надо какое-то устройство?

Я когда-то микрософтовским нашёл проблему, которую memtest не находил.

Вот и я подумал - прогнать сервак стресс-тестом типа Prime95 или LinX, но время на эти эксперименты ограничено, сервак должен работать, а не стоять.

Так что, братья по разуму, те логи и скрины, которые вчера выложил, ничего конкретного вам не говорят?

Тогда из-за нехватки времени пока поступлю, наверное следующим образом.
Емнип, эти падения начались после какого-то обновления Debian.
Ведь все чукчи наивно верят, что каждое обновление улучшает Linux, вот и я обновля. И дообновлялся.
Если это действительно так, то незачем мучить сервак тестами, а нужно откатить ядро назад на старое, только не помню, как это делается.

Поэтому поступлю проще: сейчас стоит Debian 10.7, и его переустановлю на 10.4 или еще поменьше.
Если падение прекратится - значит, криворукие дебиановцы. Если продолжится - то кривое железо.

Legioner: Переустановил на старый 10.2 и нашел шикарный стресс-тест от Intel -
https://losst.ru/stress-test-protsessora-v-linux
От него и произошел знаменитый Linx.

Читаем, вникаем, а я ща затестю :-)

dh57

dh55 в обоих вариантах та еще дрянь была. Недоделанная как бы uefi прошивка. После расширения памяти с 2 по 2 до 4 по 2 даже той же той же партии (было много немало блоков одной сборки) у большинства появлялись случайные перезагрузки, вроде. На мемтесте нормально работали.

Вроде, видел в ядре опции, что дамп остается в памяти и после горячей перезагрузки можно забрать.

шикарный стресс-тест от Intel - https://losst.ru/stress-test-protsessora-v-linux

Ну и тестище!!!
Запустил, потребляемая моща скакнула от 44 до 150 Вт и через пару минут пришлось остановить, потому что жареным запахло :-))

Теперь надо думать, как ослабить этот тест, потому что по предыдущим замерам знаю, что кулеры в этом блоке выше 100 Вт не вытягивают, дальше троттлинг.

Legioner
Х-ха! memtest86+ после суток тестирования так ничего и не обнаружил.

А вот тест memtester, запущенный прямо на Debian, осторожненько так намекнул -

root@Bolivar:~# memtester 7000 3
memtester version 4.3.0 (64-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 7000MB (7340032000 bytes)
got  7000MB (7340032000 bytes), trying mlock ...locked.
Loop 1/3:
  Stuck Address       : testing  11FAILURE: possible bad address line at offset 0x7732d0c8.
Skipping to next test...

Однако тут возникают очевидные вопросы к самим тестам.

Ведь memtest86+ запускался с LiveCD, и какая для него среда запуска, не знаю, может даже обычный DOS, который в отличие от офтопа не глючит, поэтому этот тест ошибок в памяти и не обнаружил.

А вот memtester запускался прямо в Debian, и если в нем ядро таки кривое, то это как, могло сказаться на корректности самого тестирования памяти?
Т.е. память может и хорошая, но врёт само ядро?

Пока в растерянности...

Вряд ли ядро может влиять на memtest. В общем видимо нужно менять память.

Получается, в Линуксе нет гарантированного способа запомнить в логах те события, которые пробегают по экрану перед kernel panic ?

Kernel panic может сохраниться максимум в pstore, в логах ОС его никогда не будет.

В офтопе есть возможность сбросить дамп перед падением, чтобы потом спокойно его анализировать

Это не работает, если падение вызывает жесткий диск, где расположена система(или вообще контроллер SATA).

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

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

В общем видимо нужно менять память.

А может ли влиять на ошибки тестирования несовместимость XEONa с данной материнкой, о которой знатоки указывали выше?


Еще мысль: поскольку free -m показывал такое распределение памяти -

 free -m
              total        used        free      shared  buff/cache   available
Mem:           7912         119        7616           8         176        7568
Swap:          7628           0        7628

memtester 7000 3

Как ты до трёх звёзд дофлудился?

Чукча - писатель.

Уменьшил проверяемую память до 3 Гиг - и все равно ошибки.
Значит, пора менять ... электролиты в обвязке! ;-) Или БП.

Legioner

Меня не было здесь 5 дней.
Чем я этим всё время разбирался? Да поиском причин kernel panic и каждодневным тестированием памяти!

Перебрал несколько «лучших» тестов и потратил много времени на них.
Устал неимоверно, поэтому выскажесь кратко:

Все эти «знаменитые» memtest86+, комплексные стресс-тесты от Intel и прочее - полное дерьмо!
Они так и ничего не сумели найти, так что их афторы пусть засунут их себе в $#*^& сами знаете куда.

А самый лучший тест памяти в мире - ничем не примечательный, никак не распиаренный memtester.

Использовал 64-битовую версию 4.3.0 memtester, которая и решила все обнаруженные проблемы.

Всем спасибо за посильную помощь!