On Tue, Nov 21, 2000 at 07:51:40PM -0500, Gene Heskett wrote:
> If you are *real* quick with a run of lpq within a second of having
> something dumped to lp0
No, this isn't a print spooler problem, it's a printer driver
(kernel-mode) and/or hardware issue.
I think the way to trace it would be to try to find something that
works, and see what's different from the situation you have.
I think you mentioned that you have 'lp0 on fire' messages: in that
case, try playing with tunelp. I think you want to turn off 'careful'
mode.
Also, you could try fiddling with the BIOS settings for the port for a
start, if you haven't done so already.
You could also play with the print driver settings. The most reliable
mode should be polling, non-hardware-assisted. So, if you set your
port to SPP in the BIOS, and make sure to specify 'irq=none' (or just
don't specify an irq) in the parport_pc options when you load it, it
really ought to work, modulo the 'careful' thing that you can adjust
with tunelp.
Check that it really is using polling rather than interrupt-driven
mode by seeing what it says in 'dmesg', or by looking at
/proc/parport/0/hardware.
You want to turn off the IEEE 1284 probe, too, because that can
confuse some peripherals. 'alias parport_probe off' in
/etc/modules.conf, if you built the kernel modular (I recommend you do
for debugging problems like this).
Basically, try to make the printer driver do the simplest thing: just
write data to the port and strobe each byte. Nothing else.
(Like Linux 2.0.x does: if you want, you could try 2.0.x and see if
that's any better..)
Tim.
*/
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Wed Nov 22 2000 - 05:49:41 EST