lpr to HP laserjet stalls

lpr to HP laserjet stalls

[Michael Ben-Gershon]

Using 'lpr' to print to an HP\x10LaserJet 6P printer often hangs midway.
This may happen both when the printer is used in its 'raw' mode and
as a filter through ghostscript. It is apparent both when printing
locally, and using Samba over the network. My own research seems
to have narrowed the problem down to the kernel. kernel 2.2.x (up to
2.2.19) was fine. I have had the problem with all 2.4.x kernels,
from 2.4.6 to 2.4.9.

I initially thought it was the new lpd supplied with RedHat linux 7.1,
but although I initially thought that reverting to the old lpd had
cured the problem, I now find it happening all the time.

It is intermittent, but very frequent. It is difficult to print more
than about 10 sheets without it happening sometime.

I have serached everywhere but not found any reports of such a problem,
except for one other user who also mailed the RedHat bugzilla list as
follows:

+------- Additional comments from lgt@dmu.ac.uk 2001-08-09 11:59:12 -------
I have exactly this same problem with my HP LaserJet 1100 - random stalls in
multi-page print jobs. The printer stops with the light on that normally
indicates data is left in the buffer that hasn't been printed yet. The print
queue eventually says it's stalled. Pressing the printer button to force out
the
page gives a page of truncated output, then a second page with what looks like
some printer commands on it, starting with "@PJL SET RET=MEDIUM". After
printing
this duff page, the printer is idle but the print queue is still stalled.
Re-starting lpd simply re-prints the same file again, starting from the
beginning, which then fails at some other random point in the file.

I had no trouble whatsoever with RedHat 6.2 or 7.0 and this printer. Now,
however, I can't reliably print anything other than a single page file - and
even that fails sometimes if other files are in the queue.

+--------------------------------------------------------------------------

It seems that his problem is similar, but maybe not exactly the same as mine,
but looks as if is caused by the same fault.

Any ideas?

Michael Ben-Gershon
mybg@netvision.net.il

Re: lpr to HP laserjet stalls

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

On Mon, Sep 03, 2001 at 11:05:29PM +0300, Michael Ben-Gershon wrote:

> It is intermittent, but very frequent. It is difficult to print more
> than about 10 sheets without it happening sometime.

Take a look at Documentation/parport.txt: see the 'Troubleshooting'
section.

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: lpr to HP laserjet stalls

[Horst von Brand]

Tim Waugh <twaugh@redhat.com> said:

[...]

> Take a look at Documentation/parport.txt: see the 'Troubleshooting'
> section.

Not in 2.4.9-ac7, at least.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: lpr to HP laserjet stalls

[Patrick Dreker]

Am Montag 03 September 2001 23:11 schrieb Tim Waugh:
> On Mon, Sep 03, 2001 at 11:05:29PM +0300, Michael Ben-Gershon wrote:
> > It is intermittent, but very frequent. It is difficult to print more
> > than about 10 sheets without it happening sometime.
>
> Take a look at Documentation/parport.txt: see the 'Troubleshooting'
> section.
I had the same problem here with my Epson Stylus Color 600. I did not matter 
whether I sent the output directly to the printer (cat file.txt > /dev/lp0) 
or used cups or lpd. It just stuck in random places. Fiddling with parport 
settings did not change anything.

In debugging the problem I found out that if one attaches an strace to the 
stuck output process (strace -p pid) the output continues. The strace always 
consisted of either write or read calls (can't remember right now, though 
write seems more logical) the first of which after attaching with strace was 
a request for 8192 Bytes which returned short with usually some 100 bytes. 
All folowing calls had the full 8192 requested Bytes as return value.

All of this vanished, when I replaced all occurrences of /dev/lp0 in my 
printer configuration by /dev/par0. I has been working flawlessly since then.

I have changed quite a bit on my system since that time, but using 
/dev/printers/0 under devfs also works fine here.

> Tim.
> */

-- 
Patrick Dreker
---------------------------------------------------------------------
> Is there anything else I can contribute?
The latitude and longtitude of the bios writers current position, and
a ballistic missile.        
                         Alan Cox on linux-kernel@vger.kernel.org

