Julius, I finally managed to generate some sensible (I hope) logs. The kernel is 3.2.60-rc3 with modifications as you requested. http://pastebin.com/6as4beZ3 This is an excerpt from syslog, showing messages logged immediately after a USB3 device (Areca ARC-5040) was plugged in. The OS was booted without any device plugged to USB3 ports, and booted seemingly normally. After the device was plugged in, similar messages as in the above file were logged 38 times, with ~30 second intervals. This was interspersed with various timeout messages. After ~18 minutes, device was recognized and filesystem mounted. Unfortunately the size of the full syslog file (from boot to FS mount) is 6 MB, and greatly exceeds pastebin limits. However, compressed file is significantly smaller. Can you indicate how would you like to receive it? (pbput to pastebin.com, email attachment, any other way?) http://pastebin.com/B431CEbp File xhci-ring.c with debug calls for your reference. One more thing: I have run into difficulty coaxing xhci_dbg to log anything by setting defines as you suggested. Instead I replaced definitions of xhci_dbg, xhci_info, xhci_err and xhci_warn in the following manner: #define xhci_dbg(xhci, fmt, args...) \ do { printk(KERN_ALERT "XHCI %s: " fmt, __FUNCTION__, ## args); } while(0) Some additional thoughts: > The piece of code you pointed out only affects single-segment > transfer rings. I think the kernel generally switched to using > multi-segment transfer rings for everything in commit 2fdcd47b69 > "xHCI: Allocate 2 segments for transfer ring", which explains why > the problem doesn't affect kernels after 3.2 Does this mean that in kernels after 3.2 the problematic code line (that toggles new_cycle_state) is never executed, i.e. dead code? > [...] in the old code, it [state->new_deq_ptr] refers to the > actual, final "new dequeue pointer" (the TRB that the ring will be > set to start at with the Set TR Dequeue Pointer command), which > should be one after cur->last_trb. Looking at the debug output, this appears to be happening in the new version as well, at least in this particular case. I will be on vacation for the rest of this week and the next one. I will try to answer emails, but unfortunately testing will have to wait until July 14th, when I am back. Thanks a lot Maciej Puzio -- 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