Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Mar 2007 18:43:08 +0200
From:      Hans Petter Selasky <hselasky@c2i.net>
To:        Markus Henschel <m.henschel@bally-wulff.de>
Cc:        freebsd-gnats-submit@freebsd.org, freebsd-usb@freebsd.org
Subject:   Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full
Message-ID:  <200703271843.08145.hselasky@c2i.net>
In-Reply-To: <4608E431.1030809@bally-wulff.de>
References:  <200703261413.l2QEDUNQ060832@www.freebsd.org> <200703261630.23223.hselasky@c2i.net> <4608E431.1030809@bally-wulff.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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



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