Re: wie lese ich meine kerneldumps?

From: Alexander Klein <Alexander.Klein(at)physiologie.med.uni-giessen.de>
Date: Mon, 7 Nov 2016 11:19:34 +0100

Am 06.11.2016 um 23:20 schrieb Peter:

> Halten wir also fest: man baut ein SATA-SSD in den Rechner. Der
> fängt daraufhin an, ~zweimal am Tag panics zu produzieren. Man wird
> diese Panics nicht los (und ich hab zwischenzeitlich gut drei Viertel
> der Hardware testweise ausgewechselt, ohne dass sich am Fehlerbild
> was geändert hätte), ausser indem man für die SCSI-Platten das TCQ
> ausschaltet. Ist das bizarr oder ist das bizarr?

Hallo Peter,

das erinnert mich an eine Sache, die ich damals mit meinen alten
Apple-Systemen und Linux erlebt habe, ob 68k oder frühe PPC, daran kann
ich mich nicht mehr erinnern, jedenfalls:

Es war zu Zeiten, als SCSI-2-Platten schon knapp wurden, also habe ich
angefangen, alte Platten zu sammeln und bin auch zu zwei
Micropolis-SCSI-1-Platten gekommen, die am Mac immer problemlos ihren
Dienst verrichteten.

Unter Linux war es dann nur leider so, daß sie im Prinzip zwar auch
liefen, aber zwischendurch blieb irgendwann plötzlich das ganze System
stehen. Der Fehler blieb bis zur Entsorgung der Platten ungeklärt.

Die Frage ist halt, was man zu erreichen hoffen kann, denn der Fehler
kann sich ja im Prinzip überall verstecken:

– Es kann die Platte selbst sein, so wie früher schon mal:

http://www.computercraft.com/docs/qfbtmbug.shtml

– Wenn es Probleme in irgendwelchen Bridge-Chips sind, die in seltenen
Konstellationen auftreten, dann müßte man wohl den Datenverkehr auf dem
Bus analysieren; viel Arbeit.

– Wenn die Fehler von Timing-Problemen im Kernel kommen, könnte es
helfen, den Kernel mal mit einem anderen Compiler zu übersetzen, denn
schon simpelste Programme unterscheiden sich auf Assembler-Ebene
erheblich (links GCC, rechts CLANG):

         .file "helloworld.c" .file "helloworld.c"
         .section .rodata .text
.LC0: .globl main
         .string "Hello World!" .align 16, 0x90
         .text .type main,@function
         .globl main main:
         .type main, @function # BB#0:
main: pushl %ebp
.LFB1: movl %esp, %ebp
         .cfi_startproc subl $12, %esp
         pushl %ebp leal .L.str, %eax
         .cfi_def_cfa_offset 8 movl $0, -4(%ebp)
         .cfi_offset 5, -8 movl %eax, (%esp)
         movl %esp, %ebp calll printf
         .cfi_def_cfa_register 5 movl $0, %ecx
         andl $-16, %esp movl %eax, -8(%ebp)
         subl $16, %esp movl %ecx, %eax
         movl $.LC0, (%esp) addl $12, %esp
         call puts popl %ebp
         movl $0, %eax ret
         leave .Ltmp0:
         .cfi_restore 5 .size main, .Ltmp0-main
         .cfi_def_cfa 4, 4
         ret .type .L.str,@object
         .cfi_endproc .section .rodata.s
.LFE1: .L.str:
         .size main, .-main .asciz "Hello World!\n"
         .ident "GCC: (FreeBSD Po .size .L.str, 14
         .section .note.GNU

                                             .ident "FreeBSD clang ve
                                             .section ".note.GN

Was passiert denn, wenn Du den virtuellen Speicher zwar auf der Platte
hältst, aber statt in einer Partition in einer entsprechenden Datei?
Wenn die Maschine mehrere Kerne hat, könnte man versuchsweise alle bis
auf einen abschalten um zu sehen, ob es ein Parallelisierungsproblem ist?

Viele Grüße,

        Alexander

-- 
Alexander Klein
Physiologisches Institut der JLU-Gießen
Aulweg 129
35392 Gießen
http://www.med.uni-giessen.de/physio/
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 07 Nov 2016 - 11:20:18 CET

search this site