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 exceptionally long?
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 think.
OK, but it'll have a very similar name...