[OpenAFS-devel] OpenAFS 1.4.0 rc3 crashes on Linux 2.6

Jeffrey Hutzelman jhutz@cmu.edu
Mon, 24 Oct 2005 00:17:23 -0400


On Friday, October 21, 2005 01:09:37 AM +0000 Andy Lutomirski 
<amluto@hotmail.com> 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) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA