Hi,
this is an updated copy of my report at:
https://bugzilla.kernel.org/show_bug.cgi?id=70781
The two dmesg reports can be found there.
Regards,
Andreas Reis
---
[xhci_hcd] reset SuperSpeed, xhci_drop_endpoint called with disabled ep,
Error in queuecommand_lck: task blocked
Corsair Voyager GT 3.0 32GB on an Intel Z87. I'm using it mostly to
store source code and as ccache directory, ie. lots of small reads &
writes. That's also when the bug happened so far.
Currently on 3.14-rc3 (self-compiled on Arch), ie. with the other xhci
revert-fixes already applied.
Happens since 3.14 development started. Can't remember ever having
anything like it occur on 3.13.
The error always follows the same sequence — with apparently varying
addresses — though I cannot (or don't know how to) trigger it manually:
1. usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd
2. xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled
ep ffff880428207900
3. usb-storage: Error in queuecommand_lck: us->srb = ffff8804283d0d80
Then the task that called the IO hangs, and afterwards the entire
system, at the latest when I try to shutdown/restart.
It also often happens that if I restart leaving the stick plugged in, it
either won't show after boot or immediately triggers some other file
system related bug, as seen in the attachment.
[I've tried ext4, f2fs and btrfs — the first always seems able to
recover at some point, the second sometimes (at least if one manages to
avoid any corrupted files henceforth), the third never.]
The first dmesg attachment shows the bug with "module xhci_hcd =p" set.
The other shows the dmesg after the first restart with the stick plugged
in after the boot had finished. fsck.f2fs was able to repair the
partition, and no follow-up bug triggered.
--
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
