I have reproducible kernel panic with amanda Network Disk Archiver. panic: trap: fast instruction access mmu miss cpuid = 0 KDB: enter: panic [thread pid 12 tid 100006 ] Stopped at kdb_enter+0x3c: ta %xcc, 1 db> bt Tracing pid 12 tid 100006 td 0xfffff800bfa3b0a0 panic() at panic+0x160 trap() at trap+0x390 -- fast instruction access mmu miss tar=0 %o7=0xc00512dc -- db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd [...] 12 fffff800bfa393e0 0 0 0 000020c [CPU 0] idle: cpu0 [...] db> show intrcnt ??? 2 stray 1 pil4: ast 2289936 pil5: stop 1 pil13: fast 16560 pil2: ithrd 4488976 vec2027: puc0 166 vec2025: uart2 7746 vec2026: uart3 8814 vec2020: pcm0 123652 vec2017: hme0 3769678 vec2016: sym0 590176 vec2022: sym1 15568 vec2000: fwohci0+ 1 pil14: tick 24242583 db> show pcpu cpuid = 0 curthread = 0xfffff800bfa3b0a0: pid 12 "idle: cpu0" curpcb = 0xe0429980 fpcurthread = none idlethread = 0xfffff800bfa3b0a0: pid 12 "idle: cpu0" Backtrace: #13 0x00000000c0365b58 in trap (tf=0xe04292c0) at /usr/src/sys/sparc64/sparc64/trap.c:369 #14 0x00000000c0050fc0 in tl1_trap () #15 0x0000000000000000 in ?? () #16 0x00000000c00512e4 in intr_fast () at /usr/src/sys/sparc64/sparc64/interrupt.S:193 (kgdb) frame 13 #13 0x00000000c0365b58 in trap (tf=0xe04292c0) at /usr/src/sys/sparc64/sparc64/trap.c:369 369 panic("trap: %s", trap_msg[tf->tf_type & ~T_KERNEL]); (kgdb) p/x tf[0] $1 = {tf_global = {0xc0358b24, 0x2, 0xfffff800bfa3b0a0, 0xfffff800bfa3b0a0, 0x4, 0xc048b800, 0xe0429980, 0xc04d67b8}, tf_out = {0x0, 0x0, 0x0, 0xc0487758, 0x2fac, 0xc0487758, 0xe0428bc1, 0xc00512dc}, tf_fprs = 0xc04cf7b0, tf_fsr = 0xc04cf7b0, tf_gsr = 0x7e1, tf_level = 0x0, tf_pil = 0x2, tf_sfar = 0x0, tf_sfsr = 0x0, tf_tar = 0x0, tf_tnpc = 0x4, tf_tpc = 0x0, tf_tstate = 0x9915001602, tf_type = 0x62, tf_y = 0x0, tf_wstate = 0x5ea, tf_pad = {0x0, 0x0}} (kgdb) frame 16 #16 0x00000000c00512e4 in intr_fast () at /usr/src/sys/sparc64/sparc64/interrupt.S:193 193 mov %o1, %o0 Current language: auto; currently asm (kgdb) l 188 stx %l0, [PCPU(IRFREE)] 189 190 wrpr %g0, PSTATE_KERNEL, %pstate 191 192 FAULT ---> call %o0 # $o0 == 0, Why? 193 mov %o1, %o0 194 ba,a %xcc, 1b 195 nop 196 END(intr_fast) (kgdb) x/4i 0xc00512dc 0xc00512dc <intr_fast+124>: call %o0 0xc00512e0 <intr_fast+128>: mov %o1, %o0 0xc00512e4 <intr_fast+132>: b,a %xcc, 0xc0051264 <intr_fast+4> 0xc00512e8 <intr_fast+136>: nop How-To-Repeat: Run amdump. Keyboard or mouse activity lead to a kernel panic.
With following workaround the kernel does not a panic: --- interrupt.S.diff begins here --- --- sys/sparc64/sparc64/interrupt.S.orig Sat Apr 16 19:05:56 2005 +++ sys/sparc64/sparc64/interrupt.S Thu Mar 30 13:35:18 2006 @@ -159,7 +159,7 @@ ret restore -2: wrpr %g0, PSTATE_NORMAL, %pstate +2: /* wrpr %g0, PSTATE_NORMAL, %pstate */ ldx [%l0 + IR_NEXT], %l1 brnz,pt %l1, 3f --- interrupt.S.diff ends here --- Whether it is necessary to do interrupt handler queue operations (add to queue/remove from queue) as atomic? -- Andrew Belashov
Previous experimental patch is bad. Don't use it! I have understood the reason of a panic. The keyboard, mouse and other uart interrupts have greater PIL than the others. When the intr_fast() processes interrupt request queue, new interruption comes from mouse or keyboard. In that case, some interruptions from queue can be processed twice... Please commit following patch and close the PR. -- With Best Regards, Andrew Belashov.
Responsible Changed From-To: freebsd-sparc64->marius grab
State Changed From-To: open->closed Close; the fix was committed as part of sys/sparc64/sparc64/interrupt.S 1.9, MFC'ed to RELENG_6 in 1.8.2.1 and to RELENG_6_1 in 1.8.6.1. Thanks for the report and patch!