Created attachment 142791 [details]
output from lsusb -v
Beginning with kernel 3.15.1, on my server with an Etron xhci controller, I am getting hard lockups every time I connect a drive to my USB 3 HDD dock with ASMedia ASM1051E UASP compliant chipset. The only way I am able work around this is to set the quirk to ignore uas for the device. I have found that the same dock works flawlessly with uas on another machine with an Intel xhci controller.
Created attachment 142801 [details]
output from lspci -nn
On Sat, Jul 12, 2014 at 01:45:53PM +0000, email@example.com wrote:
> Bug ID: 80101
> Summary: kernel panic on USB 3.0 drive connection with Etron
> xhci controller
Please send to the firstname.lastname@example.org mailing list.
For the record: I asked Jonathan to file this bug for tracking after he had contact with me about this by email.
This appears to be a problem specific to Etron xhci controllers. I've ordered a pci-e addon card with an Etron xhci controller to debug this further, which I should get in aprox. 3 weeks.
In the mean time I plan to write a patch to disable streams (and thus uas) on Etron controllers (for now).
For completeness sake, here is the relevant part of dmesg when things go wrong:
[ 229.882190] usb 2-1: new SuperSpeed USB device number 3 using xhci_hcd
[ 229.908001] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 229.908218] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: 400000
[ 229.908349] scsi7 : usb-storage 2-1:1.0
[ 230.912633] scsi 7:0:0:0: Direct-Access ASMT 2105 0 PQ: 0 ANSI: 6
[ 230.914818] sd 7:0:0:0: [sdc] Attached SCSI removable disk
[ 289.680267] usb 2-1: USB disconnect, device number 3
[ 319.599862] usb 2-1: new SuperSpeed USB device number 4 using xhci_hcd
[ 319.626881] scsi8 : uas
[ 319.628221] xhci_hcd 0000:02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
[ 320.029323] BUG: unable to handle kernel paging request at 0000000001000003
Before we out-right disable streams Etron controllers, lets first see if maybe this is easy to fix properly.
Can you please build a kernel with the 2 debug patches I'm about to attach ?
Then boot that kernel and do dmesg | grep xhci, there should be a line like this in there:
xhci_hcd 0000:00:14.0: hcc params 0x20007181 hci version 0x100 quirks 0x0000bd30
Also please collect the output of the crash when you attach the uas device again, there should be some more info in there now.
If the hci version is 0x96 or less, can you then please also boot with:
Added to the kernel commandline and see if that makes a difference ?
Created attachment 142951 [details]
Created attachment 142961 [details]
debug patch 2
Created attachment 143341 [details]
output from crash (debug kernel)
Created attachment 143351 [details]
output from dmesg (debug kernel)
Created attachment 143371 [details]
Thanks for the logs. Can you try a kernel with this patch ? (applies on top of the 2 debug patches).
This _may_ fix this, no promises though :)
The kernel refers to the pci-id for the etron xhci controller as PCI_DEVICE_ID_ASROCK_P67 but I believe this is a generic Etron controller pci-id. Is the controller we're dealing with here onboard an asrock P67 motherboard ?
Yes, the controller is onboard an Asrock Z68 Pro3-M. BTW, no luck with the patch :(
My own Etron pci-e addon card has arrived last week, and I've spend 3 full days debugging its buggy bulk streams implementation. But in the end its bulk streams support is simply too buggy.
So I've written a patch blacklisting streams on this controller. This should make things automatically fall-back to usb-storage on this controller. I'll attach the patch here.
Can you please build a kernel with this patch, and test without the usb_storage quirk on the kernel command-line, and let me know if things still work (using usb-storage automatically) that way?
Created attachment 144441 [details]
Note for technical details of the streams issue on this model Etron controller, see the commit message inside the patch.
Too bad about the buggy controller. Anyhow, everything seems to be working fine with the patch.
> Can you please build a kernel with this patch, and test without the
> usb_storage quirk on the kernel command-line, and let me know if things
> still work (using usb-storage automatically) that way?
The patch for disabling streams has been merged upstream, can someone with the necessary rights please close this bug (I cannot) ?
Done.. you can drop me an email if you need any others closing Hans