LINUX.ORG.RU

Не грузится Mint (Ubunti, Khali), не запускается LiveUSB: kernel panic -Firmware bug, Harware error,

 


0

1

Стоял Mint 18.2, вчера после очередного обновления ядра и intel-microcode пошел спать, утром заметил что ПК перезапустился. Как оказалось - перезапуск был циклическим - раз в 30 секунд из-за kernel panic. Актуально для всех версий ядер который были сохранены.

Изначально сообщение было такое: tsc deadline disabled due to errata; please update microcode to version: 0x52 (or later), после чего обновил bios - ошибка поменялась на kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exeption handler. Иногда удавалось загрузиться до логин скрина и зависал на нем, иногда практически сразу после запуска. Никакой связи уловить не смог. Тоже самое при загрузке с LiveUSB (Mint,, ubuntu). Отключил hyperthreading - и кое-как смог поставить khali, который завелся с noapic. Система работает 5-10 минут после чего фризится, звук уходит в зацикливание и спустя 30 секунд - перезагружается.

Это уже что-то аппаратное?

Скрины с разных мест прилагаю (железо Core i7-7700k, asus prime h270-plus) фото

Как вариант ядра древние попробовать 3.х-4.0. Напоследок накатить win 10 посмотреть как она себя поведет.

intel выпустила обновление микрокода, от которого происходили перезагрузки, но это касалось более древних архитектур haswell и еще какой то, новость тут была, поищи.

Скорее всего аппаратная проблема.

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

Качнул десятку, через минтовский «Запись образа...» закатал на флшеку - не запускается, т.е просто игнорит его. Буду экспериментировать. Про обновление микрокода почитал, вроде моего ядра то нет. Проц пока на гарантии, наверное пойду сдавать - а там уж как решат их эксперты.

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

Ну так ты питание пробовал отключать?

Ещё попробуй записать мяту какую на флешку и попользоваться лайвом. Если будет работать - значит таки в grub'е обновления микрокода прописались.

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

Можешь выложить dmesg у глючащей системы и когда работало нормально (скажем, journalctl --list-boots, там, например, в декабре всё нормально было, а это 10 ребутов назад, journalctl --dmesg -b -10)? Хотя не уверен, что если новый микрокод (если предположить, что он при откате биоса не сбрасывается до старой версии) будет видно в логах. С другой стороны, версия микрокода будет видна

onlybugs ★★ ()
Последнее исправление: onlybugs (всего исправлений: 2)
Ответ на: комментарий от vicacid

Может быть проблема с оперативной памятью.

Скачай memtest, запиши на флешку и проверь память.

Можешь попеременно подключать по одной планке памяти и протестировать их все.

Как найдёшь глючную не подключай её.

Если гарантия на память есть вперёд менять в магазин.

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

Тогда пробуй ставить Windows 10, просто создай на флешке fat32 и скопируй на неё все файлы из ISO образа Windows 10.

Дальше грузись в UEFI режиме с флешки.

Никаких других программ для создания флешки с установщиком Windows не нужно.

Но это только для UEFI режима.

Как поставишь проверяй как работает система.

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

Гугл нашёл пару подобных случаев. У одного кривой биос был, обновление помогло. Несколько других просто пропали.

https://lime-technology.com/forums/topic/55140-632-kernel-panic-not-syncing-t...

https://www.thomas-krenn.com/de/wiki/Kernel_panic_-_not_syncing:_Timeout:_Not...

https://askubuntu.com/questions/989900/kernel-panic-not-syncing-not-all-cpus-...

onlybugs ★★ ()
Последнее исправление: onlybugs (всего исправлений: 1)
Ответ на: комментарий от vicacid

зайдём с другой стороны. что говорит

dmesg | grep -i microcode

?

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

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

в микрокоде дело.

У меня стоит intel-ucode 20180108-1. Обновы для твоего процессора:

$ bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -l -s 0x906e9 -
microcode bundle 1: (stdin)
selected microcodes:
001/159: sig 0x000906e9, pf_mask 0x2a, 2018-01-04, rev 0x0080, size 98304

Из интеловского архива 20171117:

$ iucode_tool -td -l -s 0x906e9 microcode.dat
microcode bundle 1: microcode.dat
selected microcodes:
001/159: sig 0x000906e9, pf_mask 0x2a, 2017-04-06, rev 0x005e, size 97280

Чуть более старый архив 20170707:

$ iucode_tool -td -l -s 0x906e9 microcode.dat
microcode bundle 1: microcode.dat
selected microcodes:
001/159: sig 0x000906e9, pf_mask 0x2a, 2017-04-06, rev 0x005e, >size 97280

А ты говоришь, что у тебя ревизия 0x7c. Нужно пробовать загружать старый микрокод. Или искать где взять бинарник посвежее (вот в арче, например) и его попробовать. Ну или подождать пока интел выкатит нормальное обновление

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

Микрокод изначально загружается из Bios, но если у ядра есть более свежая версия микрокода, то будет загружена она ядром. В deb дистрибутивах есть отдельный пакет intel-microcode. Если этот пакет обновился, то если даже ты откатишься на старое ядро, версия микрокода будет та же. Поправьте, если не прав.

zyxar ()
Ответ на: комментарий от vicacid

Взял другую материнку на таком же чипе (H270) - кое-как поставил винду, радовался около 2,5 - 3 часов, погонял интеловскими тестами проц - в 3 из 5 случаев валится с ошибкой по перегреву процессора (в аиде до 100%, тротлинг до 35%), после чего все так же зафризилось (стартует через раз и зависает в интервале от 1 до 30 мин). Радиатор и кулер на 200 Вт тепловыделения, при 91 у Core i7 7700k - должно хватать, взял сегодня core i5, полет нормальный, семерку попытаюсь вернуть по гарантии.

vicacid ()