Bug 8053 - lp0 dose not print unless I turn the printer on and off after reboot. Also after a while of being idle I have to turn the printer on and off
lp0 dose not print unless I turn the printer on and off after reboot. Also af...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.1
All Linux
high Severity high
: ---
: ---
Assigned To: Michael K. Johnson
jflaker@uswest.net
:
: 8054 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-12-29 15:48 EST by jflaker
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-01-19 08:43:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jflaker 1999-12-29 15:48:14 EST
If I reboot my linux box the printer has to be turned off and back on
befor it will print. the tunelp command reports busy. Also affter the
printer has set idle for a long while I have to turn it off and back on.
I need to have two printers connected to the server for our opperation.
lp1 dose not have the problem. If I setup three parallel devices and print
to lp1 and lp2 I don't have the problem. But if I only have two devices
and force lp0 to lp1 and lp1 to lp2 I still have the problem.
Comment 1 jflaker 1999-12-29 16:02:59 EST
modprobe dose not find the printers during bootup. And printtools ony find lp0
not lp1
Comment 2 jflaker 1999-12-29 16:33:59 EST
I do have parport_lowlevel parport_pc in my /etc/conf.modules. without it I
cannot print at all.
Comment 3 Bill Nottingham 1999-12-30 12:34:59 EST
*** Bug 8054 has been marked as a duplicate of this bug. ***
Comment 4 Bernhard Rosenkraenzer 2000-01-05 12:54:59 EST
This was a "feature" introduced in textutils 2.0 (sorting according to the
locale). I've reverted this behavior in 2.0a-1 (Raw Hide).
Comment 5 Bernhard Rosenkraenzer 2000-01-05 12:56:59 EST
Argh, sorry, the close and latest comment went to the wrong bug.
Never use Mozilla 5.0 betas with bugzilla. :/
Comment 6 Bernhard Rosenkraenzer 2000-01-05 12:59:59 EST
What printer are you using? Does tunelp -r help? Are you using SPP, EPP or ECP?
Comment 7 jflaker 2000-01-08 13:11:59 EST
I am using okidata microline 320 & 390 turbo. the tunelp /dev/lp0 -r dose not
help I have to turn the printer off and back on. tunlp /dev/lp0 -s reports
status 63, busy,ready , on line, out of paper. I have loaded 3 machines and all
three times I got the same problems.
Comment 8 jflaker 2000-01-08 13:13:59 EST
I have tryed SPP EPP AND ECP IT MAKES NO DIFFERENCE. ALSO I HAVE TRYED A IEEE
CABLE AND A PLANE CHEAP CABLE WITH NO DIFFERENCE
Comment 9 Joel Flaker 2000-01-12 15:22:59 EST
Has there been any update to this. I know that (raw hide) it will be fixed on
next version. is there a patch I can pick up. or any updated info on this
problem.
Comment 10 jflaker 2000-01-15 11:12:59 EST
I put scope on our parallel port to the printer. Every time I boot up, Linux
pulls the init line on pin 16. This init causes the Okidata 320 and 390 turbo to
go busy. This is why when we print to the printer we first have to turn it off
and back on. Now, when I let the printer sit with no activity for a hour or so
the first print job I do re-pulls the init line on pin 16 and causes the
printer to go busy again. Is their a reason you have to send a init after a
printer has been idle? Is their anything you can do? All of our customers use
320 or 390 turbos. I would like to switch to Linix but need the printer to work
reliable.
As a work around I have broke pin 16 off the parallel cable and my printer is
working fine. But I do not want to do this in our customers stores.
Please reply and give me some insight.
Comment 11 jflaker 2000-01-15 11:14:59 EST
I would be willing to send you a Okidata 390 turbo for testing this if
that would help us get this resolved.
Comment 12 Bernhard Rosenkraenzer 2000-01-19 08:43:59 EST
Tim Waugh thinks this is a bug in the parport driver in the kernel (port resets)

Note You need to log in before you can comment on or make changes to this bug.