On Wed, 6 Dec 2006, Pete Zaitcev wrote:
> On Wed, 6 Dec 2006 10:55:21 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > [...] Some keyboards sometimes send more data than a single report in
> > a packet, leading to EOVERFLOW errors. The patch tries to fix things by
> > using a transfer length at least as large as the maxpacket size. I'm not
> > sure if this will fully fix the problem, though -- if the device actually
> > does stick more than one report in a single packet then the driver will
> > need to parse them all, and the patch doesn't try to do that.
>
> Unfortunately, they do send two reports in one packet, so I had to
> abandon my own version of it.
It shouldn't be very hard to parse more than one report per packet.
> The situation does not happen all that
> often.
It happens quite a lot for one of the users in this bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=6584
> We have to ignore interrupts long enough for two reports to
> batch together. In 2.6.18 at least we reset the device if it gets stuck,
> so for me this is not as urgent as it was in 2.6.9 times.
The bad behavior is triggered by a KVM (no surprise there). Details in
the bug report.
> The other one looks ok, although doesn't it reopens the way for that
> situation when the CPU spins and does not allow disconnect to proceed?
> It needs the parameter set for it first, but still.
Shouldn't any reasonable HID device have bInterval set to something > 1?
That would prevent spinning.
Alternatively, when the kvm parameter is set we could invoke the
hid_io_error() handler as we do now, but make it retry indefinitely rather
than issue a reset after 1 second. Perhaps that would be safer.
Alan Stern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
