Having some parallel port issues (ok, stop laughing!). Can some people with parallel ports on their mobos (real ones, not usb-based ones) send me the output of:
tail -c+1 /proc/sys/dev/parport/parport0/{autoprobe,base-addr,dma,irq,modes}
I'm especially interested to see what you get if you have ECP mode set in the BIOS.
Also: dmesg |grep parport or grep parport /var/log/messages
My 2008 motherboard refuses to let linux use ECP, even though the BIOS says ECP. EPP seems to work, but doesn't give me a DMA. Other boards I've checked use EPP and DMA.
Without DMA, cups printing uses I/O polling and is ***SLOW*** and uses 100% cpu for 30s per page. Ouch.
To the zero people who are interested in the bugzilla, here's a link: https://bugzilla.redhat.com/show_bug.cgi?id=1180396
Maybe try specifying the IRQ manually, per https://www.kernel.org/doc/Documentation/parport.txt ? I haven't used a real parallel port under Linux since 2.2, so beyond that, no idea. -Adam
On 2015-01-10 Adam Thompson wrote:
Maybe try specifying the IRQ manually, per https://www.kernel.org/doc/Documentation/parport.txt ? I haven't used a real parallel port under Linux since 2.2, so beyond that, no idea.
Yup, that's like the only useful doc on the net, and I tried everything in there. The IRQ that is autoassigned is correct, and the port works, it's the lack of DMA that seems to be killing me.
I guess I'm the lucky owner of a buggy board (Intel!!!) or kernel... or both, as far as parport is concerned.
My point was this: "By default IRQs are not used even if they _can_ be probed."
What happens if you explicitly specify the (detected) IRQ on the kernel command line or modprobe options? Same thing?
-Adam
On 2015-01-10 Adam Thompson wrote:
My point was this: "By default IRQs are not used even if they _can_ be probed."
What happens if you explicitly specify the (detected) IRQ on the kernel command line or modprobe options? Same thing?
Yup. Unless you mean setting some other value. 7 is what is detected (seems to be a standard as most examples/outputs show it). I do/did specify it manually (and io addrs et al) during my tests, no change. I even tried some off the wall permutations/choices and only succeeded in getting nothing to print until setting it back to probed values.
I have a sneaking suspicion that this mobo has a f/w bug (and it's too late to report it to Intel), or kernel doesn't like my IO chip. Though the latter case is more hopeful, it also sucks because the interest in fixing a parallel port issue by kernel devs will be about negative 5.
I don't mind living with the problem (when do I need to print fast? and who cares about 100% cpu for 30s once in a blue moon), or just using a USB->serial doohicky (haven't tried yet), but my first inclination is always bug report + attempt to fix. It gives a chance for me to receive a great round of indifference.
(Further: yes, I'm using the latest mobo BIOS, no they don't mention parport problems in the notes. The BIOS gives an option for print mode only (output only, bidir, EPP, ECP), and (unlike other boards) no options for tweaking the ioaddr, irq, dma, etc. This BIOS also does not give a "PnP OS" option, which may have helped (by toggling), but I'm pretty sure that choice is hardcoded to NO in this example.)