larry@focsys.uucp (Larry Williamson) (11/28/89)
This happened with our 1.0.6 system as well. When ever anyone here runs pic (DWB 2.0), our system would lock up so hard, that the only recourse was to power off the computer. I had to remove pic. When we upgraded to 2.0.2, I figured that the new DWB (2.1.0) would fix this problem. I just installed the new DWB this afternoon, and it is no better. Has anyone seen this happen before? I don't have a nice concise roff file that can be used to recreate this bug yet, but I should have one soon (It is an expensive bug to try to recreate since I must power down, and wait through 15 minutes of fsck). If it makes any difference, I'm using the latest version of jetroff (2.6), the system has a 387 installed, and no other program gives us grief like this. On our previous system (386/ix 1.0.6), I tried pic outside of jetroff (ie. pic <dangerous_file >/tmp/please_reboot) and the lockup would still occur. I should have more information soon. Thanks for any pointers. -Larry
larry@focsys.uucp (Larry Williamson) (11/28/89)
In article <LARRY.89Nov27150018@focsys.uucp> I wrote:
: When ever anyone here runs pic (DWB 2.0), our system would lock up
: so hard, that the only recourse was to power off the computer. I had
: to remove pic.
:
: If it makes any difference, I'm using the latest version of jetroff
: (2.6), the system has a 387 installed, and no other program gives us
: grief like this. On our previous system (386/ix 1.0.6), I tried pic
: outside of jetroff (ie. pic <dangerous_file >/tmp/please_reboot) and
: the lockup would still occur.
I'm pretty sure that Jetroff is not the trouble, running pic alone on
the command line still causes trouble (ie. pic <x.mm >y.tmp). But,
what does seem to be a part of the trouble is the 387! On another
machine here, one without the 387, but otherwise the much the same,
pic runs fine.
-larrycpcahil@virtech.uucp (Conor P. Cahill) (11/28/89)
In article <LARRY.89Nov27150018@focsys.uucp>, larry@focsys.uucp (Larry Williamson) writes: > > This happened with our 1.0.6 system as well. When ever anyone here > runs pic (DWB 2.0), our system would lock up so hard, that the only > recourse was to power off the computer. I had to remove pic. Not that this is any real help..... I have Elan's EROFF (which is based upon DWB 2.0, I believe) and originally used it on Bell Tech's Release 3.1, then 3.2, then moved it to 386/ix 2.0.2. We have prepared lots of documents using pic to generate some moderately complex drawings (50+ miscellaneous sized, invisible & visible boxes with angled connecting lines as an example) and have never had a problem with the system locking up. Under the BT OS, we didn't even have a 387 (and it was just a 16Mhz 386). If you are doing some serious document preparation using troff, EROFF definately should be considered. > I don't have a nice concise roff file that can be used to recreate > this bug yet, but I should have one soon (It is an expensive bug to > try to recreate since I must power down, and wait through 15 minutes > of fsck). When you do get one, send me a copy & I will try it under EROFF. --- I'm not affiliated with Elan corp, just a happy customer. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
cpcahil@virtech.uucp (Conor P. Cahill) (11/28/89)
In article <LARRY.89Nov27153954@focsys.uucp>, larry@focsys.uucp (Larry Williamson) writes: > I'm pretty sure that Jetroff is not the trouble, running pic alone on > the command line still causes trouble (ie. pic <x.mm >y.tmp). But, > what does seem to be a part of the trouble is the 387! On another > machine here, one without the 387, but otherwise the much the same, > pic runs fine. It sounds like you are running into the old 386 problem with the 387 in multitasking environments. There is a software solution that can be configured into the kernel (can't remember exactly what it is named). Several board manufacturers have come up with a $100 hardware solution. Not sure how successfull that is. (Bell Tech, now Intel, was one of them). -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
rick@pcrat.uucp (Rick Richardson) (11/28/89)
In article <LARRY.89Nov27150018@focsys.uucp> larry@focsys.uucp (Larry Williamson) writes: >This happened with our 1.0.6 system as well. When ever anyone here >runs pic (DWB 2.0), our system would lock up so hard, that the only >recourse was to power off the computer. I had to remove pic. I think this is all due to floating point hardware/software troubles. We saw erroneous output from pic and xclock when a 287 was installed. Changing the coprocessor present bit in CMOS ROM fixed that. In our case, UNIX thought there was a 387 installed when there was only a 287 installed, and tried to execute instructions that didn't exist in the 287. I don't know exactly what the fix is for 387's, but I think you may need to get the 80386DX processor (yours is probably a 386 double sigma, take a look). As an aside, it really bugs me that Intel did squat for owners of buggy 80386's (multiply, FP, DMA troubles ... pretty common stuff), but promised free upgrades for owners of buggy 80486's. -- Rick Richardson | Looking for FAX software for UNIX/386 ?????? mention PC Research,Inc.| WE'RE SHIPPING your uunet!pcrat!rick| Ask about FaxiX - UNIX Facsimile System (tm) FAX # (201) 389-8963 | Or JetRoff - troff postprocessor for the HP {Laser,Desk}Jet
jcm@mtunb.ATT.COM (John McMillan) (11/28/89)
In article <LARRY.89Nov27150018@focsys.uucp> larry@focsys.uucp (Larry Williamson) writes: >This happened with our 1.0.6 system as well. When ever anyone here >runs pic (DWB 2.0), our system would lock up so hard, that the only >recourse was to power off the computer. I had to remove pic. On an ATT-6386 running SVR3.2, the 387 problem is 'fixed' by adding the following to '/etc/conf/cf.d/stune' and re-building the kernel: DO387CR3 1 I haven't worked with the derivative systems and it might be different. If supported, it should be mentioned in "The System Administrator's Guide" under Tunable System Parameters: General Kernel Parameters ["Mentioned" is all!], and in '/etc/conf/cf.d/mtune'. john mcmillan -- att!mtunb!jcm -- muttering for SELF... not THEM
larry@focsys.uucp (Larry Williamson) (11/29/89)
In article <LARRY.89Nov27150018@focsys.uucp> I wrote: > Whenever anyone here runs pic (DWB 2.0), our system would lock up > so hard, that the only recourse was to power off the computer. I received mail and have seen postings from each of these people: . cpcahil@virtech.uucp (Conor P. Cahill) . rick@pcrat.uucp (Rick Richardson) . Dick Dunn <watmath!ico.isc.com!rcd> . Preston Gurd <watmath!watcgl.waterloo.edu!rpgurd> They all suggested that the problem is probably related to the old infamous 386/387 incompability. And they are correct. I swapped the double sigma 386 out of the machine with the 387 and put in a 386DX chip. Pic now seems to work like a charm. Thanks. -Larry
vjs@calcite.UUCP (Vernon Schryver) (12/01/89)
In article <1708@mtunb.ATT.COM>, jcm@mtunb.ATT.COM (John McMillan) writes: > On an ATT-6386 running SVR3.2, the 387 problem is 'fixed' by adding > the following to '/etc/conf/cf.d/stune' and re-building the kernel: > > DO387CR3 1 > > john mcmillan -- att!mtunb!jcm -- muttering for SELF... not THEM Can someone say precisely what the kernel work-around is? I've heard of something like leaving the 387 marked absent or in other words continueing to "emulate" 387 instructions, and in the "emulator" doing strange and slow stuff before actually doing the ESC+etc. How much slower is <old 386>+<software fix>+387 than <new 386>+387? How many cycles are added to each 387 operation? Vernon Schryver vjs@calcite.uucp
lee@sq.sq.com (Liam R. E. Quin) (12/03/89)
[sorry if I'm a few days behind, news takes longer to reach us because the Canadian cold weather reduces the speed of light :-)] In article <1989Nov28.014033.4277@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >In article <LARRY.89Nov27150018@focsys.uucp>, larry@focsys.uucp (Larry Williamson) writes: >> This happened with our 1.0.6 system as well. When ever anyone here >> runs pic (DWB 2.0), our system would lock up so hard, that the only >> recourse was to power off the computer. I had to remove pic. > >Not that this is any real help..... >I have Elan's EROFF Luck you.... I have had problems with both Elan's pic and SoftQuad's sqpic, but determined in the end that the problem was that the documentation for the Acer 386 motherboard I was using was in error, and I had the jumpers for whether or not a 387 is present set incorrectly. Another symptom was that /etc/dfspace hung (in awk), making it a little hard to log on... Check that your CMOS Setup configuration has the '387 listed. Lee -- Liam R. Quin, Unixsys (UK) Ltd [note: not an employee of "sq" - a visitor!] lee@sq.com (Whilst visiting Canada from England, until Christmas) utai!anduk.uucp!lee (after Christmas) ...striving to promote the interproduction of epimorphistic conformability