Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Jul 2009 09:29:07 +0200
From:      Hans Petter Selasky <hselasky@c2i.net>
To:        freebsd-current@freebsd.org
Cc:        Patrick Lamaiziere <patfbsd@davenulle.org>
Subject:   Re: ulpt problem (USB_ERR_IOERROR)
Message-ID:  <200907050929.07784.hselasky@c2i.net>
In-Reply-To: <20090704164341.0acd0271@baby-jane.lamaiziere.net>
References:  <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907040945.41153.hselasky@c2i.net> <20090704164341.0acd0271@baby-jane.lamaiziere.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 04 July 2009 16:43:41 Patrick Lamaiziere wrote:
> Le Sat, 4 Jul 2009 09:45:40 +0200,
>
> Hans Petter Selasky <hselasky@c2i.net> a =E9crit :
> > > ulpt_write_callback:220: state=3D0x1 actlen=3D2889
> > > ulpt_write_callback:220: state=3D0x1 actlen=3D3023
> >
> > These two lines are interesting. Are these printed when doing the
> > same job?
>
> Yes.
>
> > If the actlen is not a factor of 64 in your case, the printer will
> > think that the document has ended. Could you verify that, that cups
> > is feeding too little data into the ULPT port?
>
> Sometime cups writes only a litle amount of datas:
>
> [Job 40] Read 161 bytes of print data...
> [Job 40] Wrote 161 bytes of print data...
> [Job 40] Read 251 bytes of print data...
> [Job 40] Wrote 251 bytes of print data...
> [Job 40] Read 162 bytes of print data...
> [Job 40] Wrote 162 bytes of print data...
> [Job 40] Read 86 bytes of print data...
> [Job 40] Wrote 86 bytes of print data...
> [Job 40] Read 3292 bytes of print data...
> [Job 40] Wrote 3292 bytes of print data...
> [Job 40] Read 43 bytes of print data...
> [Job 40] Wrote 43 bytes of print data...
> [Job 40] Read 4096 bytes of print data...
> [Job 40] Wrote 4096 bytes of print data...
>
> Cups uses a select() on the input file to print, reads the datas and
> writes them to the usb port until the input file is empty.
>
> There is no warranty that the amount of datas will be a factor of 64
> bytes.

It is not right to defragment the data in /dev/ulpt either. Maybe I can mak=
e a=20
variant device, /dev/udlpt, that will automatically defrag the data.

What happens if you dd if=3Dmyjob.pcl.or.ps of=3D/dev/ulpt bs=3D1024

=2D-HPS




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907050929.07784.hselasky>