wie lese ich meine kerneldumps?

Ja, wenn das so ist, dass hier noch fröhlicher Betrieb herrscht, dann
kann ich ja hier mal ein bischen rumjammern. *grins*

Da ist mir also so eine SSD Platte zugelaufen, oder ich hab sie irgendwo
mitbestellt um über den Mindestbestellwert zu kommen, oder so.
Jedenfalls lag sie dann ein halbes Jahr in der Ecke rum, und dann dachte
ich, ich könnte sie ja mal in meinen Desktop reinschrauben, als ZFS
cache. Das hat funktioniert, einen Performance-Unterschied hab ich nicht
gemerkt, und nach einem weiteren Vierteljahr war sie tot. Nicht mehr
erkennbar für den Controller, ausser dass er ne weile gesucht hat, also
ganz tot.
Merke: auch bei SSD ist ein mirror empfehlenswert, wenn man irgendwie
Nutzdaten drauftun will.

Jedenfalls hat man sie dann umgetauscht und mir eine hübsche neue
größere dafür geschickt.

Die hab ich jetzt in meinen alten Router reingesteckt, weil sie da
vielleicht wirklich was bringen könnte. Und dann gingen die kernel
panics los. Unregelmäßig, alle paar Tage.

Erstmal waren die nicht untersuchbar, weil es bei "Uptime: " stehenblieb
und weder gedumpt noch rebootet hat. (Effekt wie in Bug 211491, nur dass
das bei mir nur nach kernel panic auftritt - normaler reboot
funktioniert). Das war zu beheben indem der Kernel mit options SMP und
VESA (oder einem davon, das verhielt sich da etwas erratisch und liess
sich nicht genau ausmachen) kompiliert wird. Brauchen tu ich die
nicht, aber wenns hilft...
Von da an gabs dann immerhin einen automatischen Reboot - allerdings
keinen Dump, sondern die Meldung, dass die Platte, auf die gedumpt
werden soll (also das swap device auf der SSD, das mglw. schuld an der
Sache ist) I/O Error liefert. :(

Inzwischen ist der Status, dass es pro Nacht zwei panics gibt, einmal
statt dem Datenbank-Backup und einmal statt dem System-Backup, und jetzt
hab ich ein anderes dump-device eingestellt, sodass ich seit heute
morgen glücklicher Besitzer von zwei Kernel dumps bin. :)

Vor denen sitze ich jetzt grübelnd und versuche die Prozessorregister
zu verstehen. Der eine kommt aus cam/scsi, da wartet scheinbar postgres
grad drauf dass seine platte anläuft. Der andere kommt aus arc_buf_clone
im ZFS, da macht bacula offenbar einen inode-lookup.
Einmal supoervisor read, einmal supervisor write, page not present.

So recht schlüssig finde ich das noch nicht.

Looking closer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0e8616b
stack pointer = 0x28:0xf1a18304
frame pointer = 0x28:0xf1a18320
code segment = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 3012 (bacula-fd)
trap number = 12
panic: page fault
cpuid = 0

--- trap 0xc, eip = 0xc0e8616b, esp = 0xf1a18304, ebp = 0xf1a18320 ---
arc_buf_clone(c7f62380,f1a18380,3,80,c7f0f000,...) at
arc_buf_clone+0xb/frame 0xf1a18320
arc_read(ce55f2f8,c4d57000,c7f62380,c0e96f50,d36c4c38,...) at
arc_read+0x406/frame 0xf1a18390
dbuf_read(d36c4c38,0,2,c0fbd8f0,0,...) at dbuf_read+0x995/frame 0xf1a1841c
[usw.usf.]

(kgdb) x/10i 0xc0e86160
0xc0e86160 <arc_buf_clone>: push %ebp
0xc0e86161 <arc_buf_clone+1>: mov %esp,%ebp
0xc0e86163 <arc_buf_clone+3>: push %ebx
0xc0e86164 <arc_buf_clone+4>: push %edi
0xc0e86165 <arc_buf_clone+5>: push %esi
0xc0e86166 <arc_buf_clone+6>: sub $0x10,%esp
0xc0e86169 <arc_buf_clone+9>: mov %ecx,%edi
0xc0e8616b <arc_buf_clone+11>: mov (%edi),%ebx *CRASH*
0xc0e8616d <arc_buf_clone+13>: mov 0x24(%ebx),%eax
0xc0e86170 <arc_buf_clone+16>: mov %eax,-0x10(%ebp)
0xc0e86173 <arc_buf_clone+19>: mov 0xc0fe4884,%eax
0xc0e86178 <arc_buf_clone+24>: mov %eax,(%esp)
0xc0e8617b <arc_buf_clone+27>: movl $0x2,0x4(%esp)
0xc0e86183 <arc_buf_clone+35>: call 0xc1055ef0 <kmem_cache_alloc>

(kgdb) p $edi
$8 = 0x0
(kgdb) p $ecx
$9 = 0x0

Wo kommt die 0 her?

Ich konnte zwar mal Assembler (8bit), aber Compiler ist halt noch was
anderes. (Und nach meinem Handbuch -für iAPX88- wird beim mov der
*rechte* parameter in den *linken* gebracht, aber hier ist es offenbar
andersrum.) Ich täte jetzt meinen, der "sub" Befehl schafft platz auf
dem Stack für die lokalen Variablen der Funktion (0x10 für zwei Pointer
und einen int64), und die zwei mov danach gehören schon zur Funktion
selber. Was geht da ab?

arc_buf_clone(arc_buf_t *from)
{
         arc_buf_t *buf;
         arc_buf_hdr_t *hdr = from->b_hdr;
         uint64_t size = hdr->b_size;

         ASSERT(HDR_HAS_L1HDR(hdr));
         ASSERT(hdr->b_l1hdr.b_state != arc_anon);

         buf = kmem_cache_alloc(buf_cache, KM_PUSHPAGE);
         buf->b_hdr = hdr;
         buf->b_data = NULL;
         buf->b_efunc = NULL;

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 14 Oct 2016 - 00:13:16 CEST