Hello,
we are running OpenAFS 1.4.5 on a zLinux System (Novell SLES-9
distribution) and we see afs_cachetrim failing about once a weeknight
like this:
Feb 18 01:02:49 mclinx kernel: openafs: dcache hvkernel BUG at
/usr/src/packages/BUILD/openafs-1.4.5/obj/s390/src/libafs/MODLOAD-2.6
.5-7.287.3-s390x-MP/afs_dcache.c:719!
Feb 18 01:02:49 mclinx kernel: illegal operation: 0001 [#1]
Feb 18 01:02:49 mclinx kernel: CPU: 1 Tainted: PF U
(2.6.5-7.287.3-s390x SLES9_SP3_BRANCH-20071002073136)
Feb 18 01:02:49 mclinx kernel: Process afs_cachetrim (pid: 6092, task:
00000003d4bf9000, ksp: 00000003e1d437b0)
Feb 18 01:02:49 mclinx kernel: Krnl PSW : 0700000180000000 00000003fe45a3c2
(afs_HashOutDCache+0x25a/0x284 [libafs])
Feb 18 01:02:49 mclinx kernel: Krnl GPRS: 00000000000000f0 0000000000507fc0
0000000000000079 00000003e1d43970
Feb 18 01:02:49 mclinx kernel: 00000003fe45a3c0 000000000002740c
00000003fe508670 0000000000000000
Feb 18 01:02:49 mclinx kernel: 0000000300000001 00000003fe4f1ff8
00000000000000c8 00000003feaae9c0
Feb 18 01:02:49 mclinx kernel: 00000003fe445000 00000003fe4c8e50
00000003fe45a3c0 00000003e1d43a70
Feb 18 01:02:49 mclinx kernel: Krnl Code: 00 00 e3 10 b0 a6 00 90 a5 1b 00
02 42 10 b0 a6 a7 18 00 00
Feb 18 01:02:49 mclinx kernel: Call Trace:
Feb 18 01:02:49 mclinx kernel: [<00000003fe45ac9e>]
afs_GetDownD+0x79a/0x960 [libafs]
Feb 18 01:02:49 mclinx kernel: [<00000003fe45ea02>]
afs_CacheTruncateDaemon+0x196/0x5e8 [libafs]
Feb 18 01:02:49 mclinx kernel: [<00000003fe4bf7a4>]
afsd_thread+0x3c8/0x8e8 [libafs]
Feb 18 01:02:49 mclinx kernel: [<0000000000108b60>]
kernel_thread_starter+0x14/0x1c
Feb 18 01:02:49 mclinx kernel:
Unfortunately, I have no idea how to reproduce this situation and we can't
predict when it will happen next.
Looking at the source code we can spot the problem here:
/* remove entry from *other* hash chain */
i = DVHash(&adc->f.fid);
us = afs_dvhashTbl[i];
if (us == adc->index) {
/* first dude in the list */
afs_dvhashTbl[i] = afs_dvnextTbl[adc->index];
} else {
/* somewhere on the chain */
while (us != NULLIDX) {
if (afs_dvnextTbl[us] == adc->index) {
/* found item pointing at the one to delete */
afs_dvnextTbl[us] = afs_dvnextTbl[adc->index];
break;
}
us = afs_dvnextTbl[us];
}
if (us == NULLIDX)
osi_Panic("dcache hv"); <---------- this is the line 719 as
shown in the panic message
}
Well, I don't know what the DVHash is, but it looks like the
index which is found in the afs_dvhashTbl[] array which is
indicated by &adc->f.fid is containing the value "NULLIDX"
and it seems the routine afs_HashOutDCache() doesn't like
this at all.
My question is under which circumstances the cachetrim thread enters
this situation. Is there indeed no other way then calling osi_Panic()
to handle this?
The cachetrim crash is painful for us because we have to restart
the whole system whenever we face it.
With kind regards,
Carsten Jacobi (*120-4468)
Firmware Development in Böblingen
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
