procinfo-16-3's procinfo gets FP exceptions sometimes when run with '-d -n1' on a dual-CPU machine. What seems to do it is running something with heavy CPU usage on both CPUs (such as the distributed.net rc5des client). If you run it for a while and wait, boom, there it goes. I have not tested this behavior on a UP kernel. This is running with the latest Rawhide (although it happened both under the Rawhide SMP kernel and under stock 2.2.5-ac3).
The root cause of this seems to be that raw idle time number in /proc/stat occasionally blips backwards (!), with a ripple through effect on procinfo, which assumes it always goes forward. I'm not sure how this is possible, but the idle number is not a kstat variable but is instead worked out by subtracting all the other time ticks (kernel, user, nice) from elapsed jiffies (times the number of cpus). Possibly there is some update ordering issues there, especially with multiple cpus and IRQs coming in at just the wrong time on the 'other' cpu. I will be asking the gurus. In the mean time, there is an obvious patch that can be made to the code in procinfo that reads /proc/stat (just check if new.cpu_idle < old.cpu_idle and make them equal if so).
fixed in procinfo-17-1, available in the next release. However, as this seems to be a kernel bug, I also certainly hope that it has been corrected in a later release of the kernel as well.