The Floating Point Exception message is /NOT/ a hardware problem. 1.3.34
I was told (or one of the mid 30's or 40's 1.3.* kernels) brings along a
completely new /proc filesystem, and top,ps,xload, and others, utilize
that system. Search TSX-11 or any SUNSite mirror for the latest procps
package which contains all those programs that use the /rpoc filesystem.
Compile and install, then your problem is gone.
- -- ____ __ __ _ ___ __
--- / __/_ __/ /_/ / ___ ___ (_)__ ___ ____/ _ \__ _____ / /__ sXe
- -_\ \/ // / __/ _ \/ -_|_-</ /_ // -_) __/ ___/ // / _ \/ '_/
- -/___/\_, /\__/_//_/\__/___/_//__/\__/_/ /_/ \_,_/_//_/_/\_\
- - /___/------------------------------------------------------ - - -
kmfdm@netline.net -|- http://www.tessier.com/spitfire -|- synthpunk@DALNet(IRC)
On Tue, 20 Feb 1996, David Engberg wrote:
>
> I decided that my 486 was too slow for C++ development, so went out and
> bought a P5-133 system with a Triton chipset PCI motherboard last weekend...
>
> Both 1.2.11 and 1.2.13 exhibited a horrible corrupting problem where I
> would work for a while, then gcc would spew some internal error before
> taking out virtual memory and, after enough restarts, my root
> filesystem.
>
> So I tried several of the more recent 1.3.* series, which mention
> corrupting PCI chipset fixes in the 'config' process. I haven't seen the
> corrupting problem, but now emacs bombs in its memory manager (xemacs
> works ok) and 'ps u' and 'top' both die with a floating exception:
>
> > ps u
> USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
> Floating exception
>
> I'm hoping this is a telling symptom of a larger problem that makes the
> majordomo 'perl' scripts consume all of the memory on my system.
>
> Has anyone else seem this problem? When were the chipset fixes
> introduced into a kernel release? I can drop back to that version to see
> if it fixes the problem(s).
>
> -dave
>
>
>