Awesome! Ok, I switched back to master, did a git pull, then rebased my topic on origin/master and recompiled. We got further, but still panic:
# /opt/openafs/sbin/afsd -stat 300 -dcache 100 -daemons 2 -volumes 50 afs: Binding rx to 0.0.0.0:7001 Starting AFS cache scan...afsd: All AFS daemons started. Here's the stack trace from the kernel dump: CRASH INFORMATION: CPU 0 CSA F00000002FF47600 at time of crash, error code for LEDs: 30000000 pvthread+01B000 STACK: [F1000000C04A2DB0]afs_mount+0001F0 (F1000A03E0251110, F1000A03E0911C7C, F1000000C04A2BC0) [F1000000C0499CB0]vfs_mount+000090 (F1000A03E0251110, F1000A03E0911C7C) [00014D70].hkey_legacy_gate+00004C () [006155AC]vfs_mount+00002C (??, ??) [00701D7C]smount+0004FC (??) [00702AC8]vmount+000248 (??, ??) [00003888]mfspurr_sc_flih01+0000E4 () [kdb_get_virtual_memory] no real storage @ 2FF1F4F8 [10001918]10001918 () [kdb_read_mem] no real storage @ FFFFFFFFFFF6130 And here's the mst: Machine State Save Area iar : F1000000C04A2DB0 msr : 8000000000009032 cr : 22222024 lr : F1000000C04A2D78 ctr : 0000000000043740 xer : 20000008 mq : DEADBEEF asr : FFFFFFFFFFFFFFFF amr : 0008C00000000000 r0 : F1000000C04A2D78 r1 : F00000002FF471F0 r2 : F1000000C05955A0 r3 : 0000000000000001 r4 : 0000000000000000 r5 : 000000000000000D r6 : F1000A03E0911C7C r7 : 0000000000000000 r8 : 0000000000000000 r9 : 0000000000000007 r10 : 003B32F62EFD4E61 r11 : 0008C00000000000 r12 : 0000000000014F54 r13 : F1000A03E04A1400 r14 : 0000000000000009 r15 : 000000002FF22CAC r16 : 000000002FF22CD4 r17 : 00000000DEADBEEF r18 : 00000000DEADBEEF r19 : 00000000000034E0 r20 : FFFFFFFFFFFFFFFF r21 : FFFFFFFFFFFFFFFF r22 : F1000A03E0251110 r23 : F3FCC00000000000 r24 : 00000000009EA3A8 r25 : 0000000000000000 r26 : 0000000000000001 r27 : FFFFFFFFFFFFFFFF r28 : 0000000000000000 r29 : 0000000000000000 r30 : 0000000000000000 r31 : F1000000C0560B10 prev 0000000000000000 stackfix 0000000000000000 int_ticks 0000 cfar F1000000C04A2B7C kjmpbuf 0000000000000000 excbranch 0000000000000000 no_pfault 00 intpri 0B backt 00 flags 00 hw_fru_id 00000000 hw_cpu_id 00000000 fpscr 0000000000000000 fpscrx 00000000 fpowner 00 fpeu 01 fpinfo 00 alloc F000 o_iar F1000000C04A2DB0 o_toc F1000000C05955A0 o_arg1 0000000000000001 o_vaddr 0000000000000004 krlockp 0000000000000000 rmgrwa F1000816B0035E20 amrstackhigh F00000002FFCCFF0 amrstacklow F00000002FFCC000 amrstackcur F00000002FFCCFE0 amrstackfix 0000000000000000 kstackhigh 0000000000000000 kstacksize 00000000 frrstart 700DFEED00000000 frrend 700DFEED00000000 frrcur 700DFEED00000000 frrstatic 0000 kjmpfrroff 0000 frrovcnt 0000 frrbarrcnt 0000 frrmask 00 callrmgr 00 Except : excp_type 00000086 EXCEPT_PROT orgea 0000000000000004 dsisr 000000000A000000 bit set: DSISR_PROT DSISR_ST vmh 0000000010002510 curea 0000000000000004 pftyp 4000000000000106 Looks like we're getting close now! Thanks! -Ben ________________________________ From: Benjamin Kaduk <ka...@mit.edu> Sent: Tuesday, August 16, 2022 8:46 AM To: Ben Huntsman <b...@huntsmans.net> Cc: Jeffrey E Altman <jalt...@auristor.com>; openafs-devel@openafs.org <openafs-devel@openafs.org> Subject: Re: [OpenAFS-devel] Latest build kernel panic on AIX 6.1 6100-09-12 On Tue, Aug 16, 2022 at 03:19:39PM +0000, Ben Huntsman wrote: > Hey there! > Thank you, I will give that a try. > > Dumb question though, how do I cherry-pick that commit into my topic > branch? Well ... in this case, since it was a simple+obvious fix I already merged it into master, so you can just re-fetch the tip of master. But in the general case, you'd need to be managing patches locally, presumably with cherry-pick. (The project in general uses a cherry-pick-based workflow; the only times I remember using merge commits are in the aftermath of security releases, e.g., if I need to make a release that's "previous release plus security fix" but the existing release branch is not suitable, and then I merge the security-fix branch back in.) Gerrit exposes each revision of each changeset as a distinct ref that's fetchable -- in the upper right of the page there's a "Download" dropdown that gives the command to fetch and checkout/cherry-pick/etc. the specific change in question. I'll also note that often a given change in gerrit is part of a stack of changes, so you may need to grab predecessor commits as well as the named one (but this one was standalone). -Ben
