On Wed, 9 Mar 2022 11:01:04 +0100
Alexander Bluhm <[email protected]> wrote:
> dar 0xfffffffffd7f0020 dsisr 0x40000000
> trap type 300 srr1 9000000000009032 at 1411eb8 lr 1411e94
> Stopped at pool_do_get+0xa8: ld r4,32(r27)
The kernel failed to read an unmapped page, so ddb has stopped the
kernel. Here's "objdump -dlr subr_pool.o" with my comments,
/usr/src/sys/kern/subr_pool.c:720
# ph = pp->pr_curpage; # r30 = pp
2170: eb 7e 00 50 ld r27,80(r30) # r27 = ph
/usr/src/sys/kern/subr_pool.c:721
# pi = XSIMPLEQ_FIRST(&ph->ph_items);
2174: 7f 63 db 78 mr r3,r27
2178: e8 9b 00 20 ld r4,32(r27) # r4 = sqx_cookie
217c: e8 a3 00 11 ldu r5,16(r3) # r5 = sqx_first
2180: 7c 9d 2a 79 xor. r29,r4,r5
> r27 0xfffffffffd7f0000
> r30 0x1b58aa0 uvm_map_entry_pool
So pp = &uvm_map_entry_pool was valid, but ph = pp->pr_curpage pointed
outside mapped memory; kernel can't read XSIMPLEQ's cookie.
> ddb{1}> mach ddbcpu 0
> hangs the machine
I struggle to guess why this was hanging. I want to believe that
cpu0 can enter ddb, because cpu1 recently entered ddb, so the pages
for entering ddb should still be mapped.
I have not seen any crash like this on powerpc64. Maybe we can't
learn more, unless the crash will happen more often.
I saw 2 of "panic: biodone already" in bsd.rd on powerpc64. The 1st
was on 2020 Sep 4, but the 2nd was on 2022 Jan 17, more than a year
later. There's no ddb in bsd.rd, so I learned almost nothing.
--George
