FS#35850 - parport stack configuration results in printing failure
Attached to Project:
Arch Linux
Opened by James (thx1138) - Wednesday, 19 June 2013, 04:11 GMT
Last edited by Tobias Powalowski (tpowa) - Sunday, 23 June 2013, 19:08 GMT
Opened by James (thx1138) - Wednesday, 19 June 2013, 04:11 GMT
Last edited by Tobias Powalowski (tpowa) - Sunday, 23 June 2013, 19:08 GMT
|
Details
Name : linux
Version : 3.9.6-1 Architecture : i686 Description: Something in the parallel port stack is causing a printing failure. On my Thinkpad T60 with port expander, with the parallel port connected to a Samsung ML-4500, which uses the ghostscript "gdi" device driver, printing works using a Debian kernel, "3.9-1-686-pae", but does not work with this Arch 3.9.6-1 i686 kernel. Same print file, generated with ghostscript and sent directly to the printer with "cat <file> > /dev/lp0", same "cat" program, same hardware. Oddly, printing to an HP LaserJet 4 Plus will work fine with both kernels. In particular, sending the file to the printer will wake-up the printer and show the blinking file-transfer light. Everything looks perfectly normal, except that, when the laser-scanning servo should start-up and the paper should feed - nothing happens. The printing just doesn't complete. I don't know what is different on the wire, between the file transfer that "works", and the one that does not. I tried the Arch linux-lts - but it hangs on boot, so I cannot say if it works. I tried the Arch linux-lqx kernel - it also fails to print the "gdi" print file. What is different about the Debian kernel? Or is there some other configuration difference? The Debian kernel dmesg reports: [ 12.304247] parport_pc 00:0a: reported by Plug and Play ACPI [ 12.304385] parport0: PC-style at 0x3bc (0x7bc), irq 7 [PCSPP,TRISTATE] [ 12.348090] parport0: Printer, Samsung ML-4500 [ 26.200230] lp0: using parport0 (interrupt-driven). The Arch kernel dmesg reports: [ 7.567551] parport_pc 00:0a: reported by Plug and Play ACPI [ 7.567706] parport0: PC-style at 0x3bc (0x7bc), irq 7, dma 0 [PCSPP,TRISTATE,COMPAT,ECP,DMA] [ 7.622980] parport0: Printer, Samsung ML-4500 [ 7.623180] lp0: using parport0 (interrupt-driven). Any thoughts? James |
This task depends upon
Closed by Tobias Powalowski (tpowa)
Sunday, 23 June 2013, 19:08 GMT
Reason for closing: Fixed
Additional comments about closing: on trunk
Sunday, 23 June 2013, 19:08 GMT
Reason for closing: Fixed
Additional comments about closing: on trunk
Also, assuming you mean "CONFIG_PARPORT_PC_FIFO", then yes, this would be a consistent difference between the Debian and Arch kernels - "is not set" in the Debian kernel, and "=y" in the Arch kernel.
Is it correct to suppose that, still, something is "broken" with the parport_pc driver when "using FIFO/DMA"?
Reference: "drivers/parport/Kconfig".
The "/proc/sys/dev/parport/parport0/*" seem to have all the correct values for the parallel port. The parameters don't have to be set explicitly, do they? I tried setting "options parport_pc dma=none", but it seemed to ignore this false dma setting. Is there some other way to temporarily disable dma without resorting to the BIOS setting?
A little searching shows other people still having problems with FIFO/DMA - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1152725. Is there anything else that is simple to test here - other than actually examining the wire output - or shall this be left to the kernel hackers?
Thanks
James