Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!manuel.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde From: bde@runx.oz.au (Bruce Evans) Subject: Re: intermittant reboots and lockups (follow up) Message-ID: <1993Mar3.014836.20108@runx.oz.au> Organization: RUNX Un*x Timeshare. Sydney, Australia. References: <1993Feb28.164505.982@mnemosyne.cs.du.edu> <1993Mar1.232255.29475@mnemosyne.cs.du.edu> Date: Wed, 3 Mar 93 01:48:36 GMT Lines: 29 In article <1993Mar1.232255.29475@mnemosyne.cs.du.edu> smace@nyx.cs.du.edu (Scott Mace) writes: >It appears that the problem is with the ULSI (accidently stated as USI) >Math co-processor. The technician at ULSI said that the pallete >distortion and intermittant lockups are caused by the npx driver sending >287 code. Apparently the ULSI chip does not understand 287 code. > >My next question is: What is 287 code doing in 386bsd? >In the npx driver is says soemthing like.... >NPX driver Numeric Processor Extension 287/387. There's only one instruction in the driver that might be 287-related: the outb(0xf1, 0). This does nothing on many systems with 387/486's. Otherwise the driver doesn't support 287's directly. It says 287 because they almost work (some details are wrong, e.g., the projective mode bit). >What would be the point of running a 287 with a 386??? Some systems have them. >Does the npx-0.3? solve this 287 conflict? No, it breaks all normal 386/387 systems :-(. It works fine on 486DX systems. For a quick fix, try changing __INITIAL_NPX_CW__ (or something like that) in <machine/npx.h> to 0x127f and rebuilding the kernel. This masks all npx exceptions. -- Bruce Evans bde%runx.oz.au@ips.oz.au