TARGET_ARCH=powerpc head -r317820 production-style kernel: periodic panics always in pid=11 (the Idle threads)

[Mark Millard]

On 2017-May-9, at 2:00 PM, Mark Millard <markmi at dsl-only.net> wrote:

. . .
> fatal kernel trap:
>   exception       = 0x903a64e (unknown)
>   srr0            = 0x7ff760
>   srr1            = 0xc1007c
>   lr              = 0x907f
>   curthread       = 0x147d6c0
>          pid = 11, comm = idle: cpu0
> [ thread pid 11 tid 100003 ]
> Stopped at      ffs_truncate+0x1080:    stw     r11, 0xf8(r31)
> 
> 1 contains (cpu1 instead of cpu0, so different tid):
> 
> fatal kernel trap:
>   exception       = 0x903a64e (unknown)
>   srr0            = 0x7ff760
>   srr1            = 0xc1007c
>   lr              = 0x907f
>   curthread       = 0x147d360
>          pid = 11, comm = idle: cpu1
> [ thread pid 11 tid 100004 ]
> Stopped at      ffs_truncate+0x1080:    stw     r11, 0xf8(r31)
> 
> 1 contains:

I've discovered where to find the trapframe
in the vmcore.* files for these specific
examples with 0x903a64e as the exception
and such.

In the vmcore the memory image starts at
byte offset 0x1000.

To see the values reported the only
place in the image file to start that
produces those values at the offsets
for in side the powerpc trapframe is:

offset 0x1001 in the vmcore.* file.

So memory address 0x1 is being used
as the trapframe address when that
odd exception information is being
displayed. Yep: misaligned.

The decoding is not of the actual
trapframe: it is garbage that is
not to be believed.


Note: I lucked out after the above and
got a somewhat different odd trap information
that lead to actually getting a backtrace
that included the actual pid 11 cpu 1 kernel
thread stack bt associated with that odd
information display.

I'll send a separate reply for that information
as it will take some transcribing from camera
pictures and such.

===
Mark Millard
markmi at dsl-only.net