njd@laidbak.UUCP (Nicholas J. DiMasi Jr.) (02/20/86)
*** RELINE THIS PLACE WITH YOUR MESS ***
Help!
We have two HP LaserJet (2686A) laser-printers. We formally ran them
on a Vax 750 under 4.2BSD, on serial ports using XON/XOFF, with very
few problems. Then, a Sun 2/130 running Sun UNIX 4.2 (Version 2.0)
took over the Vax's job of driving all our printers (and handling uucp
traffic and netnews, some project accounting work, ...). Since then,
the LaserJets have not been working reliably. I am not a system
administrator here, and I am not much of a UNIX systems-wizard (yet),
but I was willing to work on the problem. ('Never hurts to learn!)
Oh, yes: the ports board on the Sun is a Systek MTI-1600A, according
to our hardware administrator. (We are still using XON/XOFF.)
The symptoms are: after printing anywhere from part of one page to
several pages (it seems somewhat worse in landscape mode than in
portrait), the printer will often:
Stop printing and 'hang' with a partial page of data in its
buffer (the Form Feed light stays on indefinitely; taking the
printer offline and forcing out a page with the Form Feed
button yields a partially- printed page), or
'Lose' data such that there are some lines/chars missing from
the printed output, but the last line(s) are present.
Also, if multiple jobs are queued, the end of the output from one job
sometimes gets 'scrambled' with the beginning (burst page in most
cases) of the next.
(At least) the first two symptoms sounded to several people here like a
case of buffer overflow. The more I think about it, the more the third
one sounds like a special case of the second (lost data). I HAVE tried
the following:
Calling HP
- so far, I haven't been able to get through (their s/w
assistance line has been continuously busy)
Calling our HP dealer
- this is a Computerland store; the tech. folks there said, "we're
not familiar with UNIX systems" (they mostly support IBM PCs and
clones)
Testing for the "old UNIX bug", where the last close on a tty device
throws it into raw mode, thus X-ON/X-OFF no longer work (the
test/workaround is to hold the device open via sleep <hours-on-end> >
/dev/ttynn in a setuid-root shell script)
- (this was suggested by a local 'guru';) this test showed no
significant difference (and someone said later that this would
only affect a printer that was not used via lpr and lpd, etc.
Running the printer at 4800 bps instead of the factory-set 9600 bps
- no significant difference (again, I later heard that it
couldn't be the source of the problem anyway)
Checking the printcap entry; changing the fc, fx, xc, and xs settings
to those recommended by a friendly ditroff-filter vendor (who supports
many sites with LaserJets)
- the entry looked OK (as far as I can tell, i.e. everything
translated according to TTY(4) basically sounds OK or seems not
to apply to a printer); the new tty-flags settings made no
difference. The new settings are: fc#177476 :fs#301 :xc#77737
:xs#40; our original settings were (and still are for one of
the L'Jets): fc#177777 :fs#6321 :xc#177777: xs#40 (no change
in xs).
I would like to try moving the L'Jets to a different machine, but the
only other available one has no ports (yet; we are running all but some
dialups via Bridge communication servers, and expect to have a ports
board for the other machine "someday soon").
It has also been suggested that I try writing directly to the tty
device for one of the L'Jets to eliminate the "variables" of the
spooler, daemon, etc. I plan to try this.
I wish I had posted this request earlier, but I believed that I could
fix the L'Jets. Now, I find myself with not much more time (a week, maybe
more if I can convince the powers that be that I'm within a few days of
a fix) to work on these beauties.
Please, if anyone out there runs LaserJets [on a Sun], if you have any
experience with problems like I have described, or have any suggestions
or useful info, I would appreciate hearing from you. PLEASE MAIL ME
INSTEAD OF POSTING TO THE NET (or call me at 1-800-LAI-UNIX).
Thanks in advance
(sorry for the long posting),
Nick DiMasi
Lachman Associates, Inc.
...!ihnp4!laidbak!njdvsh@pixdoc.UUCP (Steve Harris) (02/24/86)
( Others may have the same problem, hence a followup. )
The LaserJet insists on using DTR handshaking. On our Pixel machine,
we "stty nohang" to prevent buffer flushing when the HP drops DTR.
Or, we jury-rig a cable to disable (mask out) DTR, so the XON/XOFF
works properly.
--
Steve Harris | {allegra|ihnp4|cbosgd|ima|genrad|amd|harvard}\
xePIX, Inc. | !wjh12!pixel!pixdoc!vsh
51 Lake Street |
Nashua, NH 03060 | +1 605 881 8791