On Sat, Feb 14, 2004 at 09:23:11PM +0100, Martin Diehl wrote:
> On Sat, 14 Feb 2004, Alan Stern wrote:
> 
> > > Feb 14 10:50:38 fliwatut kernel: hub 1-0:1.0: new USB device on port 1, assigned 
> > > address 2
> > > Feb 14 10:50:38 fliwatut kernel: drivers/usb/input/hid-core.c: ctrl urb status 
> > > -75 received
> > > Feb 14 10:50:38 fliwatut usb.agent[4385]: kernel driver hid already loaded
> > > Feb 14 10:50:43 fliwatut kernel: usb 1-1: control timeout on ep0out
> > > 
> > > It does work on my Intel-based laptop, though. 
> > 
> > This sounds depressingly like the infamous "VIA USB controller shuts down 
> > when receiving an overlong packet" problem.  That status -75 means the 
> > device tried to send more data than the computer asked it for.  (This may 
> > be a fairly common problem among low-speed HID devices.)  The "control 
> > timeout" message is a good indication that the USB controller has turned 
> > itself off.
> 
> IMHO it also sounds like a good example for what we have discussed 
> recently, i.e. up-rounding the DATA-IN transfer_length to multiple 
> maxpacket size.

The patch looks OK to me, and indeed it could make some devices that
send more data than we want working.

> Maybe something like the hack below. It compiles but is completely 
> untested (Well, my mouse is still working ;-). In fact I think there might 
> also be another issue in the hid-core which could easily trigger EOVERFLOW 
> on the int-in endpoint - see the comment in the patch below.

The int-in endpoint isn't active at the time the hid_init_reports()
function gets executed. The function only runs at init time, and the
int-in endpoint gets activated on open time. 

And open can't happen before init calls input_register_device().

So you can remove that comment and resend the patch, and I'll include it
into my tree and submit to Andrew and Linus later.

> However, in this particular case the overflow was apparently on the 
> control-data. But I have no idea how hid would behave with the trailing 
> babble-data. Well, if it works with Intel it might be worth trying it...

It'll just ignore the extra data. That's OK.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to