Изпечатай

[Lamqta]

Значи имам рутър под Дебиан, на който освен един mysql няма нищо друго. Но винаги между 10:30 и 11: 00 вечерта забива с kernel panic, като последното съобщение е за IRQ проблем. Забранил съм от BIOSа всички периферии, които не се използват, като звук, сериини и паралелни портове, LAN и т.н., но ефектът е нулев, а същевременно IRQтата си изглеждат наред:

:/proc# cat interrupts
           CPU0
  0:   19371640          XT-PIC  timer
  1:        594          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  9:          0          XT-PIC  acpi
 11:   54860279          XT-PIC  eth1
 12:   59223299          XT-PIC  eth0
 14:      74579          XT-PIC  ide0
 15:     123457          XT-PIC  ide1
NMI:          0
ERR:          0

Ето и процесите:

:~# ps ax
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  1584  512 ?        S    08 : 02   0 : 00 init [2]
root         2  0.0  0.0     0    0 ?        SN   08 : 02   0 : 00 [ksoftirqd/0]
root         3  0.0  0.0     0    0 ?        S<   08 : 02   0 : 00 [events/0]
root         4  0.0  0.0     0    0 ?        S<   08 : 02   0 : 00 [khelper]
root         5  0.0  0.0     0    0 ?        S<   08 : 02   0 : 00 [kthread]
root         6  0.0  0.0     0    0 ?        S<   08 : 02   0 : 00 [kacpid]
root         7  0.0  0.0     0    0 ?        S<   08 : 02   0 : 00 [kblockd/0]
root         8  0.0  0.0     0    0 ?        S    08 : 02   0 : 00 [pdflush]
root         9  0.0  0.0     0    0 ?        S    08 : 02   0 : 05 [pdflush]
root        11  0.0  0.0     0    0 ?        S<   08 : 02   0 : 00 [aio/0]
root        10  0.0  0.0     0    0 ?        S    08 : 02   0 : 00 [kswapd0]
root        18  0.0  0.0     0    0 ?        S    08 : 02   0 : 00 [kseriod]
root        19  0.0  0.0     0    0 ?        S<   08 : 02   0 : 00 [exec-osm/0]
root        20  0.0  0.0     0    0 ?        S<   08 : 02   0 : 00 [block-osm/0]
root        21  0.0  0.0     0    0 ?        S<   08 : 02   0 : 00 [reiserfs/0]
root       217  0.0  0.1  1840  700 ?        Ss   08 : 02   0 : 01 /sbin/syslogd
root       220  0.0  0.1  1708  504 ?        Ss   08 : 02   0 : 00 /sbin/klogd
bind       228  0.0  0.7 30220 3380 ?        Ss   08 : 02   0 : 01 /usr/sbin/named -u bind
root       248  0.0  0.2  2624 1268 ?        S    08 : 02   0 : 00 /bin/sh /usr/bin/mysqld_safe
mysql      278  0.0  1.3 65836 6484 ?        S    08 : 02   0 : 00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysql
root       279  0.0  0.1  1568  500 ?        S    08 : 02   0 : 00 logger -p daemon.err -t mysqld_safe -i -t mysqld
quagga     319  0.0  0.3  4720 1672 ?        Ss   08 : 02   0 : 00 /usr/lib/quagga/zebra --daemon -A 127.0.0.1
quagga     323  0.0  0.3  4952 1868 ?        Ss   08 : 02   0 : 00 /usr/lib/quagga/ripd --daemon -A 127.0.0.1
spong      326  0.0  1.0  6756 5296 ?        Ss   08 : 02   0 : 00 spong-client (sleeping)
root       343  0.0  0.2  3472 1440 ?        Ss   08 : 02   0 : 00 /usr/sbin/sshd
root       370  0.0  0.2  4240 1168 ?        Ss   08 : 02   0 : 00 /usr/sbin/squid -D -sYC
proxy      373 18.4 15.7 77992 76056 ?       S    08 : 02  59 : 48 (squid) -D -sYC
proxy      374  0.0  0.0  1428  296 ?        Ss   08 : 02   0 : 01 (unlinkd)
root       735  0.0  0.1  1944  812 ?        Ss   08 : 03   0 : 00 /usr/sbin/cron
root       738  0.0  0.3  2736 1552 tty1     Ss+  08 : 03   0 : 00 -bash
root       739  0.0  0.1  1708  484 tty2     Ss+  08 : 03   0 : 00 /sbin/getty -L 38400 tty2
root       740  0.0  0.1  1708  484 tty3     Ss+  08 : 03   0 : 00 /sbin/getty 38400 tty3
root       741  0.0  0.1  1708  484 tty4     Ss+  08 : 03   0 : 00 /sbin/getty 38400 tty4
root       742  0.0  0.1  1708  492 tty5     Ss+  08 : 03   0 : 00 /sbin/getty 38400 tty5
root       743  0.0  0.1  1708  484 tty6     Ss+  08 : 03   0 : 00 /sbin/getty 38400 tty6
root      1790  0.0  0.4  6380 2008 ?        Ss   09 : 28   0 : 01 sshd: root@ttyp1
root      1793  0.0  0.3  2728 1544 ttyp1    Ss+  09 : 28   0 : 00 -bash
root      3011  0.0  0.2  2744 1424 ?        S    12 : 53   0 : 00 dhcpd3 -f eth1
root      3161  0.0  0.4  6380 1932 ?        Ss   13 : 04   0 : 00 sshd: root@ttyp2
root      3165  0.0  0.3  2728 1540 ttyp2    Ss   13 : 04   0 : 00 -bash

