[comp.unix.i386] Pic on ISC's 386/ix 2.0.2 locks system hard.

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.

-larry

cpcahil@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