Hi Matt,

Do you actually get an OOP's, i.e. a kernel level segfault or do you get a
user level one. You can find this out looking at /var/log/messages.

If it is _that_ reproducible, could you do
echo 4095 > /proc/sys/coda/debug
echo 1 > /proc/sys/coda/trace
and get us the content of /var/log/messages.

- Peter -







I updated to 2.2.10 and built the new coda module but am still experiencing
the
same problems.
I think the freezing I am seeing is related to not being able to unmount
coda.
If I do a ctrl-alt-del
shutdown starts but doesn't complete. The only way out I have found at that
time
is to power
cycle.

Is it worthwhile to try compiling a bleeding edge venus? I'm not familiar
with
the mechanism
being used to make venus available for debugging when it dies. Is there a
way I
can detect
that venus died in a script and execute a clean up and restart venus or do a
clean reboot?

Matt
--


On Tue, Jun 15, 1999 at 03:42:52PM -0400, mattwell_at_us.ibm.com wrote:
>
> I am having some problems with venus. Creating files from
> some applications causes venus to die (go into the mode
> waiting for debugging). I can copy files, touch files, and create
> them with vi but if I try to use xemacs or Star Office venus dies
> and I have to reboot (can't login at another VT but the mouse
> still works - usually). Often I can't even reboot and I have to
> kill the power.

Hi Matt,

Venus 5.2.0 has a known null-pointer dereference problem, which is
triggered by all operations that attempt to create a new directory
entry. This is annoying, but cannot cause a complete system lockup.

A lockup like this would indicate that something is wrong with the
kernel code. Could you try to update your kernel to linux-2.2.10, and
combine that with a new Coda kernel module built from:
  ftp.coda.cs.cmu.edu:/pub/coda/src/linux-coda-5.2.3-linux2.2.9.tgz

There are a couple of fixes in our version wrt. to the one in the
official kernel tree, those seem to have solved at least one
(infrequent) lockup we noticed here on a SMP machine.

Jan