Дайте някакъв акъл какво да правя, че съм се видял в чудо. Предварително благодаря на всички отговорили!

P.S. С кернел 2.6.11 съм между другото.

[rpetrov]

А входящия трафик как е ? Нещо регулярно във връзките/пакетите преди забиване ?

[Lamqta]

Нищо необичайно. Всичко изглежда наред. Мисля, че не е от кернела. Повече от година работи нормално с кернел 2.4.27, когато почна да забива. Сега съм с 2.6.11 и пак е същото. В сислога няма абсолютно никакво съобщение преди забиването. Чекнал съм диска за грешки, сменил съм паметта, смених дори и LAN картите, за да съм сигурен, че не е нещо от хардуера, но ефект - нулев. Впрочем ето и последните съобщения от сислога преди kernel panic:

kernel: nf_hook: hook 0 already set.
kernel: skb: pf=2 (unowned) dev=lo len=491
kernel: PROTO=17 61.172.249.200:32809 82.199.199.85:1026 L=491 S=0x80 I=0 F=0x4000 T=2
kernel: nf_hook: hook 2 already set.
kernel: skb: pf=2 (unowned) dev=lo len=491
kernel: PROTO=17 61.172.249.200:32809 82.199.199.85:1026 L=491 S=0x80 I=0 F=0x4000 T=1
kernel: nf_hook: hook 4 already set.
kernel: skb: pf=2 (unowned) dev=lo len=491
kernel: PROTO=17 61.172.249.200:32809 82.199.199.85:1026 L=491 S=0x80 I=0 F=0x4000 T=1
kernel: nf_hook: hook 0 already set.
kernel: skb: pf=2 (unowned) dev=lo len=491
kernel: PROTO=17 61.172.249.200:32809 82.199.199.85:1026 L=491 S=0x80 I=0 F=0x4000 T=1

[laskov]

- cron стартира нещо? задейства се някаква power save функция? Промени му часовника и виж дали и забиването ще се премести във времето. Ако не, значи е от някакво външно за системата събитие, макар че не мога да си представя какво може да е. Може да промениш системния час и часа в BIOS с различни стойности и така да разделиш хардуер/софтуер.  '>  '>

[Lamqta]

Първото нещо, което направих беше да изкоментирам всичко в кронтаблицата. Cron  е активен, но няма нищо, което да се стартира.

[Agent_SMITH]

mv

Успех '>

[iive]

Ще е много ценно ако успееш да запишеш един log от kernel panic-а.
BTW ако си с RTL8139 по добре смени модела на Lan-ката.

Понеже нямаш късмета да правиш kernel oops, не можеш да разчиташ на логовете. Ще се наложи да намериш някой от патчовете които dump-ват kernel panic-а на :дискета, сериен кабел, swap.

