usb/110855: ugen: interrupt in msgs are truncated when buffer is full

[Hans Petter Selasky]

The following reply was made to PR usb/110855; it has been noted by GNATS.

From: Hans Petter Selasky <hselasky at c2i.net>
To: Markus Henschel <m.henschel at bally-wulff.de>
Cc: freebsd-usb at freebsd.org,
 freebsd-gnats-submit at freebsd.org
Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full
Date: Tue, 27 Mar 2007 18:43:08 +0200

 On Tuesday 27 March 2007 11:30, Markus Henschel wrote:
 > 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 at 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?
 
 Yes, there is a buffer, but the buffer is packet-based, and not a "ring" 
 based, so you will never get problem with packet alignment.
 
 > Why isn't O_NONBLOCK working anymore? 
 
 It is implemented, and it should work. Can you explain more what is not 
 working?
 
 --HPS