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.
modprobe dose not find the printers during bootup. And printtools ony find lp0 not lp1
I do have parport_lowlevel parport_pc in my /etc/conf.modules. without it I cannot print at all.
*** Bug 8054 has been marked as a duplicate of this bug. ***
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).
Argh, sorry, the close and latest comment went to the wrong bug. Never use Mozilla 5.0 betas with bugzilla. :/
What printer are you using? Does tunelp -r help? Are you using SPP, EPP or ECP?
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.
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
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.
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.
I would be willing to send you a Okidata 390 turbo for testing this if that would help us get this resolved.
Tim Waugh thinks this is a bug in the parport driver in the kernel (port resets)