Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!psinntp!dg-rtp!ponds!rivers
From: rivers@ponds.uucp (Thomas David Rivers)
Subject: Hanging problem solved (work-around at least).
Message-ID: <1992Aug15.010923.6242@ponds.uucp>
Summary: Problem narrowed down to '387 co-processor
Keywords: hangs, bugs, 387 coprocessor
Date: Sat, 15 Aug 1992 01:09:23 GMT
Lines: 35
Well, taking a tip from Doug Anson's (danson@lgc.com) post to this
news group I decided to try something out.
I had npx.c always return 0 from the probe for the existence of a
math-coprocessor (I'm too lazy to pull chips out and stick them in again).
and *voila* ..... The kernel no longer crashes.
I'm running a kernel w/ the rlist fixes, and wd fixes (both of them) and
the MAX_KMAPENT fix (set to 1000), and the other bufpages fix
Bill Jolitz mentioned. It has been doing nothing but re-compiling the
kernel over and over again for 14 hours, so I feel rather confidently
that the problem has been isolated.
Also, I had put in the npx.c fix mentioned by James Van Artsdalen
(james@raid.dell.com) - but that doesn't correct the hanging problem.
I don't know what this means to 486DX people; since you can't pull
your "coprocessor" out in that case.
Just to begin keeping data points on '387 problems, I'm running
a 20mhz 386 with a ULSI 33mhz coprocessor.
If you have a 387 coprocessor, and experience kernel lockups with no
recourse, I would suggest you try pulling out the chip, or
altering npx.c as I have.
Unfortunately, I will be away on a conference this week, and will have
no opportunity to try and diagnose the details of the problem - if anyone
does, please post what you find.
- Dave Rivers -
(rivers@ponds.uucp)