Hallo,
habe folgendes Problem:
Ein installiertes FreeBSD 7.1 64Bit mit vier 1.5 TB-Platten in einem ZPOOL
Gestern wollte ich ein paar ISO-Dateien in das Pool-Verzeichnis schreiben (habe ich früher auch schon gemacht und hat immer geklappt). Das Ergebns sah so (/var/log/mesages) aus:
Mar 29 11:06:17 server syslogd: kernel boot file is /boot/kernel/kernel
Mar 29 11:06:17 server kernel: ad10: FAILURE - device detached
Mar 29 11:06:17 server kernel: subdisk10: detached
Mar 29 11:06:17 server kernel: ad10: detached
Mar 29 11:06:17 server kernel:
Mar 29 11:06:17 server kernel:
Mar 29 11:06:17 server kernel: Fatal trap 12: page fault while in kernel mode
Mar 29 11:06:17 server kernel: cpuid = 1; apic id = 01
Mar 29 11:06:17 server kernel: fault virtual address = 0x50
Mar 29 11:06:17 server kernel: fault code = supervisor write data, page not present
Mar 29 11:06:17 server kernel: instruction pointer = 0x8:0xffffffff804a8465
Mar 29 11:06:17 server kernel: stack pointer = 0x10:0xffffffffac26cbc0
Mar 29 11:06:17 server kernel: frame pointer = 0x10:0xffffffffac26cc00
Mar 29 11:06:17 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b
Mar 29 11:06:17 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1
Mar 29 11:06:17 server kernel: processor eflags = interrupt enabled, resume, IOPL = 0
Mar 29 11:06:17 server kernel: current process = 3 (g_up)
Mar 29 11:06:17 server kernel: trap number = 12
Mar 29 11:06:17 server kernel: panic: page fault
Mar 29 11:06:17 server kernel: cpuid = 1
Mar 29 11:06:17 server kernel: Uptime: 18m43s
Mar 29 11:06:17 server kernel: Physical memory: 4066 MB
Mar 29 11:06:17 server kernel: Dumping 583 MB
Der Fehler ließ sich (wie an den Zeitstempeln zu sehen) ohne größere Probleme reproduzieren.
Ich habe darauf ein dd if=/dev/zero | split -b 2000m - test. gefeuert - Ergebnis: Nach ca. 8 GB hörte ich, wie eine platte anfing zu "klicken"; im Syslog konnte ich die Zeile "TIMEOUT - FLUSHCACHE retrying (1 retry left)" erkennen. Das dd konnte ich noch abbrechen, bevor mein Kernel wieder eine Panic gekriegt hat.
Da Schreibzugriffe auf den ZPOOL bisher immer geklappt haben und die Platte (wenn man smartctl glauben kann) völlig "gesund" ist (sie ist auch nicht mal ein halbes jahr alt), bin ich allmählich mit meinem Latein am Ende.
Über Tips, wie ich die Panics verhindern kann (klar: keine Daten mehr schreiben) wäre ich entsprechend dankbar.
Fiffi
PS: Einen Wackelkontakt in den Kabeln schließe ich aus; ich benutze den GENERIC-Kernel. Hoffe, diese Angaben reichen...
habe folgendes Problem:
Ein installiertes FreeBSD 7.1 64Bit mit vier 1.5 TB-Platten in einem ZPOOL
Gestern wollte ich ein paar ISO-Dateien in das Pool-Verzeichnis schreiben (habe ich früher auch schon gemacht und hat immer geklappt). Das Ergebns sah so (/var/log/mesages) aus:
Mar 29 11:06:17 server syslogd: kernel boot file is /boot/kernel/kernel
Mar 29 11:06:17 server kernel: ad10: FAILURE - device detached
Mar 29 11:06:17 server kernel: subdisk10: detached
Mar 29 11:06:17 server kernel: ad10: detached
Mar 29 11:06:17 server kernel:
Mar 29 11:06:17 server kernel:
Mar 29 11:06:17 server kernel: Fatal trap 12: page fault while in kernel mode
Mar 29 11:06:17 server kernel: cpuid = 1; apic id = 01
Mar 29 11:06:17 server kernel: fault virtual address = 0x50
Mar 29 11:06:17 server kernel: fault code = supervisor write data, page not present
Mar 29 11:06:17 server kernel: instruction pointer = 0x8:0xffffffff804a8465
Mar 29 11:06:17 server kernel: stack pointer = 0x10:0xffffffffac26cbc0
Mar 29 11:06:17 server kernel: frame pointer = 0x10:0xffffffffac26cc00
Mar 29 11:06:17 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b
Mar 29 11:06:17 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1
Mar 29 11:06:17 server kernel: processor eflags = interrupt enabled, resume, IOPL = 0
Mar 29 11:06:17 server kernel: current process = 3 (g_up)
Mar 29 11:06:17 server kernel: trap number = 12
Mar 29 11:06:17 server kernel: panic: page fault
Mar 29 11:06:17 server kernel: cpuid = 1
Mar 29 11:06:17 server kernel: Uptime: 18m43s
Mar 29 11:06:17 server kernel: Physical memory: 4066 MB
Mar 29 11:06:17 server kernel: Dumping 583 MB
Der Fehler ließ sich (wie an den Zeitstempeln zu sehen) ohne größere Probleme reproduzieren.
Ich habe darauf ein dd if=/dev/zero | split -b 2000m - test. gefeuert - Ergebnis: Nach ca. 8 GB hörte ich, wie eine platte anfing zu "klicken"; im Syslog konnte ich die Zeile "TIMEOUT - FLUSHCACHE retrying (1 retry left)" erkennen. Das dd konnte ich noch abbrechen, bevor mein Kernel wieder eine Panic gekriegt hat.
Da Schreibzugriffe auf den ZPOOL bisher immer geklappt haben und die Platte (wenn man smartctl glauben kann) völlig "gesund" ist (sie ist auch nicht mal ein halbes jahr alt), bin ich allmählich mit meinem Latein am Ende.
Über Tips, wie ich die Panics verhindern kann (klar: keine Daten mehr schreiben) wäre ich entsprechend dankbar.
Fiffi
PS: Einen Wackelkontakt in den Kabeln schließe ich aus; ich benutze den GENERIC-Kernel. Hoffe, diese Angaben reichen...