From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 07:29:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0832D106564A for ; Sun, 5 Jul 2009 07:29:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swipnet.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 9220A8FC14 for ; Sun, 5 Jul 2009 07:29:32 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=BQeo18V-fugA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=8kQB0OdkAAAA:8 a=rYzuquTPueXLEwDh6fUA:9 a=MGnlHCXEQf-HhHHV3ZUA:7 a=J8nZXcrQNjddW4vBWZWwvTFb9OUA:4 a=9aOQ2cSd83gA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 530246821; Sun, 05 Jul 2009 09:29:31 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 5 Jul 2009 09:29:07 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907040945.41153.hselasky@c2i.net> <20090704164341.0acd0271@baby-jane.lamaiziere.net> In-Reply-To: <20090704164341.0acd0271@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907050929.07784.hselasky@c2i.net> Cc: Patrick Lamaiziere Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 07:29:33 -0000 On Saturday 04 July 2009 16:43:41 Patrick Lamaiziere wrote: > Le Sat, 4 Jul 2009 09:45:40 +0200, > > Hans Petter Selasky 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