> c) I you remove a print job out of the queue and the printer is
> off, you get a kernel trap (from /var/log/warn or
> /var/log/messages)
> please look at attechment "warn"
This is odd. The problem is that lp is trying to write to a parport it
hasn't claimed, but I can't see how that could happen. Can you try to
reproduce the problem without using the print spooler and let me know how
to repeat it? Just use 'echo > /dev/lp0' instead of queueing a job.
Otherwise, please tell me _exactly_ what you do, starting from the
beginning. What modules do you start off with? When do you turn on/off
the printer? When do you insmod parport_pc? What does 'lsmod' say
after the oops? Things like that.
> d) the parport_pc-module is not loaded automatically, when the
> printserver is started. As a result, the printserver cant find a
> configured lp0 (or another lp) port. If you do a insmod parport_pc
> and afterwards the printserver is restarted, printing is possible.
Yes, this is deliberate, and documented. The parport_lowlevel thing won't
work any more; you need to put something like 'post-install parport
modprobe parport_pc' in conf.modules. On the other hand, you can load
parport_pc _after_ lp now, and have it work properly.
Tim.
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/