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

[michaelrsweet]

Version: 1.2.4
CUPS.org User: andrej

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

[michaelrsweet]

CUPS.org User: mike

It sounds like this printer doesn't support the USB printer protocol properly, so it probably needs special handling. Short of disabling bidi for all K-M printers (like we do for Canon USB printers), I'm not sure what we can do here...

Can you try changing the backend/usb-unix.c sources, specifically line 87 which reads:

use_bc = strcasecmp(hostname, "Canon") != 0;

to be:

use_bc = strstr(hostname, "Minolta") != NULL;

and let me know if that resolves the problem?

[michaelrsweet]

CUPS.org User: mike

[post via email - Andrej, please post using the web form in the future, since we currently don't add emails to bug reports automatically...]

Hello!

Many thanks for your advice. The printer operates flawlessly with the adjustment you suggested. Instead of using the 1.2.4 source, I downloaded and compiled the 1.3 source from SVN.

Both 1.2.4 and 1.3 sources don't get compiled out of the box. Perhaps they they're not getting on well with the 2.6.18 kernel I'm using. The situation was exactly the same with both 1.2.4 and 1.3 sources. The SCSI backends have to be disabled in order to compile CUPS. As I don't need SCSI support, I edited backend/Makefile and removed the scsi targets from the dependencies. After that I used autoconf. This is a standard ./configure command from the PKGBUILD for CUPS:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
--with-logdir=/var/log/cups -with-docdir=/usr/share/cups/doc
--with-cups-user=daemon --with-cups-group=lp --enable-ssl=yes
--enable-pam=yes --disable-ldap --disable-dbus

(PKGBUILD: A file specific to ArchLinux, which works like a Gentoo ebuild.)
(I have no idea why they disable dbus, but it works fine like that, so I didn't investigate into the matter.)

I built and installed the package using the standard ArchLinux packaging system. It worked fine. The printer reacts as quickly as it did before back-channel pipes appeared. The log file doesn't contain anything about back-channel data right now. (Great!)

This comment from backend/usb-unix.c applies to Minolta PagePro 1300W as well:
/*

• Disable backchannel data when printing to Canon USB printers - apparently
• Canon printers will return the IEEE-1284 device ID over and over and over
• when they get a read request...
  */

Hope this information will be useful to you. The problem seems to be solved. Again, many thanks for your advice.

Cheers!

Andrej

P. S. A detailed description of compilation problems and error messages follows. A possible workaround is to disable SCSI support, as mentioned above.

First of all, gcc says it cannot find sg.h included in backend/scsi-linux.c, line 57. That line looks like this:
#include <scsi/sg.h>
There is really no /usr/include/scsi/sg.h on my machine, for some reason or other. However, there is one in the kernel sources: /usr/src/linux/include/scsi/sg.h. I changed line 57 to be
#include "/usr/src/linux/include/scsi/sg.h"

That didn't help, for another error emerged:

Making all in backend...
Compiling scsi.c...
In file included from scsi-linux.c:57,
from scsi.c:84:
/usr/src/linux/include/scsi/sg.h:4:28: error: linux/compiler.h: není souborem ani adresá�em
In file included from scsi-linux.c:57,
from scsi.c:84:
/usr/src/linux/include/scsi/sg.h:96: error: expected ':', ',', ';', '}' or 'attribute' before '' token
/usr/src/linux/include/scsi/sg.h:109: error: expected ':', ',', ';', '}' or 'attribute' before '' token
/usr/src/linux/include/scsi/sg.h:176: error: expected ':', ',', ';', '}' or 'attribute' before '' token
In file included from scsi.c:84:
scsi-linux.c: In function 'print_device':
scsi-linux.c:205: error: 'sg_io_hdr_t' has no member named 'dxferp'
scsi-linux.c:206: error: 'sg_io_hdr_t' has no member named 'cmdp'
scsi-linux.c:207: error: 'sg_io_hdr_t' has no member named 'sbp'
scsi-linux.c:208: error: 'sg_io_hdr_t' has no member named 'timeout'
scsi-linux.c:219: error: 'sg_io_hdr_t' has no member named 'status'
scsi-linux.c:222: error: 'sg_io_hdr_t' has no member named 'status'
scsi-linux.c:231: error: 'sg_io_hdr_t' has no member named 'status'
make[1]: ** [scsi.o] Error 1

I guess all the sg.h errors are related to a macro called __user. That's the only thing lines 96, 109 and 176 in sg.h have in common. As for the errors in scsi-linux.c, they are bound with those in the header. I had a look at the struct called sg_io_hdr_t. All the "missing" members are present:

typedef struct sg_io_hdr
{
int interface_id; /* [i] 'S' for SCSI generic (required) /
int dxfer_direction; / [i] data transfer direction /
unsigned char cmd_len; / [i] SCSI command length ( <= 16 bytes) /
unsigned char mx_sb_len; / [i] max length to write to sbp /
unsigned short iovec_count; / [i] 0 implies no scatter gather /
unsigned int dxfer_len; / [i] byte count of data transfer _/
void _user *dxferp; / [i], [_io] points to data transfer memory
or scatter gather list */
unsigned char _user *cmdp; / [i], [_i] points to command to perform */
void _user *sbp; / [i], [o] points to sense_buffer memory */
unsigned int timeout; / [i] MAX_UINT->no timeout (unit: millisec) /
unsigned int flags; / [i] 0 -> default, see SG_FLAG... /
int pack_id; / [i->o] unused internally (normally) _/
void _user * usr_ptr; / [i->o] unused internally /
unsigned char status; / [o] scsi status /
unsigned char masked_status;/ [o] shifted, masked scsi status /
unsigned char msg_status; / [o] messaging level data (optional) /
unsigned char sb_len_wr; / [o] byte count actually written to sbp /
unsigned short host_status; / [o] errors from host adapter /
unsigned short driver_status;/ [o] errors from software driver /
int resid; / [o] dxfer_len - actual_transferred /
unsigned int duration; / [o] time taken by cmd (unit: millisec) /
unsigned int info; / [o] auxiliary information /
} sg_io_hdr_t; / 64 bytes long (on i386) */

It is obvious that the maro __user damages the declaration somehow, which prevents some of the members from compiling. This happens on all the lines where the __user macro appears as well as on those immediately following. Perhaps the macro only works when the whole kernel source is compiled, producing a different, final version of the header to be placed in /usr/include/scsi... Well, I've never explored the kernel sources before, so I have no idea.

[michaelrsweet]

CUPS.org User: andrej

Sorry about that. Will use the web interface next time.

[michaelrsweet]

CUPS.org User: mike

I don't know why you don't have the <scsi/sg.h> header installed (it is different than the kernel header), but I've added a configure test to compile the SCSI backend as a dummy program if <scsi/sg.h> is missing.

I also updated the USB backend to not use the back-channel code for Minolta USB printers.