Bug 50401

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.

*PLEASE*  try to get a fix out for this.. it's been frustrating me ever since I
upgraded.

I also have this problem.  I have found that if I use the Laserjet 1100 driver I get random 
stalls with exactly the same behavior as the previous commenter noted.  I have "resolved" 
my problem by switching to the generic laserjet driver which prevents the print queue from 
hanging.  Unfortunately I am limited to 300 dpi by this driver and cannot access the 
advanced features of the LJ 1100.

I also have the same problem with the HP LaserJet 1100. With the ljet4 driver,
it stalls after exactly 2 pages. This printer used to work very well in 6.2 and
it's a very nice printer so I hope this bug gets fixed soon.

I have the same problem printing to a LaserJet 6L.  The status line alternates
between "active" and "waiting for subserver to exit" and "cannot open '/dev/lp0'
- 'Device or resource busy', attempt <#>, sleeping 20".  If I wait a really long
time it eventually starts up again.  I have kernel 2.4.9-6 and glibc 2.2.4-19.
I stopped and restarted lpd and it seems to be working better now.  I also
deleted all but one job from the print queue.  Where it was previously freezing
once a page it now seems to go several pages without freezing and takes much
less time to recover from a freeze.  I have 32MB RAM in this box, which I
realize is tight, but it's the maximum the motherboard supports.  Naturally I
have ample swap space.

'fuser -v' shows that 'lpd (Worker-Print)', '/usr/share/printconf/mf_wrapper',
and '/usr/bin/magicfilter-t' all have the device file open.  Could one of these
be stepping on the others' toes?

If I 'strace -p' the magicfilter-t process, it unfreezes for a little while.  If
I break out of the strace, it also unfreezes for a little while.  When I do this
I get random characters on the page where the freeze occurred (in portrait
orientation, even if I'm printing in landscape mode).  I've also seen pages
split in two where the freeze occurred.  I think it may be time to follow the
advice from bug #43619:  delete all printer configurations, remove printconf and
printconf-gui, install printtool and rhs-printfilters from RH7.0, and
reconfigure the printers.

When I was strace'ing I found that the 'lpd' process had an outstanding read()
on fd 9 (not sure whether that's /dev/lp0).  The magicfilter-t process would
freeze in the middle of a write() call to stdout (presumably /dev/lp0).  Does
that mean this is a kernel bug?

This looks like a duplicate of #42663.


*** This bug has been marked as a duplicate of 42663 ***

This is fixed in 7.2 now, but 7.1 needs a different fix (which I don't yet know).