--On Saturday, May 07, 2005 01:36:24 PM -0400 "John S. Bucy" <[EMAIL PROTECTED]> wrote:
That's backwards of how I interpret things, actually. 8715 is in the rx network code, waiting for a reply, and 8716 seems to be in down(&dir->i_sem) in real_lookup (inlined in do_lookup).Here's what I got. I can't make much of it and it seems a little garbled. PID 8715 is starving and PID 8716 is running.
I've cleaned up the traces below. The output you get from the kernel is not a true stack trace (unless frame pointers are enabled), but a listing of all the kernel text addresses found on the stack. I'm not sure why so much stuff is left on the stack, but it is.
statnr-rate S C03CDC88 0 8715 8700 (NOTLB) [<d8abde04>] afs_osi_SleepSig+0xb4/0xf0 [libafs] [<d8abde8d>] afs_osi_Sleep+0x4d/0x80 [libafs] [<d8aaf347>] rxi_ReadProc+0xe7/0x470 [libafs] [<d8aaf820>] rx_ReadProc32+0x80/0xe0 [libafs] [<d8ab468a>] xdrrx_getint32+0x1a/0x40 [libafs] [<d8aa2f2e>] xdr_afs_uint32+0x3e/0x40 [libafs] [<d8aa0f8f>] xdr_AFSFetchStatus+0x1f/0x220 [libafs] [<d8aa360a>] RXAFS_FetchStatus+0x17a/0x1c0 [libafs] [<d8a8bf2c>] afs_FetchStatus+0xbc/0x580 [libafs] [<d8a8a7a4>] afs_GetVCache+0x2b4/0x510 [libafs] [<d8a95837>] afs_lookup+0xd07/0x13f0 [libafs] [<d8ac09a7>] afs_linux_lookup+0x37/0x140 [libafs] [<c0157271>] real_lookup+0xc1/0xf0 [<c0157506>] do_lookup+0x96/0xb0 [<c0157aad>] link_path_walk+0x58d/0xb10 [<c015827e>] path_lookup+0x6e/0x120 [<c01584f3>] __user_walk+0x33/0x60 [<c015335f>] vfs_stat+0x1f/0x60 [<c0153aab>] sys_stat64+0x1b/0x40 [<c0102493>] syscall_call+0x7/0xb statnr-rate D C03CD7E0 0 8716 8706 (NOTLB) cc8ede08 00000082 d6305510 c03cd7e0 cc8ede30 00000008 d8a8cfd2 d6393800 [<c02cfaab>] __down+0x7b/0xd0 [<c02cfbff>] __down_failed+0x7/0xc [<c015ab4b>] .text.lock.namei+0x8/0x1dd [<c0157506>] do_lookup+0x96/0xb0 [<c0157aad>] link_path_walk+0x58d/0xb10 [<c015827e>] path_lookup+0x6e/0x120 [<c01584f3>] __user_walk+0x33/0x60 [<c015335f>] vfs_stat+0x1f/0x60 [<c0153aab>] sys_stat64+0x1b/0x40 [<c01d6112>] copy_to_user+0x42/0x60 [<c0102493>] syscall_call+0x7/0xb
I got similar results, as well as the following stack from an ls ls D C03605E0 0 20998 3600 (NOTLB) [<c0281f95>] __down+0x95/0x110 [<c0282158>] __down_failed+0x8/0xc [<c016839f>] .text.lock.readdir+0x5/0x16 [<c016835e>] sys_getdents64+0x6e/0xaa [<c0105fe9>] sysenter_past_esp+0x52/0x71
Which is presumably down(&inode->i_sem) in vfs_readdir() (the only down in readdir.c)
I can't say why the threads aren't switching off the way they should, but it's not afs's fault.
p7sIDtopK6EZ2.p7s
Description: S/MIME cryptographic signature
