Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!think!samsung!cs.utexas.edu!texbell!uudell!loft386!dpi
From: dpi@loft386.UUCP (Doug Ingraham)
Newsgroups: comp.unix.i386
Subject: Re: 386ix and Parallel Printers
Summary: All lpt ports are not created equal.
Keywords: delays ISC2.0.2
Message-ID: <624@loft386.UUCP>
Date: 4 May 90 05:28:55 GMT
References: <29404@cup.portal.com> <1990Apr29.020243.20270@virtech.uucp> <1820@east.East.Sun.COM>
Organization: Lofty Pursuits, Rapid City, SD USA
Lines: 51

In article <1820@east.East.Sun.COM>, gsteckel@diag2.East.Sun.COM (Geoff Steckel - Sun BOS Software) writes:
> I, too, am having trouble with my parallel printer using PC/ix, and Interactive
> is stumped.  The problem is that output is >>>EXTREMELY<<< slow... like about
> 10 chars/sec max.  This behavior is seen when doing `cat file > /dev/lp1',
> so it isn't a spooler problem.

This sounds like the driver isn't getting any interrupts.  I have seen lpt
ports that didn't bother to connect to the interrupt line.  This seems to
be mostly the port on a monochrome card.  It is also possible that the card
is interrupting on a line other than the one the driver expects and so is
still ignored.  Try a different parallel port.  Remember that the two common
interrupts used for lpt devices are 7 and 5.  7 is the one you want to use
because 5 is used by mice and lan cards and streaming tape controllers.  I
am always fighting the lack of available interrupt lines especially on 8 bit
cards.  Another possibility is that you have 2 cards driving the same
interrupt line.

> A few weeks ago I saw the tail end of a discussion of a similar problem,
> ending with `don't use keymap'.   I don't, unless it's buried in a standard
> distribution .????rc file which I can't find.

I really can't believe this could have anything to do with the printer. At
least it shouldn't.

> Of course, if I boot DOS, the printer works just fine, thanks.  AAARRRGGHH.

Of course.  Dos doesn't use interrupts (for the parallel port).  It is single
tasking and just waits for the printer to accept a character.  You would
complain worse if Unix operated this way although your complaint would be
about how Unix locks up while printing.
 
> Any enlightenment appreciated.
> 	thanks,
> 	geoff steckel (gwes@wjh12.harvard.EDU)
> 			(...!husc6!wjh12!omnivor!gws)
> Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line.
> This posting is entirely the author's responsibility.

Suggestions:  Try a different parallel port.  Check the existing port
to make certain the card is configured correctly.  Make certain you
don't have an interrupt conflict with some other card.  If you have a
second parallel port try using that.

What is probably happening is the driver is sleeping waiting for the busy
line interrupt.  There is a timer set so that if the interrupt is missing
eventually the driver task wakes up and sends another character.

-- 
Doug Ingraham (SysAdmin)
Lofty Pursuits (Public Access for Rapid City SD USA)
uunet!loft386!dpi