From: Bela Lubkin <belal@sco.COM>
Subject: Re: Parallel printers in Unix 4.1
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Thu, 15 Oct 1992 00:26:47 GMT
Precedence: bulk

Tony Lawrence wrote:

> Situation: System was Xenix 2.3.4 w/ parallel ports at 378 int 7
> and 278 int 5, lp0 and lp2.
> 
> Upgraded to unix 3.2 4.1 and (after mkdev parallel) I end up
> with lp0 and lp1 (???).
> 
> This is not good because:
> 
> 	1. It's supposed to be impossible (?)
> 	2.  Stuff going to lp1 takes it's sweet time
> 	  getting there.
> 
> But mkdev parallel seemed pretty straightforward :-)
> 
> Where did I go wrong (aside from buying that RS Mod I back in '77)?

There are several potential problems in this area in 3.2v4.0 and MSv4.1.
Most importantly, the driver can get confused about which interrupts go
with which ports.  To avoid this, use `mkdev parallel` to *remove* all
the units you currently have installed; then use it again and *add* all
three valid units: 0x378/7, 0x3bc/7, 0x278/5.  After you've done that,
relink, reboot, and you'll find that only the ports that you actually
have (in this case, lp0 (0x378/7) and lp2 (0x278/5) are recognized on
the boot screen.

After doing that, test the performance of your printers.  If performance
is good, stop.  If one of the ports is still slow, use `mkdev parallel`
to reconfigure that particular port, changing its interrupt from 5 to 7
or vice-versa.  Relink, reboot, test performance.  Only now, if
performance is still bad, should you start messing around with patches.

Parallel port performance problems are overwhelmingly caused by
incorrect interrupt configuration.  Don't get caught up in a morass of
patches if they're not necessary.

Paul Fischer wrote:

> mkdev parallel sets the parallel port names according to the order in which 
> they were installed!  SCO no longer follows the DOS method of naming parallel 
> ports, and allows you to set them up as you need them.

That was more or less unintentional.  We'd like to keep the mapping of
lp0=378, lp1=3bc, lp2=278, yet also be able to have some of those
completely linked out of the kernel.  The way we went about it in
3.2v4.[01] wasn't right.  Hopefully it'll be right in 3.2v4.2.

... and included an itscript:

> As for the printing speed...
> 
> Parallel printer is printing slowly under Version 4.0 of SCO UNIX

> CAUSE:    Your printer may be deselecting itself upon receipt of a line
>           of text and then reselecting itself again for the next line.

[etc.]

Well, this is a *very* uncommon reason for slow printing, and would have
caused the same problems under 3.2v2, so I doubt this is Tony's problem.
This is not a cure-all for 3.2v4 slow printing, please don't distribute
it as such.

Tony then wrote to Paul:

> >Do you know whether there is an equivalent patch for 3.2.2?  The system
> >my brother is using has an abominably slow lp1, which seems like the same
> >problem...

This is undoubtably the same problem it always is: your brother's
machine has a port which is at address 0x3bc, but interrupt 5.  Either
change its address to 0x278, or its interrupt to 7.  Alternatively, in
*some* machines with *some* parallel port hardware and *some* printers,
having two ports on the same interrupt makes one or both of the ports
slow.  In that case, change address/interrupt to 0x278/5.  If nothing on
the port is configurable, you can patch the driver to expect a different
mapping of address to interrupt vector.  Note that this is tricky
(involves patching both a table and the code) and I am not going to give
you detailed instructions since I don't have them.

Paul replied with another itscript:

> Slow printing parallel printer; missing documentation for _fst patch.

> PROBLEM:  I have a parallel printer that is printing slowly.  The _fst patch 
>           that is found in SCO UNIX System V/386 Release 3.2 Operating System
>           Release Notes is omitted from the SCO UNIX System V/386 Release 3.2 
>           Version 2.0, and ODT Version 1.0  and 1.1 Release Notes.   

Once again, this patch should only be attempted after you've made sure
that the physical hardware settings do match what the driver prints at
boot time.  The driver makes assumptions about what interrupt
corresponds to a particular address; your hardware has to satisfy those
assumptions.

>Bela Lubkin<  Support engineer, The Santa Cruz Operation
Xref: sparky biz.sco.general:3707 comp.periphs.scsi:4968