Panic при старте системы

Доброго (хотя относительно...) времени суток. Переодически, при старте системы происходит кёрнел паник, как я понял, не доходя до udev. Лог загрузки бежит адски быстро, единственное что успел посмотреть это финальные строки, там речь шла о SATA и прерываниях. Где можно посмотреть полный лог *предыдущей* загрузки ядра а не текущей удачной загрузки? В логах /var/logs/kernel-чего-то-там grep слова "panic" не нашёл, хотя в том, что писалось на экране оно было. Ну и если есть телепаты, то может кто скажет и что конкрено делать... =)

Armoyt написал:

grep слова "panic" не нашёл

обычно в /var/log/messages такие сообщения лежат, а так же в лога dmesg

i2ks написал:

[quote=Armoyt]grep слова "panic" не нашёл

обычно в /var/log/messages такие сообщения лежат, а так же в лога dmesg[/quote]
как правило этих файлов не по одному , предыдущие сохраняются как /var/log/messages1 , /var/log/messages2 и т.д. , там более старая информация с прошлых загрузок .

Все логи перерыл. Нигде нет упоминания о panic. Вот самое интересное что нашёл и то относится к уже успешной загрузке:

Jan 19 17:46:31 localhost kernel: EXT4-fs (sda2): re-mounted. Opts: commit=0
Jan 19 17:46:49 localhost kernel: usb 4-1: reset low speed USB device using ohci_hcd and address 2
Jan 19 17:53:55 localhost kernel: CE: hpet increased min_delta_ns to 7500 nsec
Jan 19 18:05:19 localhost -- MARK --
Jan 19 18:08:14 localhost ntpd[3467]: skew change -34.123 exceeds limit
Jan 19 18:25:20 localhost -- MARK --
Jan 19 18:40:20 localhost ntpd[3467]: skew change -21.440 exceeds limit
Jan 19 18:45:20 localhost -- MARK --
Jan 19 18:48:39 localhost ntpd[3467]: skew change -55.642 exceeds limit

особенно интересны последние строчки. Эти строчки не ищатся больше нигде в логе, кроме этого раза. Ечть упоминание, что ACPI занимается роутингом IRQ... учитывая, что в ошибках при загрузке писались проблемы с прерываниями, возможно это и причина. Сейчас попробую ещё раз получить эту ошибку с помощью ребутов... и записать конкретные сообщения.
Вот такую вот котовасию пишет:

? printk+0x18/0x16
panic+0x61/0x166
oops_end_0xc5/0xd0
n0_context+0xbc/0x150
_bad_area_nosemaphore+0x8d/0x130
? sched_clock+0x8/0x10

...

error_code+0x67/0x6c

...

ata_bmdma_error_handler+0x0/0x110

...

handle _IRQ_event+0x44/0x1a0
? move_native_irq+0x14/0x50
handle_edge_irq+0xae/0x140
handle_irq+0x47/0xc0
do_IRQ+0x47/0xc0

...

cpu_idle+0x96/0x140
start_secondary+0x215/0x21c
_
далее собственно висит...

Это не всё конечно, всё там слишком много писать. Жаль, но похоже ни один лог на жёстком диске в этот момент не пишется.

Armoyt!

Про "борьбу с логами и сообщениями при загрузке системы" - вот здесь почитайте:
http://archlinux.org.ru/forum/viewtopic.php?f=8&t=389

Если вопрос не снимется в процессе чтения - "логи в студию"

Chars67 написал:

Про "борьбу с логами и сообщениями при загрузке системы" - вот здесь почитайте:
http://archlinux.org.ru/forum/viewtopic … &t=389

Если вопрос не снимется в процессе чтения - "логи в студию"

Либо я не так понимаю, либо там даны методы как прочитать лог, когда он бежит в обычной загрузке... но у меня-то загрузка необычная, при ней происходит кёрнел паник и система не реагирует на клавиши - в любом случае всё зависнет на последних строчках, если конечно не проявить магическую сноровку и не суметь нажать шифт+пэйдж-ап именно в тот момент именно "паниковской" загрузки (пока всё ещё подчиняется системе), что консоль при зависании выбросит на начало лога... но я таких сил в себе не чую) В самих логах ничего не остаётся, насколько я понял, в частности я смотрел почти все логи в /var/logs в том числе messages.log everything.log и kernel.log - разумеется последние версии, ориентируясь по дате, а не все четыре тома, что там есть... а dmesg.log это лог именно текущей загрузки, то есть "хорошей" загрузки.
Моя сноровка по нажатию шифта+пэйдж-ап не совершенна, но позволила узнать кое-что новое... в частности, то что я выше писал это была трассировка ошибки, а сама ошибка выглядит так:

Kernel panic - not syncing: Fatal Exeption in interrupt
pid 1841, comm: Sed Tainted: G D 2.6.36.-ARCH #1

и было ещё такое же, но:

pid 1767, comm: modprobe Tainted

