[cups.bugs] [HIGH] STR #2019: Since the advent of back-channel API, Minolta USB printer hasn't worked properly.

[Andrej Podzimek]

[STR New]

This bug report contains the same information as my forum post:
http://www.cups.org/newsgroups.php?s1+gcups.bugs+v1+T0+Q1300W

A similar problem had been described in the bugs and features section: STR
#1705. Despite all the fixes, the problem persists.

Details:
Printer: Konica Minolta PagePro 1300W (GDI, low-end B/W laser, USB 1.1)
System: Asus M2N (Centrino laptop), USB 2.0
OS: ArchLinux 0.7.2, updated regularly, kernel 2.6.18 Vanilla (NOT the
distro kernel)
CUPS: 1.2.4
Ghostscript: 8.15.2
PPD: tried both the one included with foomatic and the one from
linuxprinting.org
Driver: min12xxw 0.0.9

Problem description:
My printer had been working flawlessly with CUPS for more than one year.
It always started printing very quickly, usually in less than three
seconds after a task was added. Now it takes approximately 10 minutes to
print one single page (A4). (!) This makes it virtually impossible to
print anything longer than one page.

Other facts:
Both UIs I tried, the localhost:631 and the KDE interface, didn't report
any error. The print job was just processed and (sometimes) claimed
finished. The printer status shown was "online" or "processing".

Thousands of lines like these appear in the error_log. (LogLevel debug)

D [06/Oct/2006:12:19:33 +0200] [Job 627] Wrote 8192 bytes of print data...
D [06/Oct/2006:12:19:33 +0200] [Job 627] Received 40 bytes of back-channel
data!
D [06/Oct/2006:12:19:34 +0200] [Job 627] Read 8192 bytes of print data...
D [06/Oct/2006:12:19:34 +0200] [Job 627] Received 40 bytes of back-channel
data!

I guess the printer keeps sending acknowledgements of some kind after each
8 kB of data, but nobody reads them.

There is always an offset of 1 second between the back-channel data lines.
It seems that there is a timeout (perhaps the one defined in
src/cups-1.2.4/cups/backend.c) that blocks the transfer and waits for the
driver to read the back-channel data. The driver obviously doesn't read
from the pipe. By the way, which driver should do so? The min12xxw? But
that's just a non-interactive filter...

This means that the data is transferred to the printer at the speed of 8
kBps. For a 800 kB big print job, 100 seconds are needed for the
transfer... Is it possible to disable the back-channel data transfers?
Could one at least set the timeout to 0 somehow?

The CUPS process behaves normally during the long transfer. I can see a
tree with min12xxw, ghostscript and foomatic-rip running. No huge memory
consumption, no excessive CPU usage.

I would like to avoid downgrading CUPS, as it would not solve the problem.
This "back-channel hypothesis" is just my wild guess, the whole problem
could be caused by something different. I strongly hope I'll be able to
print again some day...

Link: http://www.cups.org/str.php?L2019
Version: 1.2.4