OK, I'm seeing an issue that I'm pretty sure is the same thing... the keyboard is all kind of goofy (loses keys, repeats keys), then quits working, then the system locks up, only when my patch is enabled and I'm getting (faked) cpu frequency transitions. It definitely appears to be some incompatibilty between the nVidia EHCI controller and my patch.
I'm debugging now. (And struggling to remember how this all works! I don't work with the USB code every day.) Thanks Stuart -----Original Message----- From: Hayes, Stuart Sent: Wednesday, July 25, 2007 1:50 PM To: 'Pete Zaitcev' Cc: [EMAIL PROTECTED]; linux-usb-devel@lists.sourceforge.net Subject: RE: Bug in EHCI split-interrupt handling I'm working on it, Pete. I've got a system with an nVidia EHCI controller (unfortunately it's an Intel box, not AMD, since the failing systems are AMD), and I'm working to reproduce the issue. I acknowledge that this issue is probably caused by this patch. I suspect that what's going on is that the nVidia EHCI controller isn't responding to the "inactivate" bit correctly. I think I will find the answer more quickly (and I'll be more certain that I've got the right answer) if I can work on a system that exhibits the problem. Thanks Stuart -----Original Message----- From: Pete Zaitcev [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 25, 2007 1:45 PM To: Hayes, Stuart Cc: [EMAIL PROTECTED]; linux-usb-devel@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: Bug in EHCI split-interrupt handling On Wed, 25 Jul 2007 08:13:45 -0500, <[EMAIL PROTECTED]> wrote: > [...] 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. No, Stuart, this won't do. I need you to look at the code, because: a) I have explored the obvious avenues already, and b) We know that unsetting CONFIG_CPU_FREQ clears the issue. The initialization of actual_length is done unconditionally in usb_submit_urb, it was the first thing I checked! I have two vague hypotheses (-sii?) currently: #1 Somehow your patch conflicts with the insertion code which moves dummy qTD around. #2 The length in QH gets desynched from length in QTD, and we have a pice of code which takes the qh->hw_token and uses it for length calculation against qtd->length. -- Pete ------------------------------------------------------------------------- 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
