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.
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.