--On Thursday, April 21, 2005 07:30:49 PM -0400 Jason McCormick <[EMAIL PROTECTED]> wrote:
Attached is the 'SysRq t' output from the EL4 test box. The procedure I'm following here is:
touch S 1D244B3C 1472 3557 3513 (NOTLB) [<f94c9c4d>] afs_osi_SleepSig+0x87/0xd5 [libafs] [<f94c9e04>] afs_osi_Sleep+0x169/0x2cd [libafs] [<f94b0ed6>] afs_close+0x173/0x341 [libafs]
This appears to be blocked waiting for an 'afs_background' thread to service a store request (around line 886 of afs_vnop_store.c; There are no other osi_Sleep's in afs_close())
However, both of the afs_background processes appear to be idle, waiting for work (around line 1258 of afs_daemons.c):
afs_backgroun S 1D244B3C 3688 2454 1 2456 2452 (L-TLB)
[<f94c9c4d>] afs_osi_SleepSig+0x87/0xd5 [libafs]
[<f94c9e04>] afs_osi_Sleep+0x169/0x2cd [libafs]
[<f94903f0>] afs_BackgroundDaemon+0x243/0x298 [libafs]
afs_backgroun S 00000670 3336 2456 1 2458 2454 (L-TLB) [<f94c9c4d>] afs_osi_SleepSig+0x87/0xd5 [libafs] [<f94c9e04>] afs_osi_Sleep+0x169/0x2cd [libafs] [<f94903f0>] afs_BackgroundDaemon+0x243/0x298 [libafs]
This doesn't really make sense. It's possible that one or more of these threads is actually blocked on a lock (which running 'cmdebug <client>' will reveal if it is the case)
I suppose it's also possible that CONFIG_PREEMPT_VOLUNTARY is causing a problem, but
I think it is unlikely (there are no resched points inside ObtainXXXLock, so I don't see how they could race). If you want to make sure that isn't the problem, then either a) test on an smp kernel, or b) build afs with the following change. On or around line 206 of src/afs/LINUX/osi_machdep.h, change '#if defined(__KERNEL__) && defined(CONFIG_SMP)' to '#if defined(__KERNEL__)'. also change line 27 of src/rx/LINUX/rx_kmutex.h to '#if 1', and line 357 of src/rx/rx_prototypes.h to '#if defined(KERNEL) && defined(AFS_LINUX20_ENV)'
p7s1leJRA37zq.p7s
Description: S/MIME cryptographic signature
