"chas williams - CONTRACTOR" <[EMAIL PROTECTED]> writes: > usually the beginning of a traceback is a bit more important than the > end. can you tell us a bit more about the machine? cache partition > type, is it shared?, the options to afsd (yes again, for clarity), > number of processors, memory size.
The machine is a dual-processor opteron with 8GB ram. There's no separate cache partition, it's on the ext3 root partition (/dev/hda2). The afsd options are -stat 3600 -dcache 3600 -daemons 5 -volumes 196 -chunksize 20 -dynroot -fakestat -afsdb -nosettime -afsdb -dynroot I've put my init script, configuration files, and dmesg output in /afs/athena.mit.edu/user/a/r/arolfe/afs-bugs. I'll see if I can get a complete stack trace too. Anything else that'd be helpful to look at? >>libafs:exi_SendPacket:741 > > i am guessing that you are manually copying this down. there > is an rxi_SendPacket() but no exi_SendPacket(). yes, should be rxi. If there's a better way to capture the stack trace, I'd love to hear about it since it'd be much easier and give much better bug reports. The trace I sent from the -memcache oops looked funny because I only copied down the function names and excluded the addresses. Christopher Allen Wing <[EMAIL PROTECTED]> writes: > I can't reproduce this on a x86_64 SMP machine (hyperthreading P4). I've put my test files in /afs/csail.mit.edu/group/psrg/public. Running 'sum *' or 'cat * > /dev/null' in that directory triggers the problem. Alex _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
