Re: 4.01 panic/lock issues?

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

jcarr%poethecat.com@localhost wrote:

> Model: sun3 60
> fpu: mc68882
> 
> This may be part of the problem. It appears that at some point in the
> past life of this box, someone did the 68882 mod on it. I never caught
> this before since it was never a problem on past SunOS or NetBSD
> versions, but something here may be triggering it.

According to the Sun3 Archive page:
http://www.sun3arc.org/hardpatches/3.60-tuning/fpu.phtml
68882 is software compatible with 68881 (except CPI),
so I wonder if it could cause FPU related errors.
Actually I used 68882 on 3/60 about 13 years ago (with 1.1 or 1.2?)
and it worked fine with X11 etc.

> I compiled Manuel's GENERIC config to use as a baseline, and the system
> booted fine, as expected. Using INSTALL, 'mutt' tends to consistently
> cause a kernel panic, so I ran it again.

Hmm, does only the mutt binary cause the problem?
How did you install it? From packages in ftp.NetBSD.org?
If so, in which path?
What command (including option etc.) did you try when the panic happens?

I.e. how can we reproduce it with a certain procedure?

I've tried
# pkg_add ftp://ftp.jp.netbsd.org/pub/pkgsrc/packages/NetBSD/m68k/4.0/All/mutt
# mutt
on 3/80 running -current but it looks working at least until
it shows the first screen.
(though I should also try it on TME emulating 3/150 and running 4.0.1)

> db> tr
> cpu_Debugger(2000,8,ef57200,f9e9da0,f9e9e04) + 6
> panic(e198d79,3a,4,466,f9e9fb4) + 11a
> trap(f9e9e1c,8,145,4) + 244
> fpu_implode(e1bbe3c,0,2,f9e6118) + ac
> (f9e9fb4,f9e6040,f9e9f70) + 184e2
> trap(f9e9fb4,10,0,0) + 548
> fault() + 10

This indicates:
- some userland code causes a FP related error
  (fpu_implode() is in sys/arch/m68k/fpe/fpu_emulate.c and
   it could only be called via fpu_emulate(), which is invoked
   on "unimplemented FP instruction/data" trap)
- fpu_implode() seems to cause a NULL pointer dereference,
  which should not happen even if unimplemented FP instructions
  actually exist in binaries

I'm not sure unimlemented FPU trap could happen even with 68882.
One possibility is binaries compiled with -m68040 or 060 option,
but kernel shouldn't panic even in that case.

If you build a kernel without options FPU_EMULATE, I guess
it won't panic but shows "no floating point support",
as per src/sys/arch/sun3/sun3/trap.c.
---
Izumi Tsutsui