Re: ulpt problem (USB_ERR_IOERROR)

On Monday 13 July 2009 03:41:02 Patrick Lamaiziere wrote:
> Le Sun, 12 Jul 2009 09:52:29 +0200,
>
> Hans Petter Selasky <hselasky_at_c2i.net> a écrit :
> > > But the printer hangs after the first job (the data led on the
> > > printer stay on):
> > > unlpt_open: using defrag write mode
> > > ulpt_write_callback:237: state=0x0 actlen=0
> > > ulpt_write_callback:237: state=0x1 actlen=32768
> > > ulpt_write_callback:237: state=0x1 actlen=32768
> > > ulpt_write_callback:237: state=0x1 actlen=32768
> >
> > The prints look good.
> >
> > Did you restart/repower the printer, before trying to print?
>
> Oh yes, several times.
>
> > What document format is being used on /dev/ulpt? Maybe you have to
> > use another format. Did you use the correct PPD file for your
> > printer? I have a brother printer here which uses USB, and claims to
> > support PCL 6, but whenever I print something in PCL 6, it's not
> > recognized. I found out I had to download a special PPD file, and
> > install foomatic-rip, for cups. Then it worked using the GDI protocol.
>
> No the format is good, I've saved the file sent by cups to unlpt0
> and tried this file several times on a 7.0-RELEASE
> (cat file > /dev/unlpt0). It works fine on 7.X.
> Now, i use this file on 8.0 to test without cups.
>
> But there was a small problem with your previous patch in usb_dev.c:
> static int
> usb_write(struct cdev *dev, struct uio *uio, int ioflag)
> {
> ...
>                 if (f->flag_have_fragment == 0) {
>                         USB_MBUF_RESET(m);
>                         io_len = m->cur_data_len;
>                         pdata = m->cur_data_ptr;
>                         if (io_len > uio->uio_resid)
>                                 io_len = uio->uio_resid;
>                         m->cur_data_len = io_len;
>                 } else {
>                         io_len = m->max_data_len - m->cur_data_len;
> ---                     pdata = m->cur_data_ptr + io_len;
> +++                     pdata = m->cur_data_ptr + m->cur_data_len;
>

Yes, you are right there. Should be fixed in USB P4. This patch is not yet in 
8-current.

>
> Now I've got some USB_ERR_STALLED errors but I'm able to print 3 or
> 4 times.
>
> unlpt_open: using defrag write mode
> ulpt_write_callback:237: state=0x0 actlen=29561
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_status_callback:369: error=USB_ERR_TIMEOUT
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_status_callback:369: error=USB_ERR_STALLED
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_write_callback:237: state=0x1 actlen=32768
> ulpt_status_callback:369: error=USB_ERR_STALLED
> ulpt_write_callback:237: state=0x1 actlen=29561
> ulpt_status_callback:369: error=USB_ERR_STALLED
> ulpt_status_callback:369: error=USB_ERR_STALLED
> (...)
>

The printing works besides from the status failing?

> It looks like there is a probem to get the status. FreeBSD 7.0 uses a
> flag USBD_SHORT_XFER_OK, so I tried to add a flag .short_xfer_ok = 1
> and to increase the timeout. But without luck.

Could you try increasing the timeout to 20 seconds? Maybe the printer USB 
firmware is really simple and can only do one request at a time?

> [ULPT_INTR_DT_RD] = { .type = UE_CONTROL,
>                 .endpoint = 0x00,       /* Control pipe */
>                 .direction = UE_DIR_ANY,
>                 .bufsize = sizeof(struct usb_device_request) + 1,
> 	        .flags = {.short_xfer_ok = 1},
>                 .callback = &ulpt_status_callback,
>                 .timeout = 5000,        /* 5 second */
>         },
>

--HPS