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

[Markus Henschel]

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