Kernel Panic Trap 12

[KB]

Well-Known Member
Seit einiger Zeit stürzt einer meiner Remote-Server in schöner Regelmäßigkeit mit folgender Fehlermeldung ab:

Nov 13 17:23:25 trema_srv kernel: Fatal trap 12: page fault while in kernel mode
Nov 13 17:23:25 trema_srv kernel: cpuid = 0; apic id = 00
Nov 13 17:23:25 trema_srv kernel: fault virtual address = 0x0
Nov 13 17:23:25 trema_srv kernel: fault code = supervisor write, page not present
Nov 13 17:23:25 trema_srv kernel: instruction pointer = 0x20:0xc0b54c76
Nov 13 17:23:25 trema_srv kernel: stack pointer = 0x28:0xd9baf750
Nov 13 17:23:25 trema_srv kernel: frame pointer = 0x28:0xd9baf78c
Nov 13 17:23:25 trema_srv kernel: code segment = base 0x0, limit 0xfffff, type 0x1b
Nov 13 17:23:25 trema_srv kernel: = DPL 0, pres 1, def32 1, gran 1
Nov 13 17:23:25 trema_srv kernel: processor eflags = interrupt enabled, resume, IOPL = 0
Nov 13 17:23:25 trema_srv kernel: current process = 6539 (find)
Nov 13 17:23:25 trema_srv kernel: trap number = 12
Nov 13 17:23:25 trema_srv kernel: panic: page fault
Nov 13 17:23:25 trema_srv kernel: cpuid = 0
Nov 13 17:23:25 trema_srv kernel: KDB: stack backtrace:
Nov 13 17:23:25 trema_srv kernel: #0 0xc0af3e5f at kdb_backtrace+0x4f
Nov 13 17:23:25 trema_srv kernel: #1 0xc0ac088f at panic+0x16f
Nov 13 17:23:25 trema_srv kernel: #2 0xc0e25493 at trap_fatal+0x323
Nov 13 17:23:25 trema_srv kernel: #3 0xc0e2559b at trap_pfault+0xfb
Nov 13 17:23:25 trema_srv kernel: #4 0xc0e2650a at trap+0x44a
Nov 13 17:23:25 trema_srv kernel: #5 0xc0e0faec at calltrap+0x6
Nov 13 17:23:25 trema_srv kernel: #6 0xc0b58bcb at vnlru_free+0x2bb
Nov 13 17:23:25 trema_srv kernel: #7 0xc0b58d19 at getnewvnode+0x69
Nov 13 17:23:25 trema_srv kernel: #8 0xc0d00b39 at ffs_vgetf+0x109
Nov 13 17:23:25 trema_srv kernel: #9 0xc0d0100e at ffs_vget+0x2e
Nov 13 17:23:25 trema_srv kernel: #10 0xc0d0ee94 at ufs_lookup_ino+0xb04
Nov 13 17:23:25 trema_srv kernel: #11 0xc0d0ef2a at ufs_lookup+0x2a
Nov 13 17:23:25 trema_srv kernel: #12 0xc0e466a2 at VOP_CACHEDLOOKUP_APV+0x42
Nov 13 17:23:25 trema_srv kernel: #13 0xc0b403f6 at vfs_cache_lookup+0xe6
Nov 13 17:23:25 trema_srv kernel: #14 0xc0e48926 at VOP_LOOKUP_APV+0x46
Nov 13 17:23:25 trema_srv kernel: #15 0xc0b4836e at lookup+0x6ae
Nov 13 17:23:25 trema_srv kernel: #16 0xc0b49476 at namei+0x676

Wobei das verursachende Programm variiert (rm und find). Die Reihenfolge der aufgerufenen Funktionen scheint jedoch immer die gleiche zu sein. Nach vnlru_free wird der Trap ausgelöst.

Nun meine Frage:

Deutet dies auf ein Problem mit dem Dateisystem (hier auf RAID1 bzw. RAID5) hin? Oder kann dieser Fehler z.B. auch durch ein defektes RAM-Modul ausgelöst werden, da auch die angegebene Adresse "0xc0b58bcb at vnlru_free+0x2bb" immer die Gleiche zu sein scheint?
Evtl. hat hier ja schon jemand Erfahrungen gesammelt.
 
Theoretisch kann es beides sein. Aber das riecht schon sehr nach einem defekten Dateisystem. Er sucht eine Inode (ufs_lookup_ino), liest sie ein (ffs_vgetf), übergibt sie ans VFS (getnewvnode), das VFS versucht sofort eine Vnode freizuräumen (vnlru_free) und *kabumm* (calltrap). Die offensichtliche Erklärung ist, dass das Dateisystem etwas ans VFS übergeben hat, woran es sich verschluckt. Weniger offensichtlich oder möglich wäre, dass der Kernelspeicher korrumpiert ist. Weit hergeholt aber möglich, dass er keiner Vnodes mehr hat und aus obskuren Gründen auch keine Abräumen kann. Lange Rede, kurzer Sinn: Mache erstmal ein fsck.
 
