On Friday, October 21, 2005 01:09:37 AM +0000 Andy Lutomirski
<[EMAIL PROTECTED]> wrote:
Here's the OOPS:
----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at "/var/tmp/portage/openafs-kernel-1.4.0_rc6/work/op:131
invalid operand: 0000 [1] PREEMPT
CPU 0
Modules linked in: libafs ipt_conntrack iptable_nat ipt_REJECT ipt_state
ip_conntrack ipt_multiport iptable_filter ip_tables snd_pcm_oss
snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
snd_cs4281 snd_opl3_lib snd_hwdep snd_via82xx snd_ac97_codec snd_pcm
snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd
soundcore xfs raid5 xor raid0
Pid: 1007, comm: ls Tainted: P 2.6.13-gentoo-r3
RIP: 0010:[<ffffffff8818a250>] <ffffffff8818a250>{:libafs:osi_Panic+0}
This is the key line -- it says the oops occurred inside osi_Panic,
which is not surprising since the entire point of that routine is to
generate an oops. The interesting information is whatever was printed
out (in dmesg, or syslog) right _before_ the oops. That's where the
message is that will tell us _why_ OpenAFS is panicing.
Call Trace:<ffffffff881953a8>{:libafs:osi_UFSOpen+440}
Well, there are only two calls to osi_Panic in osi_UFSOpen. I'm going to
make an intelligent guess as to which one it is, and say that
osi_AllocLargeSpace failed, indicating a failure to allocate memory.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
