Re: [linux-usb-devel] EHCI Regression in 2.6.23-rc2
David Brownell wrote: On Monday 13 August 2007, [EMAIL PROTECTED] wrote: With the VIA controller I have, Which kind is that? The VT6202 is buggy as all get-out, and they sold a *LOT* of those discrete chips for use in add-on PCI cards. We generally warn people away from those. A more current version is the VT6212, which was much more usable. (If it says EHCI 0.95, it's a VT6202... their EHCI 1.0 chips were much better.) Where exactly should I search for this? Neither lspci nor lsusb showed any hint on the EHCI rev. the chip conforms to.. [..] Perhaps for now the best thing would just be to bypass the EHCI CPU frequency notifier code (i.e., my patch) for VIA EHCI controllers, since they are broken. Would a hard-coded blacklist (just an if (manufacturer==VIA)... type thing) be OK? Yes ... although if you don't need to blacklist their EHCI 1.0 chips don't do it. (Any VIA EHCI integrated into a southbridge is going to follow spec rev 1.0 pretty well, modulo idiosyncratic timings.) I guess its needed to blacklist even the ECHI 1.0 chips, since my problem is with exactly one of those ;) I'm not really into USB protocol specs, but perhaps its possible to test wether the problem Stuarts patch addressed can actually happen on VIA EHCI chips? Perhaps those guys solved the problem in Hard/Firmware.. I've also acquired a card with an NEC EHCI controller on it, which I'm going to look at while I'm into it... Another case where there are a lot of add-on EHCI 0.95 cards; but in this case the quirks were less significant. Some guy donated me a PCMCIA card with one of those, cause it'll wont work in his Windows only Notebook :) Greetings Daniel Exner - 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
Re: [linux-usb-devel] EHCI Regression in 2.6.23-rc2
On Monday 13 August 2007, Daniel Exner wrote: David Brownell wrote: On Monday 13 August 2007, [EMAIL PROTECTED] wrote: With the VIA controller I have, Which kind is that? The VT6202 is buggy as all get-out, and they sold a *LOT* of those discrete chips for use in add-on PCI cards. We generally warn people away from those. A more current version is the VT6212, which was much more usable. (If it says EHCI 0.95, it's a VT6202... their EHCI 1.0 chips were much better.) Where exactly should I search for this? Neither lspci nor lsusb showed any hint on the EHCI rev. the chip conforms to.. The driver logs that information as it starts; on this sytem: ehci_hcd :00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 vs EHCI 0.95. [..] Perhaps for now the best thing would just be to bypass the EHCI CPU frequency notifier code (i.e., my patch) for VIA EHCI controllers, since they are broken. Would a hard-coded blacklist (just an if (manufacturer==VIA)... type thing) be OK? Yes ... although if you don't need to blacklist their EHCI 1.0 chips don't do it. (Any VIA EHCI integrated into a southbridge is going to follow spec rev 1.0 pretty well, modulo idiosyncratic timings.) I guess its needed to blacklist even the ECHI 1.0 chips, since my problem is with exactly one of those ;) Something doesn't add up then ... above you ask where to find that info, but here you say you already got it from somwhere ... ? I'm not really into USB protocol specs, but perhaps its possible to test wether the problem Stuarts patch addressed can actually happen on VIA EHCI chips? Perhaps those guys solved the problem in Hard/Firmware.. Theoretically possible, and I've certainly seen hardware made to do stranger things than that. I've also acquired a card with an NEC EHCI controller on it, which I'm going to look at while I'm into it... Another case where there are a lot of add-on EHCI 0.95 cards; but in this case the quirks were less significant. Some guy donated me a PCMCIA card with one of those, cause it'll wont work in his Windows only Notebook :) A NEC 0.95 ?? Should be fine with Linux. Assuming no bugs have crept in. - Dave - 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
Re: [linux-usb-devel] EHCI Regression in 2.6.23-rc2
David Brownell wrote: On Monday 13 August 2007, Daniel Exner wrote: [..] Where exactly should I search for this? Neither lspci nor lsusb showed any hint on the EHCI rev. the chip conforms to.. The driver logs that information as it starts; on this sytem: ehci_hcd :00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 vs EHCI 0.95. ehci_hcd :00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 Build into: 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] I've also acquired a card with an NEC EHCI controller on it, which I'm going to look at while I'm into it... Another case where there are a lot of add-on EHCI 0.95 cards; but in this case the quirks were less significant. Some guy donated me a PCMCIA card with one of those, cause it'll wont work in his Windows only Notebook :) A NEC 0.95 ?? Should be fine with Linux. Assuming no bugs have crept in. Didn't test it yet with 2.6.23-rc2 or rc3, but up to 2.6.22 it was fine :) Regarding the option to blacklist VIA in the module: I would prefer blacklisting VIA by default but giving the module some parameter like honours inactive bit to override this. Perhaps there are newer VIA Chips out there, that indeed do this and some users trigger happy enough to test this. :) Greetings Daniel Exner - 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
Re: [linux-usb-devel] EHCI Regression in 2.6.23-rc2
Daniel Exner wrote: Jiri Kosina wrote: On Fri, 10 Aug 2007, Daniel Exner wrote: Please CC me, as I'm currently not subscribed to this list, thx. Please also don't forget to CC relevant people/lists when reporting bugs, thanks. Guess its ok, now? Thanks anyway :) After some serious hangs with 2.6.23-rc2 I did some bisects and this was the result: 196705c9bbc03540429b0f7cf9ee35c2f928a534 is first bad commit commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 Author: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thu May 3 08:58:49 2007 -0700 I guess that the patch attached to bug 8535 in kernel.org bugzilla -- http://bugzilla.kernel.org/attachment.cgi?id=12228action=view -- solves your issues, right? Nope, this does _not_ fix my issue. Anything else I could try, or some files you need? I tried finding some clue in my logs, but without any results so far. Greetings Daniel Exner It appears that the VIA controllers just ignore the inactivate bit completely. Normally, when I set the inactivate bit in the QH and then watch the QH overlay, I eventually see the controller clear the active bit in the overlay token, and, of course, it doesn't do the transaction. With the VIA controller I have, after I set the inactivate bit, I eventually see the controller set bit 1 in the overlay token (SplitXstate), indicating that it's running the transaction, and, a couple microframes later, it clears that bit again. The transaction is not inactivated. The problem occurs if a transaction completes when the inactivate bit is set... qh_completions will ignore the transaction until the inactivate bit is cleared, and then, when the transaction should be re-activated, my patch will set the active bit back to 1 in the overlay qtd token, even though the transaction was already completed by the controller... To work around this, I'd have to re-write my patch so that it didn't depend on the inactivate bit at all... I suppose it could possibly be done just by directly manipulating the active bit in the overlay token, since already the code doesn't mess with the overlay if there's any chance that the transaction is alrady cached or in progress, but that would be tricky. Perhaps for now the best thing would just be to bypass the EHCI CPU frequency notifier code (i.e., my patch) for VIA EHCI controllers, since they are broken. Would a hard-coded blacklist (just an if (manufacturer==VIA)... type thing) be OK? I've also acquired a card with an NEC EHCI controller on it, which I'm going to look at while I'm into it... Thanks Stuart - 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
Re: [linux-usb-devel] EHCI Regression in 2.6.23-rc2
On Monday 13 August 2007, [EMAIL PROTECTED] wrote: With the VIA controller I have, Which kind is that? The VT6202 is buggy as all get-out, and they sold a *LOT* of those discrete chips for use in add-on PCI cards. We generally warn people away from those. A more current version is the VT6212, which was much more usable. (If it says EHCI 0.95, it's a VT6202... their EHCI 1.0 chips were much better.) after I set the inactivate bit, I eventually see the controller set bit 1 in the overlay token (SplitXstate), indicating that it's running the transaction, and, a couple microframes later, it clears that bit again. The transaction is not inactivated. ... Perhaps for now the best thing would just be to bypass the EHCI CPU frequency notifier code (i.e., my patch) for VIA EHCI controllers, since they are broken. Would a hard-coded blacklist (just an if (manufacturer==VIA)... type thing) be OK? Yes ... although if you don't need to blacklist their EHCI 1.0 chips don't do it. (Any VIA EHCI integrated into a southbridge is going to follow spec rev 1.0 pretty well, modulo idiosyncratic timings.) I've also acquired a card with an NEC EHCI controller on it, which I'm going to look at while I'm into it... Another case where there are a lot of add-on EHCI 0.95 cards; but in this case the quirks were less significant. - Dave - 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
Re: [linux-usb-devel] EHCI Regression in 2.6.23-rc2
Jiri Kosina wrote: On Fri, 10 Aug 2007, Daniel Exner wrote: Please CC me, as I'm currently not subscribed to this list, thx. Please also don't forget to CC relevant people/lists when reporting bugs, thanks. Guess its ok, now? Thanks anyway :) After some serious hangs with 2.6.23-rc2 I did some bisects and this was the result: 196705c9bbc03540429b0f7cf9ee35c2f928a534 is first bad commit commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 Author: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thu May 3 08:58:49 2007 -0700 I guess that the patch attached to bug 8535 in kernel.org bugzilla -- http://bugzilla.kernel.org/attachment.cgi?id=12228action=view -- solves your issues, right? Nope, this does _not_ fix my issue. Anything else I could try, or some files you need? I tried finding some clue in my logs, but without any results so far. Greetings Daniel Exner - 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
Re: [linux-usb-devel] EHCI Regression in 2.6.23-rc2
On Fri, 10 Aug 2007, Daniel Exner wrote: Please CC me, as I'm currently not subscribed to this list, thx. Please also don't forget to CC relevant people/lists when reporting bugs, thanks. After some serious hangs with 2.6.23-rc2 I did some bisects and this was the result: 196705c9bbc03540429b0f7cf9ee35c2f928a534 is first bad commit commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 Author: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thu May 3 08:58:49 2007 -0700 I guess that the patch attached to bug 8535 in kernel.org bugzilla -- http://bugzilla.kernel.org/attachment.cgi?id=12228action=view -- solves your issues, right? Stuart, did you submit this fix for upstream already please? -- Jiri Kosina - 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
Re: [linux-usb-devel] EHCI Regression in 2.6.23-rc2
Jiri Kosina wrote: On Fri, 10 Aug 2007, Daniel Exner wrote: After some serious hangs with 2.6.23-rc2 I did some bisects and this was the result: 196705c9bbc03540429b0f7cf9ee35c2f928a534 is first bad commit commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 Author: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thu May 3 08:58:49 2007 -0700 I guess that the patch attached to bug 8535 in kernel.org bugzilla -- http://bugzilla.kernel.org/attachment.cgi?id=12228action=view -- solves your issues, right? Stuart, did you submit this fix for upstream already please? Yes... http://marc.info/?l=linux-usb-develm=118598561010046w=2 However, I have not tested this with a VIA EHCI controller (though it's been tested with Intel, Broadcom, and nVidia). This patch uses the inactivate bit in the QH, which wasn't previously used by the linux kernel, and I found that the different vendors of EHCI controllers (Intel, Broadcom, nVidia) all handle this a little differently. There's probably something about the way VIA controllers respond to seeing this bit set that is breaking things. I'll try to get my hands on a VIA EHCI controller so I can look at this... if you happen to know of an add-in card that has one of these, please let me know! It would be a lot easier for me to debug this myself here than to try to get someone else to run test kernels for me... - 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
