jorgnsn@qucis.queensu.ca (John Jorgensen) (12/05/90)
We have been experiencing a maddeningly intermittent problem with two
HP LaserJet IIIs with HP's PostScript cartridge. In brief, the
printers occasionally hang indefinitely while printing jobs, and have
to be reset or power-cycled before they will start printing again.
The problem does not seem to be bugs in the submitted PostScript
programs, because the exact same files will print perfectly after the
printer is reset. I am posting in the hope that someone else might
have seen similar problems, and either solved them, or been able to
link them to known bugs in HP's PostScript.
Here are the long, gory details:
We have two LaserJet IIIs with HP's PostScript cartridge, hanging
off the MTI-1600 board of a Sun 3/160.
Occasionally the printers hang (from 0 to 4 times a week, where each
printer sees 250-450 print jobs per week, totaling 1000-3000 pages).
"PROCESSING DATA" shows up in the message window, and stays there for
tens of minutes. Because I have been able to print the identical jobs
after resetting the printer, I know that the problem is not just that
the PostScript program is doing a great deal of computation.
Sometimes I have been able to take the printer offline, reset it from
the front panel, and had it work fine afterwards. More often, when I
try to take the printer offline, the message "OFFLINE PENDING" appears
on the screen, but the printer never goes offline. In those cases, I
have had to turn the printer off and on to bring it back to the real
world.
Generally speaking, resubmitting the same job after resetting or
power-cycling the printer results in perfect output and no hitches.
The times that I have seen the printer hang again on the same job, it
was on a different page.
There doesn't seem to be anything special about the pages where the
printer hangs (no fancy bitmaps or complicated graphics, for example).
Most of the output that causes the problem has been produced by
dvitps, the DVI-to-PostScript translator that we use, but the printers
have also hung on output from tpscript, a public domain
DITROFF-to-PostScript translator. Neither of these programs has
produced similar problems on our old Apple LaserWriter I (but I
suppose they could be tickling some subtle incompatibility between
HP's PostScript and Apple's).
I have some evidence that the difficulty is not a communications
problem between the Sun and the printers:
First, the spooler logs have frequently shown that as far as the
host was concerned, the entire job was sent, even though there
were still several pages to print after the point where the
printer hung--so it seems that the printer was able to continue
receiving and buffering characters despite not being able to
output anything.
Second, in cases where the host had not sent the entire file, I
have used Sun's pstat command to look at the STREAMS data
structures for the printer's serial line and confirmed that the host
was blocked on that line with a full buffer.
Third--and this is the weird one--I have enabled debugging output
in the PostScript that dvitps produces and the resulting messages
indicate not only that the PostScript program has started work on
the page after the last page it managed to print, but that
sometimes that it is _two_ pages ahead of the last page to print.
That last point, combined with the whirring noise that sometimes
accompanies the hanging, makes me wonder if the problem is at least
sometimes associated with the printer's attempt to output a page.
There are, however, no paper jams associated with this problem.
I have modified our spooler to bracket each print job with a
"vmstatus" command, to check for memory leaks. There don't seem to be
any. Are there other status commands I could insert to indicate if
some evil condition is gradually building up between jobs?
Now for the treatments I have either tried or considered. When the
problems first surfaced, shortly after we installed the printers, I
moved the PostScript cartridges from the right to the left slot, and
imagined the problem went away for a while (more likely users just
stopped bothering to tell me about it). I have considered replacing
dvitps and tpscript with alternative programs (probably Tomas Rokiki's
dvips and GNU's groff), but am reluctant to dragoon our users into
this until I have some clearer indication that it will do some good.
I have also thought of moving the printer's serial lines from the
Sun's MTI boards to the ports on the CPU board, but again am reluctant
to shift equipment around without knowing more about what I am doing.
With the problem so intermittent, even deciding whether it has gone
away is difficult.
So has anybody out there seen similar problems? Are there known
problems with HP's PostScript? Has anybody actually managed to read
this far? Email me, and I will post a summary.
Thanks for your help,
John Jorgensen jorgnsn@qucis.queensu.ca (613) 545 6784
Systems Programmer, Dept. of Computing Science, Queen's Universitywoody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (12/06/90)
Don Lancaster has mentioned the same sort of things to me. His opionion is that the version of PS for that particular machine in cartridge form is riddled with bugs. He has a rather extensive list. I believe some of them have been documented over on the Genie Postscript roundtable. At any rate, Don runs a free helpline and posts his number in the computer shopper. He doesnot support or deal with people outside the us, and especially so for Canada due to the multitude of problems he has had with Canadian mail service. I currently don't have access to the Genie roundtable (i'm just to darned cheap!), but I think I can get a bug summary. Cheers Woody
schuster@panix.uucp (Michael Schuster) (12/06/90)
In article <1734@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: > >Don Lancaster has mentioned the same sort of things to me. His >opionion is that the version of PS for that particular machine >in cartridge form is riddled with bugs. He has a rather extensive >list. I believe some of them have been documented over on the Actually, to my knowledge he has documented two. One is specific to the IID/IIID, and involves the fact that -copypage- is not side-sensitive on a duplexing printer. This slows it down considerably. The other one =I= discovered while running a Lancaster demo file of different screen parameters. A certain combination of -arc- and -setscreen- in repetition somehow overflows an internal stack and produces a cartridge crash. If you use the cart interactively, the interpreter echoes back "Fatal System Error @ [address" This is consistent, happens EVERY TIME, and is associated with an error message on the LCD followed by a hard reset. HP is aware of both bugs. As of this writing they have not given the slightest indication that they intend to fix either of them. -- *%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%* l\ /l ' _ Mike Schuster ...!cmcl2!panix!schuster l \/ l l l/ (_ NY Public Access CIS:70346,1745 l l l l\ (_ New York, NY USA MCI Mail,GEnie:MSCHUSTER
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (12/07/90)
In article <1990Dec6.134809.213@panix.uucp>, schuster@panix.uucp (Michael Schuster) writes: > In article <1734@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: > > > Actually, to my knowledge he has documented two. One is specific to the > IID/IIID, and involves the fact that -copypage- is not side-sensitive on > a duplexing printer. This slows it down considerably. On a single page printer, you can image a page, do a copypage, and then go back and erase a portion of the page, change the data and do another copypage etc. This makes for very fast generation of repetitive things like flyers or newsletters that are mailed to diffrent individuals. Unfortunatly, the duplex implementation does (currently) not work in an analogous manner. If you print a double sided newsletter, say, and then want to change some data on one of the pages, you have to re-image the entire document. What should happen, is that you should be able to make either the front or back side the currently active side, so that you could select side 1, change data just like you can on a single sided page, and then using copypage, kick another copy of the page out. As more and more duplexing printers (I know of on that is currently in the works) come out, unless this is changed, they will be crippled, and virtually useless. > > The other one =I= discovered while running a Lancaster demo file of different > screen parameters. A certain combination of -arc- and -setscreen- in > HP is aware of both bugs. As of this writing they have not given the > slightest indication that they intend to fix either of them. Actually, if it works the way it does for most other Adobe OEM'S, Adobe requires a $100,000.00 up front payment for a new rev level. If an OEM finds a problem that requires a rev level (Adobe won't allow a simple rom patch), then they have to determine if it is worth $100,000.00 to get it fixed. Generaly, they wind up accumulating the problems for as long as possible, then get a revision to fix a bunch all at once. This info comes from a reliable source within an Adobe OEM. Cheers Woody > > > -- > *%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%* > l\ /l ' _ Mike Schuster ...!cmcl2!panix!schuster > l \/ l l l/ (_ NY Public Access CIS:70346,1745 > l l l l\ (_ New York, NY USA MCI Mail,GEnie:MSCHUSTER
schuster@cup.portal.com (Michael Alan Schuster) (12/08/90)
Reply from Don Lancaster (and I quote): " There's nothing at all mysterious about the HP cartridge blowups. It does it all the time, reliably like clockwork. Just feed it too complicated a job or too many fonts, and away she goes. That's what error #24 is all about. By the way, the PROCESSING DATA message usually means the printer is out behind the barn playing with itself. Very informative. A specific way to blow up this cartridge appears as HPCARTXX.PS in PSRT. This cartridge also has a fatal copypage flaw in duplex mode, since copypage is NOT side sensitive, causing a 10:1 to 50:1 slowdown. Both HP and Adobe assert that this is an intentional feature. All of which is maddingly infuriating. But duplex printing is SO GREAT otherwise that you have to put up with all this male bovine excretia. See my cartridge review in GURU67.TXT on PSRT." -------------------- --mike
jeffe@eniac.seas.upenn.edu (George Jefferson ) (12/08/90)
> A specific way to blow up this cartridge appears as HPCARTXX.PS in PSRT. . .. > See my cartridge review in GURU67.TXT on PSRT." -excuse my ignorance, but WHAT is PSRT? -- -george @sol1.lrsm.upenn.edu
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (12/09/90)
In article <34361@netnews.upenn.edu>, jeffe@eniac.seas.upenn.edu (George Jefferson ) writes: > > A specific way to blow up this cartridge appears as HPCARTXX.PS in PSRT. > > -excuse my ignorance, but WHAT is PSRT? > Don Lancasterese for the PostScript RoundTable over on GENIE, of which Don is the sysop for. Genie is a pay service. They have a new flat rate connect charge now, something like 6.00 or so per month or maybe less. That gets you access to lots of stuff, but the PS round table costs you $6.00 per hour to access, of that amout 10% or .60 hour gets payed to the sysop. Considering the amount of work that Don puts into it it is probably way below minimum wage 8> but they do have several hundred postscript downloads etc etc. Cheers Woody
schuster@cup.portal.com (Michael Alan Schuster) (12/09/90)
>-excuse my ignorance, but WHAT is PSRT?
Sorry ... it's GEnie's cutesy name for their PostScript conference.
I've posted the cartridge blowup demo separately here.