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

Tue Mar 27 17:00:27 UTC 2007

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

From: Markus Henschel <m.henschel at bally-wulff.de>
To: Hans Petter Selasky <hselasky at c2i.net>
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:55:58 +0200

 Hans Petter Selasky schrieb:
 > 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
 > 

 With the old ugen I did something like:

 int iDevice=open("/dev/ugen0.4", O_RDONLY);
 fcntl(iDevice, F_SETFL, O_NONBLOCK);

 Now the fcntl call fails. But instead this works and does the same:

 int iDevice=open("/dev/ugen0.4", O_RDONLY|O_NONBLOCK);

 I thought the O_NONBLOCK flag was just for the open call itself?!?
 Whatever, it does what I need :-)

 The only thing that keeps me from using the new usb stack is umass now.
 When inserting an usb flash memory stick it is detected and says umass
 attached to ii but then it takes ages (more that 30s) for the device
 files to become available. A "camcontrol rescan all" hangs during this
 time too.Is it possible to use the old umass with the new stack or just
 revert umass to an older version from you like 1.6.1?

 BTW: The performance of the new usb stack is great. umass throughput
 with the memory stick nearly increased by 50%!!

 -- 
 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