From owner-freebsd-bugs Fri Mar 10 0: 0: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 9359137B952 for ; Fri, 10 Mar 2000 00:00:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id AAA44997; Fri, 10 Mar 2000 00:00:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Fri, 10 Mar 2000 00:00:03 -0800 (PST) Message-Id: <200003100800.AAA44997@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Ted Mittelstaedt" Subject: Re: kern/7678: Problems with a 386-16 Reply-To: "Ted Mittelstaedt" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/7678; it has been noted by GNATS. From: "Ted Mittelstaedt" To: , Cc: Subject: Re: kern/7678: Problems with a 386-16 Date: Thu, 9 Mar 2000 22:03:06 -0800 I have seen this kind of problem before as well on older 386/16 systems. It began sometime in the 2.2 series of kernels. In fact I think I submitted it as a pr that has subsequently been closed. I can confirm that this is not ram related - I've run all 2.2 series on 4MB. (the systems were very slow, of course) I do however believe this is a CPU bug. There is a well-known 80386 bug only present in early 16's that broke FPU support. (note that any surface-mount 386-16 is well after the bug was fixed) There are probably other ones as well. I believe that the triggering incident on this bug is a newer version of GCC, NOT the FreeBSD kernel. In my case, swapping out the 80386-16 CPU with another 80386-16 CPU fixed the problem. (obviously it was a socketed CPU) The only difference between the CPU's was that they were manufactured in different geographical locations. Otherwise both were marked as Intel CPU's. Ted To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message