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

Andrej Podzimek aa at quick.cz
Wed Oct 11 23:05:34 PDT 2006


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3898 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.cups.org/pipermail/cups/attachments/20061012/cb1c28ca/attachment.bin>


More information about the cups mailing list