За съжаление това е само половината работа, понеже кернелът е компилиран от теб, адресите нямат смисъл, затова трябва да го обработиш с ksymoops. Много препоръчително е да направиш директория
/var/log/ksymoops/
Там ще се записват всички зареждания на модули. Да не я забравиш после, че ще ти изяде всичкото място '>
Разбира се трябва ти System.map и някои други файлчета.

За повече информация погледни тук
и разбира се документацията на ksymoops

Ако успееш прати ми вест!

[Lamqta]

LAN картите са Intel, така че това отпада. Кернела съм го компилирал твърд, без модули, така че не знам дали и това ще свърши работа, но ще се поровя в линковете, който си ми дал и дано измисля нещо.

Аз имам подобен проблем.
Данеби паник-а да е Aieee, killing interrupt handler! Най-отдолу.
Ползваш ли трафик шейпинг? Ако да, от кога?
Ако намериш решение на проблема си, моля сподели го с нас.

[Lamqta]

Да, ползвам трафик шейпинг, обаче го спрях, като почна да забива, така че това можем да го изключим, защото продължава да забива. А проблема ми прилича на Hard Panic – also known as Aieee

Цитат

Hard panics – causes: The most common cause of a hard kernel panic is when a driver crashes within an interrupt handler, usually because it tried to access a null pointer within the interrupt handler.  When this happens, that driver cannot handle any new interrupts and eventually the system crashes.  This is not exclusive to Dialogic drivers.

Така че KSYMOOPS едва ли ще ми свърши работа.

Само 1 ще кажа. Тоя Aieee, panic. Го имам с ядра 2.4.20, 2.4.26 и 2.4.29. На 2 абсолютно различни машини. Compaq P60 Seagate 106MB. 2x3c503 и HP P166, 1GB MAXTOR, i 1xRTL8139 i 1xMyson.
Линукса е един и същ, само ядрата и драйверите за ЛАН-а са различни. Иначе е image 1:1. При мен забива абсолютно произволно. Ползвам го за рутер на РРТР връзка. pptp-to ми е
1.6.0, pppd 2.4.3 ako не се лъжа. Ползвам HTB за шейпинг.
Едно е сигурно, не е hardware проблем. Изключил съм swap.
Ако не е от шейпинг-а не знам от какво може да е. Информацията в нета е много оскъдна на тази тема.
Дистрото е Слак 10.

[Lamqta]

Така. Значи ставаме двама. И мойте машини са две. Едната е Athlon2500+, 512RAM, с два диска, като единият го използвам за прозрачно прокси под скуид. Другата е 2xPentium II Klamath  с 256RAM без прокси. И двете забиват по абсолютно идентичен начин, с тази разлика, че колкото и да е странно по-нестабилната е двупроцесорната, макар че при компилацията на ядрото съм включил поддръжка на 2 процесора. Сега съм със статични IP адреси, но преди това бях и аз с pptp. Проблемите общо взето започнаха, когато преминах от pptp към статичните IPта. Ще пробвам да махна pptp-то изобщо и ще ви кажа как се държи до 1-2 дни.

[iive]

ksymoops-а е чак втората стъпка.
Аз имах късмет да имам oops, но ти го нямаш. Затова:
- използвай примерно LCKM_hotwo
за да го запишеш на swap-а.

- използвай kmsgdump за да го запишеш на дискета или до го отпечаташ през паралелния порт.

 - възможно е да успееш да хванеш dump-а, ако компилираш със серийна конзола и сложиш bootparam console=ttyS1 . Разбира се ще ти трябва още един компютър или какво да е устройство което да запише dump-а (примерно Palm ).

Ако си с 2.6.x kernel включи Kernel_hacking->KernelDebugging->Compile_the_kernel_with_debug_info
Това би трябвало да ти спести ksymoops-а.

[Lamqta]

Цитат

- използвай примерно LCKM_hotwo

За съжаление пачовете за ядрото са само до версия 2.6.9 така че за момента и това не ми върши работа '>

[bira_more]

Не знам дали ще ти свърши работа - малко в страни ама:
Имахме проблеми с компилации (Gentoo) - оказа се проблемна memory.
Сменихме я - по малко проблеми.
Да не би да има хардуерен проблем?
Решим със смяна на хардуера?