From owner-freebsd-usb@FreeBSD.ORG Tue Mar 27 09:53:05 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E385B16A402; Tue, 27 Mar 2007 09:53:04 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Received: from mail2.bally-wulff-berlin.de (mail2.bally-wulff-berlin.de [212.144.118.9]) by mx1.freebsd.org (Postfix) with ESMTP id CCFFF13C46C; Tue, 27 Mar 2007 09:53:03 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Message-ID: <4608E431.1030809@bally-wulff.de> Date: Tue, 27 Mar 2007 11:30:25 +0200 From: Markus Henschel MIME-Version: 1.0 To: Hans Petter Selasky References: <200703261413.l2QEDUNQ060832@www.freebsd.org> <200703261630.23223.hselasky@c2i.net> In-Reply-To: <200703261630.23223.hselasky@c2i.net> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2007 09:30:19.0565 (UTC) FILETIME=[893FFDD0:01C77052] Cc: freebsd-gnats-submit@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 09:53:05 -0000 Hans Petter Selasky schrieb: > On Monday 26 March 2007 16:13, Markus Henschel wrote: >>> Number: 110855 >>> Category: usb >>> Synopsis: ugen: interrupt in msgs are truncated when buffer is full >>> Confidential: no >>> Severity: serious >>> Priority: medium >>> Responsible: freebsd-usb >>> State: open >>> Quarter: >>> Keywords: >>> Date-Required: >>> Class: change-request >>> Submitter-Id: current-users >>> Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 >>> Closed-Date: >>> Last-Modified: >>> Originator: Markus Henschel >>> Release: 6.2 custom kernel >>> Organization: >> Bally Wulff Automaten GmbH >> >>> Environment: >> FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar 23 >> 21:28:38 CET 2007 >> prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 >> >>> Description: >> We use ugen for some user space drivers. When an interrupt in endpoint is >> used ugen creates a queue that is filled by the kernel. The user space >> driver is responsible for reading data from the device file. If this >> happens too slow the queue is full and new msgs arriving from the usb >> device are lost. This behavior is OK. >> >> The problem is that the queue is not a multiple of the interrupt in >> endpoints msgs size. So it is possible that the last msg in the queue is >> truncated. This is very hard to detect for a user space driver. The data >> stream seen by the user space driver will contain an incomplete msgs >> directly followed by the next message without knowing truncation happened >> (except when using some data corruption detection mechanism). >> >> It would be much better if ugen would fill the queues of interrupt in >> endpoints until there is no more space for a complete msg. This way the >> user space driver will not loose sync with the incoming msgs. > > The new USB stack has this fixed already. What I do is that the USB driver > stops polling the interrupt endpoint when the user-land application does not > read data. When the user-land application has read a packet, the interrupt > endpoint is started again. The only problem is that some devices, like a > Microsoft mouse I have, stops working immediately when its internal buffer > overflows. Bad hardware design. But if your hardware is not like that, the > new ugen, which is part of the new USB driver, will work great for you. > > Also packet alignment is kept between reads: Only one packet per read. > > See: > > http://www.turbocat.net/~hselasky/usb4bsd > > --HPS > Thanks, I gave it a try and it seems to work fine :-). Could you please explain how reading an interrupt in endpoint works internally with the new ugen? Is there still a buffer that recieves data from the endpoint or is each read request from user land synchronously triggering a read data request on the interrupt endpoint? Why isn't O_NONBLOCK working anymore? -- Regards, Markus Henschel Development BALLY WULFF Automaten GmbH Maybachufer 48-51 12045 Berlin Phone: +49(30)62002 161 FAX: +49(30)62002 230 http://www.ballywulff.de