On Mon, 11 Aug 2014, Alexei P wrote: > I believe the focus of this thread has gone in wrong direction. The question > should not be about how to disable the flood of "detected XactErr" messages, > but (a) why does it occur in this particular case, and (b) why there are so > many of them. > My opinion here is: > > (a) The fact of appearance of "detected XactErr" message indicates some > BRUTAL CONDITION with communication pipe on the particular USB port. Usually it means that the computer did not receive a reply packet in response to some packet it sent to the device. This could be because noise disrupted either the packet sent to the device or the reply packet, or because the device has crashed and isn't sending anything. > This > message is generated after the host hardware was unable to receive proper > protocol response from a device after THREE BACK-To-BACK ATTEMPTS (assuming > CERR in EHCI.c is set to 3). This means that this situation is not some > accidental signal glitch but a fatal condition on the pipe. Not true. People have observed conditions where the transaction errors occurred multiple times in a row (more than three) and then went away. There are examples hidden away in the email archives of such occurrences. You may be able to find some if you read through the email exchanges leading up to the commit that introduced the multiple-retry mechanism. > In other words, > the USB device has likely lost its configuration, or went dead. Therefore, > the host should not re-try this low-level transaction, and rather resort to > some higher-level recovery procedure (port reset and re-enumeration). Thus, > we are coming to (b): Since the initial assumption above is wrong, this conclusion is invalid. > (b) Instead of switching to recovery, the Linux USB driver attempts 32 > additional re-tries. As explained in (a), these retries serve no purpose, > except they generate really alarming debug logs that would be impossible to > miss. They do serve a purpose. Sometimes they are able to re-establish communication. > Sorry to reviving 2-years-old thread. My problem with Linux USB stack is why > it is doing extra 32 attempts to a dead link. What is the rationale behind > this 32-times "recovery policy"? The number 32 was picked more or less arbitrarily. Experience has shown, however, that 3 is definitely too small. 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
