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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture i686
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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
Comment by Jan de Groot (JGC) - Wednesday, 19 June 2013, 08:21 GMT
Probably CONFIG_PARPORT_FIFO that we have enabled in our kernel. Looks like you have an ECP port, how is your parallel port configured in BIOS?
Comment by James (thx1138) - Wednesday, 19 June 2013, 16:04 GMT
Yes, ECP. And yes, selecting instead "Bi-directional" in the BIOS, the ML-4500 printer operates properly. Hmm...

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
Comment by Tobias Powalowski (tpowa) - Sunday, 23 June 2013, 19:08 GMT
will be in next rebuilds

Loading...