Второе что могу сказать - похоже ошибка вылезает только при обесточивании и старте системы, а не при ребуте (но вероятность появления ошибки не 100%, что самое интересное...). И таки она вылазит конечно позже загрузки модулей, а не до Udev, просто там скорость высокая и первый раз я это упустил.

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

Armoyt написал:

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

Вот незадача, пишет "немогу прочитать пакет" указываю ему путь из кэша пэкмана до ядра старого.
А из яурта ядра принципиально не хотят собиратся - у всех пишут fail при попытке пройти целостность какого-либо файла... причём всегда одного и того же (там патчи разные бонусом идут). Такое явление нормально для aur или у меня соединение с ним настолько коряво? В последнем случае, я думаю бились бы разные файлы...

Из старого репозитория тоже не получилось?

Armoyt написал:

А из яурта ядра принципиально не хотят собиратся - у всех пишут fail при попытке пройти целостность какого-либо файла... причём всегда одного и того же

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

core/kernel26 2.6.36.3-1 (base) [установлен]
The Linux Kernel and modules

archlinuxfr/kernel26rt 2.6.33.7_rt29-1 [установлен]
The Linux Kernel and modules - with realtime preemption

Второе ядро это и было "лекарством" (постучал по дереву, так как неизвестно сработало ли на 100%). Но почему они оба установлены? Или второе это что-то типа патча, наложенного на base? Или их где-то можно переключать?

Вообще я пришёл к идее, что на Арче не надо ничего обновлять, если всё работает... а то винтики за гаечки заскочат и полетит вообще всё.

Armoyt написал:

Вообще я пришёл к идее, что на Арче не надо ничего обновлять, если всё работает... а то винтики за гаечки заскочат и полетит вообще всё.

Раз на раз не приходится. Обычно обновляется без проблем. Бывают сложности, если девелоперы начинают что то мутить с заменой или выпиливанием чего то. Это можно отследить в списке рассылки. Если намечается что то массовое, то лучше подождать пару дней и почитать форум. Кто с чем столкнулся.

Armoyt написал:

Второе ядро это и было "лекарством" (постучал по дереву, так как неизвестно сработало ли на 100%). Но почему они оба установлены? Или второе это что-то типа патча, наложенного на base? Или их где-то можно переключать?

они оба установлены, но работает только одно. переключать при загрузке. (наверное. или в загрузчике).

ЗЫЖ вам точно нужно ядро реального времени???

drBatty написал:

ЗЫЖ вам точно нужно ядро реального времени???

Если бы я знал в чём разница..)) конечно я устанавливал его не потому что мне нужно было именно это ядро, я действовал по принципу "изменить настройку, чтобы посмотреть реакцию". Похоже после установки ядра срабатывает скрипт, который переделывает menu.lst. То есть я сейчас на новом ядре... или поправте меня, если это не так. Ведь если это не так, то всё, чего я достиг аннулируется =)

# (0) Arch Linux
title Arch Linux
root (hd0,1)
kernel /boot/vmlinuz26 root=/dev/sda2 ro vga=773 5 reboot=p
initrd /boot/kernel26.img

Armoyt написал:

То есть я сейчас на новом ядре... или поправте меня, если это не так.

uname -r

Armoyt!
Да вы не паникуйте:

просто имеется в виду:

$ uname -r

и узнаем текущую версию вашего ядра.

И даже если это рил-тайм-кернель - фигня делов - можно ведь и в QNX сидеть на домашнем десктопе. Кроме шуток.

мда... похоже ниразу я не на новом ядре)

[armoyt@f5n ~]$ uname -r
2.6.36-ARCH

Судя по всему надо вручную прописывать путь до сюда:

[armoyt@f5n ~]$ ls /boot
grub kernel26-fallback.img kernel26rt.img System.map26rt vmlinuz26rt
kernel26-ck-fallback.img kernel26.img System.map26 vmlinuz26
kernel26-ck.img kernel26rt-fallback.img System.map26-ck vmlinuz26-ck

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

[внезапно]
уже соберите своё ядро и не парьтесь .. wink (очень-о-оч-чень плохой совет ) ...

[в двойне внезапно] а кто сказал, что на собранном мною своём ядре этого не будет?)
Как и следовало ожидать ошибка никуда не исчезла... есть идеи как откатить ядро без использования кэша пэкмана? в кэше лежат не tar.gx, а что-то вроде tar.xz причём только на некоторых пакетах, в число коих и входят все скачанные мною ранее ядра.

Armoyt!
Уже не смешно - .xz - c некоторых пор стандартный архив пакетов в Arch'e.

Но опять же - ничего страшного.

Все проходили через ляпы (а качественный гожий ляп - дык это ж вообще песня smile ).

Короче: а теперь-то что не так?

Ну переодиский кёрнел паник-то никто не излечил...)
Да, работает пакман с этими пакетами, я просто первый раз коряво команду давал. Теперь вот буду думать откуда взять версию nvidia для старого ядра)) Или откачусь на самое несвежие из 2.36...