Re: lpr to HP laserjet stalls

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

On Mon, Sep 03, 2001 at 08:20:31PM -0400, Horst von Brand wrote:

> Not in 2.4.9-ac7, at least.

Well, it's not actually called 'Troubleshooting', I see.  Look for
'Reporting printer problems with parport'.

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: lpr to HP laserjet stalls

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

On Tue, Sep 04, 2001 at 02:56:56AM +0200, Patrick Dreker wrote:

> All of this vanished, when I replaced all occurrences of /dev/lp0 in my 
> printer configuration by /dev/par0. I has been working flawlessly since then.

crw-rw----    1 root     lp         6,   0 Aug 30 21:30 /dev/lp0
crw-------    1 root     root       6,   0 Aug 30 21:30 /dev/par0

Are you sure you didn't also upgrade the kernel? ;-)

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: lpr to HP laserjet stalls

[Michael Ben-Gershon]

Tim Waugh wrote:
> 
> On Mon, Sep 03, 2001 at 11:05:29PM +0300, Michael Ben-Gershon wrote:
> 
> > It is intermittent, but very frequent. It is difficult to print more
> > than about 10 sheets without it happening sometime.
> 
> Take a look at Documentation/parport.txt: see the 'Troubleshooting'
> section.

OK. Here it is:

Sep  3 00:33:28 linux kernel: 0x378: FIFO is 16 bytes
Sep  3 00:33:29 linux kernel: 0x378: writeIntrThreshold is 8
Sep  3 00:33:29 linux kernel: 0x378: readIntrThreshold is 8
Sep  3 00:33:29 linux kernel: parport0: PC-style at 0x378 (0x778)
[PCSPP,TRISTATE,COMPAT,EPP,ECP]
Sep  3 00:33:29 linux kernel: parport0: irq 7 detected
Sep  3 00:33:29 linux kernel: parport0: Printer, Hewlett-Packard HP LaserJet 6P
Sep  3 00:33:29 linux kernel: lp0: using parport0 (polling).

Here are the contents of the parport directory in /proc:

::::::::::::::
/proc/sys/dev/parport/parport0/autoprobe
::::::::::::::
CLASS:PRINTER;
MODEL:HP LaserJet 6P;
MANUFACTURER:Hewlett-Packard;
DESCRIPTION:Hewlett-Packard LaserJet 6P Printer;
COMMAND SET:PJL,MLC,PCLXL,PCL;
::::::::::::::
/proc/sys/dev/parport/parport0/autoprobe0
::::::::::::::
::::::::::::::
/proc/sys/dev/parport/parport0/autoprobe1
::::::::::::::
::::::::::::::
/proc/sys/dev/parport/parport0/autoprobe2
::::::::::::::
::::::::::::::
/proc/sys/dev/parport/parport0/autoprobe3
::::::::::::::
::::::::::::::
/proc/sys/dev/parport/parport0/base-addr
::::::::::::::
888     1912
::::::::::::::
/proc/sys/dev/parport/parport0/devices/lp/timeslice
200
::::::::::::::
/proc/sys/dev/parport/parport0/dma
::::::::::::::
-1
::::::::::::::
/proc/sys/dev/parport/parport0/irq
::::::::::::::
-1
::::::::::::::
/proc/sys/dev/parport/parport0/modes
::::::::::::::
PCSPP,TRISTATE,COMPAT,EPP,ECP
::::::::::::::
/proc/sys/dev/parport/parport0/spintime
::::::::::::::
500

As far as I can see, although IRQ 7 is detected, it is not used, so
I don't see how starting parport with irq=none would help. Could
CONFIG_PARPORT_PC_FIFO actually improve matters in such a situation?

Michael Ben-Gershon
mybg@netvision.net.il

Re: lpr to HP laserjet stalls

[Michael Ben-Gershon]

