[OpenAFS-devel] [FOR TESTING] OpenAFS 1.3.87 RPMs for RHEL4 (i386, x86_64)

[Alex Rolfe]

"chas williams - CONTRACTOR" <chas@cmf.nrl.navy.mil> 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 <wingc@engin.umich.edu> 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