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? - 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 (b) Possibility of more frequent interrupts to the system during the duration where XactErrs are encountered (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) are there any more that we are missing? -hari -- 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