Tim Waugh wrote:
> 
> On Tue, Sep 04, 2001 at 02:03:03PM +0300, Michael Ben-Gershon wrote:
> 
> > Sep  3 00:33:29 linux kernel: parport0: PC-style at 0x378 (0x778)
> > [PCSPP,TRISTATE,COMPAT,EPP,ECP]
> 
> This is 'polling' mode.  So, three code paths left to try. :-)
> 
> > As far as I can see, although IRQ 7 is detected, it is not used, so
> > I don't see how starting parport with irq=none would help. Could
> > CONFIG_PARPORT_PC_FIFO actually improve matters in such a situation?
> 
> It could, yes.
> 
> I certainly wouldn't have expected stalls in polling mode though.  I
> wonder what's up with that.
> 
> It would be very useful to see if there's any change with (a)
> interrupt-driven, (b) PIO, or (c) DMA printing.

Please excuse my ignorance, but if it detects the IRQ and does not use it,
how is it possible to set up interrupt-driven mode?

I am not really a 'kernel hacker', but am posting here as I have not
managed to solve the problem elsewhere. So please tell me exactly what to
put on the kernel command line at start-up.

Many thanks,

Michael Ben-Gershon
mybg@netvision.net.il

Re: lpr to HP laserjet stalls

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Tue, Sep 04, 2001 at 02:21:31PM +0300, Michael Ben-Gershon wrote:

> Please excuse my ignorance, but if it detects the IRQ and does not use it,
> how is it possible to set up interrupt-driven mode?

For interrupt-driven mode: irq=auto dma=nofifo
For PIO mode: irq=auto dma=none
For DMA mode: irq=auto dma=auto

You need to check the 'dmesg' output after parport_pc has loaded to
see exactly what it will use though (i.e. whether it has detected
usable hardware).

The line that goes 'parport0: PC-style at 0x378 (0x778)' is the
important one.  Ignore the stuff in [brackets] at the end; if an
interrupt is mentioned it is using it; if a DMA channel is mentioned,
it is using it; and if it says 'using FIFO' then it's using the FIFO
with programmed IO (rather than DMA).

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: lpr to HP laserjet stalls

[Patrick Dreker]

Am Dienstag 04 September 2001 10:50 schrieb Tim Waugh:
> On Tue, Sep 04, 2001 at 02:56:56AM +0200, Patrick Dreker wrote:
> > All of this vanished, when I replaced all occurrences of /dev/lp0 in my
> > printer configuration by /dev/par0. I has been working flawlessly since
> > then.
>
> crw-rw----    1 root     lp         6,   0 Aug 30 21:30 /dev/lp0
> crw-------    1 root     root       6,   0 Aug 30 21:30 /dev/par0
>
> Are you sure you didn't also upgrade the kernel? ;-)
I must have been through approx. 20-30 Kernel Versions since that time 
(including some -test, -pre and -ac versions), so I would not rule out that 
possibility. Especially since I have not been able to reproduce this in the 
last few hours, and I must say, that I have really tried to ;-)

> Tim.
> */

-- 
Patrick Dreker
---------------------------------------------------------------------
> Is there anything else I can contribute?
The latitude and longtitude of the bios writers current position, and
a ballistic missile.        
                         Alan Cox on linux-kernel@vger.kernel.org

Re: lpr to HP laserjet stalls

[Michael Ben-Gershon]

Tim Waugh wrote:
> 
> On Tue, Sep 04, 2001 at 02:21:31PM +0300, Michael Ben-Gershon wrote:
> 
> For interrupt-driven mode: irq=auto dma=nofifo
> For PIO mode: irq=auto dma=none
> For DMA mode: irq=auto dma=auto
> 
> You need to check the 'dmesg' output after parport_pc has loaded to
> see exactly what it will use though (i.e. whether it has detected
> usable hardware).
> 
> The line that goes 'parport0: PC-style at 0x378 (0x778)' is the
> important one.  Ignore the stuff in [brackets] at the end; if an
> interrupt is mentioned it is using it; if a DMA channel is mentioned,
> it is using it; and if it says 'using FIFO' then it's using the FIFO
> with programmed IO (rather than DMA).


OK. Firstly I rebuilt the kernel (2.4.9) with CONFIG_PARPORT_PC_FIFO
enabled. I also configured the parallel driver to be a module, to enable
easier testing.

