Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!yarrina.connect.com.au!warrane.connect.com.au!godzilla.zeta.org.au!not-for-mail From: bde@zeta.org.au (Bruce Evans) Newsgroups: comp.unix.bsd.misc Subject: Re: Configuring lp Date: 27 Jul 1995 05:01:32 +1000 Organization: Kralizec Dialup Unix Sydney - +61-2-837-1183, v.32bis v.42bis Lines: 36 Message-ID: <3v63ec$h85@godzilla.zeta.org.au> References: <3ukfrj$84e@vodka.intele.net> <3uloih$qte@atlantis.utmb.edu> NNTP-Posting-Host: godzilla.zeta.org.au In article <3uloih$qte@atlantis.utmb.edu>, M. L. Dodson <bdodson@beowulf.utmb.edu> wrote: >In article <3ukfrj$84e@vodka.intele.net>, Barnacle Wes <wes@intele.net> writes: >>steinber@slinky.cs.nyu.edu (Joseph Steinberg) wrote: >>... >>I had a number of problems when I first plugged in my new inkjet printer >>to FreeBSD. I discovered that the kernel reports that lpt0 is an >>Interrupt-driven port, which seems to give me a throughput of about >>3 characters per minute (yes, MINUTE!). I set the port for polled i/o >>mode at the bottom of /etc/rc.local thusly: >... >Does anyone familiar with the lpt driver know what could be the matter? I had an >old Panasonic dot matrix under 2.0R which worked fine with interrupt-drive I/O. Some printers apparently interrupt before they are ready. Interrupt handling may be very fast due to an adequate implementation or fast hardware. Then the printer may still be unready when the lpt interrupt handler is reached. The lpt interrupt handler is stupid and doesn't allow for this. There is no good way to allow for it - at best the handler could wait for a few microseconds, wasting time, in the hope that a few microseconds is long enough to wait. Note that it is good for the printer to interrupt early if the host system has nothing better to do than wait - this reduces latency. The lpt interrupt handler is also too stupid to recover from lost interrupts. These occur whenever anything disables interrupts for longer than the printer ACK time. Printer interrupt handlers should have timeouts to recover from this. A timeout of 1/100 second would give a speed of 100 cps even if interrupts are totally broken. The 3 chars/minute speed might be caused by "stray" interrupts not working right when a driver is using irq 7. It is possible to distinguish "stray" interrupts from real irq 7's but the interrupt system dosn't bother. It depends on the driver ignoring interrupts that aren't for it. -- Bruce Evans bde@zeta.org.au