> Bug #1: Failure of get_device_list() to find configured devices with major=6
>
> This bug has been observed on two different machines; mine, under both
> 2.0.35 and 2.1.120, and the print server at VA Research (according to Rob
> Walker, copied above).
> My machine under 2.0.35 and VAR's print server can both print
> through lp1, despite the fact that "cat /proc/devices" doesn't show "6 lp"
> as it apparently should. So the lp device is functional in these
> configurations but it's invisible under /proc. What's up with *that*?
I haven't managed to reproduce that with lp as a module -- I'll link it in
with the kernel in a minute and see what happens then. I can't begin to
imagine what could be causing that, I'm afraid.
> Bug #2: Something isn't right in the 2.1.xx lp initialization
>
> My machine under 2.1.120 cannot print. Attempts to cat to /dev/lp0
> or /dev/lp1 yield "Operation not supported by device".
Hmm. Works for me.. ;-)
Again, I've got lp as a module. I'll use your config options and take a
look though.
If you could send the output of "dmesg", that would help out a lot.
> I suspect this has something to do with the facts that (a) the port
> address configured for the port is 378, which would normally be lp1,
> (b) /proc/parport contains only the entry `0', and (c) the 2.1.xx
> driver, unlike the 2.0.xx driver, tries to map port addresses
> to devices dynamically.
> Frobbing lp boot time options has yielded no good result.
If you only have one parallel port, which I think is what you've
described, then you can expect /dev/lp0 to be the right device. To make
sure, you could try booting with:
parport=0x378 lp=parport0
on the kernel command line. (Or something like that - check
Documentation/parport.txt and drivers/char/lp.c.)
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/faq.html