rcw@qetzal.UUCP (06/05/87)
Egads! Quick, a post, before the system panics again...
Here are the blood curdling details:
Hardware: Apparat Ram card; 0 bank 120ns 64k drams, 1,2 banks:
120 ns 256k drams 3 bank: empty. Switch 2 set appropriately for memory/
type of ram. Computer=IMS286,1meg on motherboard.
Switch 1 is set for starting address at 1408k. The tech confirmed
that this was proper. (I don't know why it's not 1024!)
Other boards: Pulled, don't affect occurrence of problem.
Phoenix bios 3.0
Software: Version 2.2L of Microport System V/AT. "Big" kernel.
(Problem also occurrs with small kernel)
Problem: Rom checks memory 640k base, 1536 extended. I do a
telinit 2 to go multi-user. I then vi the Makefile
for news 2.11. Kernel tells me either: NMI in system
mode, or NMI in user mode, then displays the Makefile.
I then do 'j's down the page. I do 'k's back up the
page. Disk light flashes, then "DOUBLE FAULT" ocurrs,
a bunch of hex info is displayed, and the message
appears: "panic - general protection" is displayed.
Notes: I've returned the card once, and am experiencing the
same behavior. vi seems to be the most reliable way
of producing the problem. Nowhere in any docs from
Microport,Apparat,or IMS do I see noted any restrictions
on the type of card that can be used. If I pull the ram
card and run setup again, everything works fine.
This problem is driving me up a wall. Anyone have a clue?
--
Robert C. White, Jr. Graphics Information, Inc. ****************
UUCP: seismo!{nbires!isis|hao}!scicom!qetzal!rcw * OIL/GAS/LAND *
USPS: 3067 Robin Way, Denver, CO 80222 * CARTOGRAPHY *
ATT : +1 303 759-3666 ****************aryeh@eddie.MIT.EDU (Aryeh M. Weiss) (06/19/87)
In article <114@qetzal.UUCP> rcw@qetzal.UUCP (sysop) writes: >Software: Version 2.2L of Microport System V/AT. "Big" kernel. > (Problem also occurrs with small kernel) > >Problem: Rom checks memory 640k base, 1536 extended. I do a > telinit 2 to go multi-user. I then vi the Makefile > for news 2.11. Kernel tells me either: NMI in system > mode, or NMI in user mode, then displays the Makefile. > I then do 'j's down the page. I do 'k's back up the > page. Disk light flashes, then "DOUBLE FAULT" ocurrs, > a bunch of hex info is displayed, and the message > appears: "panic - general protection" is displayed. I had this type of probelm using a Wells American A*Star II and a PC-Limited 1.5 MEG card. At 8-0, or 8-1 the system had obscure and non-reproducible errors when doing a big compile. NMI errors occured, but memory passed advanced diagnostics. I did not have as much trouble at 6-0 or 6-1. I recently installed a Micron 4 MEG memory card (100ns chips) and found that I had to tell it to force a wait state, or else I got the same obscure (and non-reproducible) errors. Micron writes in their manual that some AT clones have different timing than an IBM AT, and they will not work properly at 8-0. Apparently, setting the Wells to insert a wait state does not do the trick. Something about the timing... Also, users of Microport UNIX will be glad to know that the 80287 floating point crash (system hangs when there is a floating point error) has been fixed, and the patch has been sent to uport for inclusion in their next release. Also, the clock problem has been fixed. As I am inexperienced at posting news (this is my first time) send mail to me to get patches. If I get a flood of replies, I will post the fixes, but you will need the source to build a new lib1 to link to the kernal. -- aryeh@eddie.mit.edu mit-eddie!lees-rif!aryeh
karl@ddsw1.UUCP (Karl Denninger) (06/21/87)
In article <6120@eddie.MIT.EDU>, aryeh@eddie.MIT.EDU (Aryeh M. Weiss) writes: > Also, users of Microport UNIX will be glad to know that the 80287 > floating point crash (system hangs when there is a floating point > error) has been fixed, and the patch has been sent to uport for inclusion > in their next release. Also, the clock problem has been fixed. There was also a floating-point emulator bug (system may panic after an 'exec' if there is no 80287 installed AND floating point was being used), which has been fixed. The game 'phantasia' was the first to cause this panic on our system (3 panics in less than two hours! Removing the 'exec' from the die() code 'fixed' it temporarially). There was also a problem in the system-vision package, make sure you obtain this disk as well if you use this part of the package (editing user defaults causes a core dump) These have been fixed, and V2.2.2 is available. I would advise all who have 2.2 and do not have an 80287 to contact Microport to obtain this update. We have received this upgrade and it does appear to correct the problem. Note: 2.2.2's release notes still list the 80287 bug as an open problem. -- Karl Denninger UUCP : ...ihnp4!ddsw1!karl Macro Computer Solutions Dial : +1 (312) 566-8909 (300-1200) "Quality solutions at a fair price" Voice: +1 (312) 566-8910 (24 hrs)
aryeh@eddie.MIT.EDU (Aryeh M. Weiss) (06/21/87)
In article <117@ddsw1.UUCP> karl@ddsw1.UUCP (Karl Denninger) writes: >In article <6120@eddie.MIT.EDU>, aryeh@eddie.MIT.EDU (Aryeh M. Weiss) writes: >> Also, users of Microport UNIX will be glad to know that the 80287 >> floating point crash (system hangs when there is a floating point >> error) has been fixed, and the patch has been sent to uport for inclusion >> in their next release. Also, the clock problem has been fixed. > > >Note: 2.2.2's release notes still list the 80287 bug as an open problem. > The clock fix and 80287 fix are quite new, were done in our lab and forwarded to Microport. They should be included in the next release. I will briefly describe them, but you will need a source licence to fix them yourself. In clock.c (rel.2.2/i*/i*/os) remove the first two #ifdef IBMAT, except to move time++ out of the second one into the regular code. This removes the kludges with which Microport tried to "fix" the problem. Also, set RTCCNT (/usr/include/sys/clock.h) to 19885 (decimal). In trap.c (same directory) add the following line outb (0xF0, 0); /* M001 - Clear busy condition */ after the asm (" fnclex") instruction (there is only one of them). Having done this, run make in that directory to get a new lib1, and then make a new kernal. After you have installed the new kernal, use /etc/patch to check .clocktic -- it should be 19885. If it is not, patch it. This value may need tuning if your system has slightly differnet internal oscillators. It was very nice to force a divide by zero and have the system dump core and return cleanly... The system is running well (no obscure compiler errors) with the 4 Meg Micron extended memory board at 10 MHz 1 Wait state. However, it did not run properly at 8 MHz 0 wait states. I wonder if other people with clones based on the Chips and Technology chip set have had such problems (mine is a Wells A*Star II). -- aryeh@eddie.mit.edu mit-eddie!lees-rif!aryeh