Unable to handle kernel NULL pointer dereference at virt....

[MeTRiX]

Hallo,

in syslog hat mir mein Server seit gestern 3x folgendes ausgepuckt. Muss ich mir nun gedanken machen? bzw. was soll mir das sagen?

Es läuft ne aktuelle Debian stable und ich behaupte fast, dass es erst seit dem update vom kernel (b24) gestern auftritt.

Aug 2 20:55:19 server kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 0000007c
Aug 2 20:55:19 server kernel: printing eip:
Aug 2 20:55:19 server kernel: c01491f2
Aug 2 20:55:19 server kernel: *pde = 00000000
Aug 2 20:55:19 server kernel: Oops: 0000
Aug 2 20:55:19 server kernel: CPU: 0
Aug 2 20:55:19 server kernel: EIP: 0010:[may_ptrace_attach+126/164] Not tainted
Aug 2 20:55:19 server kernel: EFLAGS: 00010202
Aug 2 20:55:19 server kernel: eax: 00000000 ebx: c9b64000 ecx: cda90000 edx: 0000c19b
Aug 2 20:55:19 server kernel: esi: 00000000 edi: 00000000 ebp: 000007ff esp: c9b65f58
Aug 2 20:55:19 server kernel: ds: 0018 es: 0018 ss: 0018
Aug 2 20:55:19 server kernel: Process ps (pid: 28500, stackpage=c9b65000)
Aug 2 20:55:19 server kernel: Stack: cc1a2e00 cda90000 c0149227 cda90000 cc1a2e00 cda90000 000007ff c01494e4
Aug 2 20:55:19 server kernel: cda90000 cc19b000 00000000 ce599430 ffffffea 000007ff c13e5310 bffffb28
Aug 2 20:55:19 server kernel: cc19b000 c0130085 ce599430 bffff2ac 000007ff ce599450 c9b64000 bffff2ac
Aug 2 20:55:19 server kernel: Call Trace: [proc_pid_environ+15/108] [proc_info_read+84/264] [sys_read+149/224] [system_call+51/56]
Aug 2 20:55:19 server kernel:
Aug 2 20:55:19 server kernel: Code: f6 40 7c 01 75 14 b8 00 e0 ff ff 21 e0 f6 80 d6 01 00 00 08

[pdreker]

Das sind Kernel Crashes. Mit dem Programm ksymoops kannst aus diesen Dumps "decodierte" Backtraces machen, und so dann ehen, ob es immer an der gleichen Stelle crashed und wo genau. Wenn es immer an der gleichen Stelle passiert ist das wahrscheinlich ein Bug. Wenn das noch öfter vorkommt (und auch Anwendungen unberechenbar crashen) würde ich 'mal den Speicher testen.

Es kann auch passieren, dass nach einem Crash dieser einfach weitere Crashes an anderen Stellen im Kernel verursacht. Ich würde einfach 'mal rebooten, und das Problem beobachten...

Patrick

[MeTRiX]

habe jetzt mal rebootet ...

hoffe, dass es kein hardware defekt war - aber da es genau nach dem kernel update aufgetreten ist, bin ich optimistisch...

[bon]

hallo,
ich habe exakt das gleiche problem seit dem kernel-update. ein austauschen von ram brachte nichts. die kernelmeldungen tauchen weiter in unregelmäßigen abständen auf. ich bin noch nicht dahintergestiegen wer da schuld ist aber wenn es bei dir und vielleicht bei anderen auch auftritt, könnte es evtl. auch am kernel selbst liegen?

[pdreker]

Ja, kann es, ist aber nicht soo wahrscheinlich, aber es ist definitiv nicht ausgeschlossen!

Lies mein erstes Post nochmal, so kann man so ungefähr rausfinden, welcher Teil des Kernel das Problem ist (oder vielleicht den falschen CPU Typ angegeben?), und kann den dann deaktivieren, falls man ihn nicht braucht.

Patrick

[bon]

Ja, kann es, ist aber nicht soo wahrscheinlich, aber es ist definitiv nicht ausgeschlossen!

diese aussage ist ne eins

@pdreker
ich bin kein kernelfachmann und habe jetzt mal folgendes versucht. ich habe die fehlermeldung in eine datei geschrieben und dann:
'ksymoops datei' ausgeführt. da kamen für mich nur undefinierbare sachen
aber am ende stand da
1 warning issued. Results may not be reliable.

aber vielleicht wende ich das programm auch nur falsch an? vielleicht kannst du mir in dem punkt helfen? danke.

[pdreker]

Naja, je nach Konfig des Logging Systems ist es nicht direkt nötig ksymoops zu verwenden. Ausserdem hat ksymoops *immer* was zu meckern, normalerweise ist die Ausgabe aber OK.

ksymoops macht aus den Adressen in dem Call Trace (such 'mal in dem Oops nach den Worten Call Trace) die eigentlichen Funktionsnamen. Da kommt normalerweise dann etwas in der Form:

Code: Alles auswählen

Call Trace: [proc_pid_environ+15/108] [proc_info_read+84/264] [sys_read+149/224] [system_call+51/56] 

Das steht normalerweise ganz unten (vorletzte Zeile ungefähr). Wenn Du mehrer Oopse hast, ist nur das jeweils erste nach dem Reboot interessant. Die folgenden sind normalerweise nur "Fallout..

Wenn Du Dir diese dekodierten Call Traces anschaust, kann man oft aus den Namen der dort aufgeführten Funktionen auf den Teil des Kernel schliessen, in dem was schief geht.

Du kannst das Call Trace auch hier posten, aber *nur* in dekodierter Form, da man die Dekodierung nur auf der Maschine durchführen kann, auf der der Kernel läuft, oder die einen Kernel hat der *exakt* (sowohl Version, als auch die gesamte Konfiguration) identisch ist.

Ich bin allerdings momentan etwas im Stress (Klausuren) und ab Mittwoch bis nächste Sonntag nicht da. Falls keiner was dazu sagen kann, ping mich einfach mit einer PM an, ich schau dann nochmal...

Patrick

[MeTRiX]

http://lists.debian.org/debian-security ... 00162.html

neuer kernel

[bon]

yepp das wars, jetzt läufts wie es soll...