Danke, Yamagi! Check läuft...

[EDIT]
fsck hat tatsächlich was gefunden (und zwar auf dem System-Raid):

** /dev/mirror/root (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=1126451 (4224 should be 4160)
CORRECT? no

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

639407 files, 2807860 used, 6146607 free (3959 frags, 767831 blocks, 0.0% fragmentation)

Bleibt abzuwarten, ob es wieder knallt...
[/EDIT]
 
Ich sehe gerade, dass die Fehler ja gar nicht behoben wurden, da die Platten in Benutzung sind.
Wie teile ich dem System mit die Fehler mit dem nächsten Systemstart zu beseitigen?
 
In die rc.conf die folgende Zeile:
Code:
fsck_y_enable="YES"

Bestätigt alle Anfragen von fsck automatisch mit Yes
 
So, rc.conf angepasst und Server neugestartet und noch einmal fsck manuell aufgerufen.
Und jetzt neue Fehler:

** /dev/mirror/root (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
UNALLOCATED I=1123665 OWNER=www MODE=100660
SIZE=0 MTIME=Nov 16 20:37 2013
FILE=/var/spool/clientmqueue/dfrAGJb0n7001775

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

UNALLOCATED I=1123677 OWNER=www MODE=100660
SIZE=0 MTIME=Nov 16 20:37 2013
FILE=/var/spool/clientmqueue/qfrAGJb0n7001775

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

UNALLOCATED I=1123679 OWNER=root MODE=100600
SIZE=0 MTIME=Nov 16 20:37 2013
FILE=/var/spool/mqueue/dfrAGJb0QI001776

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

UNALLOCATED I=1123688 OWNER=root MODE=100600
SIZE=0 MTIME=Nov 16 20:37 2013
FILE=/var/spool/mqueue/qfrAGJb0QI001776

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? no

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
LINK COUNT FILE I=1123644 OWNER=root MODE=0
SIZE=0 MTIME=Nov 16 20:37 2013 COUNT 0 SHOULD BE -1
ADJUST? no

LINK COUNT FILE I=1123655 OWNER=www MODE=0
SIZE=0 MTIME=Nov 16 20:36 2013 COUNT 0 SHOULD BE -1
ADJUST? no

LINK COUNT FILE I=1123656 OWNER=root MODE=0
SIZE=0 MTIME=Nov 16 20:36 2013 COUNT 0 SHOULD BE -1
ADJUST? no

LINK COUNT FILE I=1123685 OWNER=root MODE=0
SIZE=0 MTIME=Nov 16 20:36 2013 COUNT 0 SHOULD BE -1
ADJUST? no

** Phase 5 - Check Cyl groups
ALLOCATED FILE 1123644 MARKED FREE
ALLOCATED FILES 1123655-1123656 MARKED FREE
ALLOCATED FILE 1123685 MARKED FREE
BLK(S) MISSING IN BIT MAPS
SALVAGE? no

639169 files, 2807602 used, 6146874 free (4130 frags, 767843 blocks, 0.0% fragmentation)

Ich verzweifle gleich...
Könnte das mit der Spiegelung durch gmirror zusammenhängen?
 
Du hattest aber nicht mal zwischendurch nur ein einzelnes Device des Mirrors rw gemounted oder?
 
nach einem fsck_y_flags="-f" und einem Neustart kamen weitere Fehlermeldungen hinzu:

** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=1123675 (8 should be 0)
CORRECT? no

INCORRECT BLOCK COUNT I=2418304 (8 should be 0)
CORRECT? no

INCORRECT BLOCK COUNT I=2418305 (8 should be 0)
CORRECT? no

INCORRECT BLOCK COUNT I=2418306 (8 should be 0)
CORRECT? no

INCORRECT BLOCK COUNT I=2418307 (8 should be 0)
CORRECT? no

:grumble:
 
** /dev/mirror/root (NO WRITE) -> Er kann das Dateisystem nicht prüfen, da es noch immer irgendwo eingehängt ist. Und solange es das ist, wird es auch inkonsistent sein. Gemountete Dateisysteme sind niemal konsistent. :) Es sollte reichen, im Single User Mode direkt als erstes Kommando "fsck -y" einzutippen, damit er alle prüft. Wenn das nicht klappt, bleibt nur die Live-CD.
 
Das ist mir ehrlich gesagt noch nie aufgefallen, aber durchaus nachvollziehbar.
Jetzt ist der Server erst einmal wieder down.
Um die Uhrzeit möchte ich aber die IT vor Ort nicht mehr mit meinem Problem belästigen.
Geht also erst morgen weiter...

Vielen Dank für Eure Unterstützung!
 
Zurück
Oben