Re: 4.01 panic/lock issues?

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

Bolo wrote:

> The size of the floating point save context can be different.
> If the kernel was only compiled with code for the 68881 floating point
> save size, a larger 68882 context could overflow into something else.
> 
> It won't matter for executables that don't use floating point, because
> of the only-save-if-used fp code.

Yes, I think that's the way how src/sys/arch/sun3/sun3/fpu.c
detects 68881 or 68882.  I guess MI m68k code will handle
frame size by "fpu_type" variable since 3/80 (68030+68882)
uses the same fpu.c.

> Mutt probably does some floating point arith for, which
> makes a save-context be generated on context switch, and boom,
> something dies.
> 
> To try and reproduce it just have something that does a floating
> point op, and context switches -- ato[df] or printf("%f") might be
> enough to trigger it.

Many simple commands (like ps(1)) uses FP ops so if FP instructions
don't work completely it's unlikely to boot up to multiuser.
(see "LC040 FPE problem" on mac68k port page)

In this case, unimplemented FP instruction trap happens
even though the machine has 68020+68882.

The trap invokes FP emulation functions, but I'm afraid
the FPE functions might not be initialized if the machine
has an FPU, so it might cause NULL pointer dereference.

We should confirm the following points:

1) whether unimplemented FP trap could happen even with 68881 or 68882
   (if so we should check how it should be handled)
2) if it's vaild what code could cause the trap
3) whether 68020+68882 requires different handling from 68030+68882
---
Izumi Tsutsui