On Wed, 20 Feb 2013, Haribabu Narayanan wrote: > Hi all, > > We are facing an issue in one of our platforms which seems to be > indirectly related to how close USB transactions are attempted (in > case of failed transactions). In the EHCI layer, we have these two > defines that deal with retries for failed USB transactions: > > #define EHCI_TUNE_CERR 3 > #define QH_XACTERR_MAX 32 > > Would appreciate any help with the following questions: > > - Are EHCI_TUNE_CERR and QH_XACTERR_MAX applicable to exactly the same > set of bus-level errors (namely the single error: XactErr) ? Or in > other words, are only the errors that are retried in EHCI-software by > using QH_XACTERR_MAX benefiting by the use of EHCI_TUNE_CERR set to a > value > 1? Yes, I believe so. It would be necessary to read through the EHCI spec very closely to make sure, however. You'd have to check that in every situation where the error counter decrements to 0, the transaction fails with XactErr status. > - We are contemplating reducing EHCI_TUNE_CERR from 3 to 1 (while > keeping QH_XACTERR_MAX the same). This helps us because SW is > involved with subsequent retries and there is a finite amount of delay > involved there. What are the effects on the system if we do this ? I > can think of the following few : > > (a) Possible reduced throughput in case the USB device responds poorly Yes. > (b) Possibility of more frequent interrupts to the system during the > duration where XactErrs are encountered This will be a very small effect. Most likely all three retries would occur during the same microframe anyway, and interrupts occur only at microframe boundaries. > (c) Possible impact on the robustness (of dealing with badly behaving > devices or bad bus conditions) as the effective number of retries are > now reduced from 32*3 to 32*1. We can surely counter this by > increasing QH_XACTERR_MAX to (32*3) Again unlikely to have much effect. If the device or bus is that badly behaved or that noisy, you probably shouldn't be using it at all. > are there any more that we are missing? I can't think of any. Have you tried making this change? Does it really help at all? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
