When lp loads for the first time it runs parport_probe, which reports the
correct info to the log. The printer then goes into a sulk; print jobs are
accepted but disappear from the queue without getting printed.
Power-cycling the printer after the probe corrects the situation;
subsequent print jobs work fine (though I suspect that if I were to wait
long enough for the modules to get cleaned it might happen again).
The following make no difference:
BIOS settings: I tried normal, EPP and ECP.
parport_pc module options: tried explicitly setting ioport and irq
polling/interrupt driven are the same.
Recompiling the kernel with parport probing turned off solves the problem,
but if there's a lighter-weight way of turning off probing I couldn't find
it in the docs.
(using Kernel 2.2.16-3)
Tim, any ideas?
Put 'alias parport_probe off' in /etc/conf.modules.
I don't know why that particular printer gets upset with the probe though. Is
there any other peripheral in between it and the computer? Is the cable
Thanks 'alias parport_probe off' does the trick and means I can use the rpm
kernel. Presumably that's documented in general stuff about modules, rather
than being parport[_probe] specific?
The printer is the only peripheral attached to the port, and it's a bog standard
length cable. Are there any tests you would like me to run? I'll have the
machine for a while yet.
If you have tunelp around, you could try messing with the -C option, which puts
the kernel into or out of 'careful' mode.
I'll close this issue for now, since the issue was with parport_probe
unconditionally loading. If you can't get tunelp to fix things for when
parport_probe _does_ load, that probably should be a separate bugzilla bug I
OK, but it'll have a very similar name...