I don't see how my patch could cause a transfer to return an actual_length of -4.
If it is my patch causing this problem, I suspect it would be because the nVidia EHCI controller handles the "inactivate" bit in an unexpected (and probably out of spec) way--I was able to test with Broadcom & Intel, but I didn't have an nVidia EHCI controller to test on. I guess it's possible that, when the "inactivate" bit is set, the nVidia EHCI controller sets the status to make it look like that transaction is finished, and maybe the inactivate bit was set early enough that actual_length never got initialized to anything and the -4 was just leftover in that memory space...? I suggest this without looking at the code--I don't know if that's actually possible. I'll try to locate a box with an nVidia EHCI controller today and see if I can reproduce this. Stuart -----Original Message----- From: Alan Stern [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 5:07 PM To: Pete Zaitcev Cc: Hayes, Stuart; USB development list Subject: Re: Bug in EHCI split-interrupt handling On Tue, 24 Jul 2007, Pete Zaitcev wrote: > On Tue, 24 Jul 2007 15:44:23 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=8535 > > > > contains logs suggestive of problems with EHCI split-interrupt > > handling. See in particular comment #33; the usbmon log in comment > > #32 contains a line in which a low-speed interrupt URB returns with > > status equal to 0 and actual_length set to -4. > > Nicolas sent me a trace out of band which had a similar entry: > ffff8100057f6100 1467276128 C Ii:2:004:1 0:8 -4 > > > Obviously this should never happen. Can anybody offer tips on where > > to go searching through the driver code for a solution? > > I'm going to double-check that usbmon is not deceiving you. It sure > looks totally bogus. Maybe I mixed up fields in a union somewhere. Maybe. Stuart Hayes has just added comment #42 in which he suggests this problem may be caused by the cpufreq adjustment patch he wrote. Stuart, could your patch cause a 4-byte low-speed interrupt transfer to return an actual_length of -4? Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
