Subject: FP woe -- Re: regress/lib/libc/ieeefp/except
To: None <port-mips@netbsd.org, port-pmax@netbsd.org>
From: Toru Nishimura <nisimura@itc.aist-nara.ac.jp>
List: port-mips
Date: 06/04/2000 00:06:45
My R3000 is suffered from "kernel touch FPA" symptom repeatedly.
> R3000 processor posts INT5 interrupt requesting the intervension of
> kernel emulation for FP insn(s). EPC always points the 2nd insn of
> ast() routine which does not make sense to me. I'm confused about
> what't the exact condition(s) produces FP interrupt on R3000. A
> possible cause would be a glitch in fp.S which will repeatedly
> generate (it's what I'm watching) INT5 interrupts once it dives into
> an infinite loop. Can someone out there throw a towel to me?
I found MIPS kernel runs differently than used to be. I have been
using an old NetBSD/pmax kernel made last March 3rd (very stable), and
it never posts FPA interrupts when two small FPA exciser processes rush
to grab a single FPA. On the other hand, recent NetBSD/pmax kernel
posts FPA interrupts in moderate pace, a few per second given CPU
speed. While my recent change of delayed lazy FPA context switch might
be blamed, why R3000 FPA interrupt behaves differently after all?
== a kernel built this afternoon ==
$ vmstat -i
interrupt total rate
softclock 14939 9
softnet 1860 1
serial0 1467 0
ether 3048 1
scsi 13142 8
clock 394946 256
fpu 114 0
Total 429516 279
$ uptime
12:02AM up 26 mins, 2 users, load averages: 1.05, 0.54, 0.32
=== old kernel built 3/3 ===
$ vmstat -i
interrupt total rate
softclock 6501964 7
softnet 2152899 2
ether 2369416 2
scsi 766167 0
clock 225912335 256
optslot0 63671043 72
optslot1 791943 0
Total 302165767 342
$ uptime
12:03AM up 10 days, 5:08, 4 users, load averages: 0.23, 0.25, 0.40
Tohru Nishimura