Konica Minolta PagePro 1300W not working since the introduction of back-channel API

[Andrej Podzimek]

Abstract:
Since the advent of back-channel API, my Minolta USB printer hasn't worked properly.

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.

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 filter...

This means that the data is transferred to the printer at the speed of 8kBps. For a 800 kB big print job, 100 seconds are needed for the transfer... Is it possible to disable the back-channel data transfers? (I mean, without tweaking the code...) Could I 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 (e. g. hardware failure). If you have any ideas on how to solve this matter, please give me a hint.