I found that whatever I did, printing was not stalled (this must be a
result of CONFIG_PARPORT_PC_FIFO).

However, I found that dmesg gave some strange messages every so often under
PIO and DMA modes.

	FIFO is stuck
	BUSY timeout
	dma write timed out

I don't know what they mean (the printing itself was not affected) but
I guess it would be better to avoid modes which give such messages.

At the moment I am loading the module with:

	insmod parport
	insmod parport_pc io=0x378,0xa800 irq=auto,auto dma=nofifo,nofifo

If there is anything more I should be doing, please let me know.

Thanks for all the help,

Michael Ben-Gershon
mybg@netvision.net.il

Re: lpr to HP laserjet stalls

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On Tue, Sep 04, 2001 at 04:22:19PM +0300, Michael Ben-Gershon wrote:

> I don't know what they mean (the printing itself was not affected) but
> I guess it would be better to avoid modes which give such messages.

They are normal, really, and are there to help debugging.

> At the moment I am loading the module with:
> 
> 	insmod parport
> 	insmod parport_pc io=0x378,0xa800 irq=auto,auto dma=nofifo,nofifo

So this is interrupt-driven printing but without using the ECP
hardware.  I wonder why CONFIG_PARPORT_PC_FIFO makes a difference.  It
shouldn't, really, and neither should building it as a module.

Strange.

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: lpr to HP laserjet stalls

[Michael Ben-Gershon]

Tim Waugh wrote:
> 
> On Tue, Sep 04, 2001 at 04:22:19PM +0300, Michael Ben-Gershon wrote:
> 
> > I don't know what they mean (the printing itself was not affected) but
> > I guess it would be better to avoid modes which give such messages.
> 
> They are normal, really, and are there to help debugging.
> 
> > At the moment I am loading the module with:
> >
> >       insmod parport
> >       insmod parport_pc io=0x378,0xa800 irq=auto,auto dma=nofifo,nofifo
> 
> So this is interrupt-driven printing but without using the ECP
> hardware.  I wonder why CONFIG_PARPORT_PC_FIFO makes a difference.  It
> shouldn't, really, and neither should building it as a module.

Building it as a module meant I didn't have to reboot for every time
I wanted to retest it with different parameters.

Michael Ben-Gershon
mybg@netvision.net.il

Re: lpr to HP laserjet stalls

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

On Tue, Sep 04, 2001 at 04:41:22PM +0300, Michael Ben-Gershon wrote:

> Building it as a module meant I didn't have to reboot for every time
> I wanted to retest it with different parameters.

I understand.  But I'm looking at the differences between a broken
system and a working system.  It seems from what you say to be:

- CONFIG_PARPORT_PC_FIFO
- Parport built as modules

So it seems as though it's either one of these, or the combination.

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: lpr to HP laserjet stalls

[Michael Ben-Gershon]

Tim Waugh wrote:
> 
> On Tue, Sep 04, 2001 at 04:41:22PM +0300, Michael Ben-Gershon wrote:
> 
> > Building it as a module meant I didn't have to reboot for every time
> > I wanted to retest it with different parameters.
> 
> I understand.  But I'm looking at the differences between a broken
> system and a working system.  It seems from what you say to be:
> 
> - CONFIG_PARPORT_PC_FIFO
> - Parport built as modules
> 
> So it seems as though it's either one of these, or the combination.

The modules side could possibly be explained by a possible h/w clash, with
the printer support loaded later than something which it may be clashing
with if loaded first - although I am a bit out of my depth in terms of
my understanding of the kernel boot process here. However, what is
interesting is that I originally had the problems when I upgraded to
the 2.4 kernel (and RH 7.1). I subsequently upgraded the h/w from a
PII 333 on a Tyan m/b to a P4 1.5G on an Asus m/b. The former was a mixed
PCI/ISA board, with both types of cards installed, whereas the latter
was all PCI. I had the same printer problem on both boards with kernel 2.4,
which makes the possibility of a h/w clash being the cause a bit remote.

The 2 changes above (I have not yet had a chance to try each in isolation)
fixed the problem.

Michael Ben-Gershon
mybg@netvision.net.il