Comments below.
On Mon, Mar 03, 2014 at 10:55:13PM +0100, Merlin Chlosta wrote:
> Hello everyone,
>
> I'd like to encrypt my external HDD using dm-crypt (luks) via USB 3.0.
> The crypto-container creation works, but writing to it doesn't:
>
> > kernel: usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd
> > kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800c37e5c80kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800c37e5cc0kernel: usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd
> > kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800c37e5c80kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800c37e5cc0kernel: usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd
> > kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800c37e5c80kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800c37e5cc0kernel: usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd
> > kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800c37e5c80kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800c37e5cc0kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for address device command
> > kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for address device command
> > kernel: usb 4-2: device not accepting address 2, error -62
> > kernel: usb 4-2: USB disconnect, device number 2
> > kernel: scsi 12:0:0:0: rejecting I/O to offline device
> > kernel: scsi 12:0:0:0: [sdc] killing request
> > kernel: scsi 12:0:0:0: [sdc] Unhandled error code
> > kernel: scsi 12:0:0:0: [sdc]
> > kernel: Result: hostbyte=0x01 driverbyte=0x00
> > kernel: scsi 12:0:0:0: [sdc] CDB:
> > kernel: cdb[0]=0x2a: 2a 00 00 00 10 41 00 00 12 00
> > kernel: end_request: I/O error, dev sdc, sector 4161
> > kernel: quiet_error: 1601 callbacks suppressed
> > kernel: Buffer I/O error on device dm-5, logical block 2
> > kernel: lost page write due to I/O error on dm-5
> > kernel: Buffer I/O error on device dm-5, logical block 3
> > kernel: lost page write due to I/O error on dm-5
> > kernel: Buffer I/O error on device dm-5, logical block 4
> > kernel: lost page write due to I/O error on dm-5
> > kernel: Buffer I/O error on device dm-5, logical block 5
> > kernel: lost page write due to I/O error on dm-5
> > kernel: Buffer I/O error on device dm-5, logical block 6
> > kernel: lost page write due to I/O error on dm-5
> > kernel: Buffer I/O error on device dm-5, logical block 7
> > kernel: lost page write due to I/O error on dm-5
> > kernel: Buffer I/O error on device dm-5, logical block 8
> > kernel: lost page write due to I/O error on dm-5
> > kernel: Buffer I/O error on device dm-5, logical block 9
> > kernel: lost page write due to I/O error on dm-5
> > kernel: Buffer I/O error on device dm-5, logical block 10
> > kernel: lost page write due to I/O error on dm-5
> > kernel: Buffer I/O error on device dm-5, logical block 11
> > kernel: lost page write due to I/O error on dm-5
> > kernel: scsi 12:0:0:0: rejecting I/O to offline device
> > kernel: scsi 12:0:0:0: [sdc] killing request
> > kernel: scsi 12:0:0:0: [sdc] Unhandled error code
> > kernel: scsi 12:0:0:0: [sdc]
> > kernel: Result: hostbyte=0x01 driverbyte=0x00
> > kernel: scsi 12:0:0:0: [sdc] CDB:
> > kernel: cdb[0]=0x2a: 2a 00 00 00 10 53 00 00 18 00
> > kernel: end_request: I/O error, dev sdc, sector 4179
> > kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800c37e5c80
> > kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8800c37e5cc0
>
> USB 2.0 (ehci-pci) works fine (direct, filesystem, crypto). With USB
> 3.0, both direct access using 'dd' and filesystem access is possible.
> Only direct access to the cryptdevice fails (including 'mkfs.ext4').
>
> If I create a filesystem on the crypto device via USB 2.0, I can access
> it via USB 3.0 as well.
>
> % uname -r
> 3.13.5-1
> (also tested on 3.14rc4)
In a separate mail, you said 3.10.30-1-lts also works. We do have one
known regression for USB mass storage. If you compile your own kernel,
please retest with 3.14-rc4 with these two commits reverted:
3804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a: enable tso if usb host supports sg dma"
247bf557273dd775505fb9240d2d152f4f20d304 "xhci 1.0: Limit arbitrarily-aligned scatter gather."
Please let me know if reverting those two commits worked. If not, we'll
dig deeper into exactly why your mass storage device is failing.
Sarah Sharp
> % lspci -nn | grep USB
> 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
> Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
> 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
> Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
> 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
> Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
>
> % sudo lsusb -v -d 4971:1014
> Bus 004 Device 003: ID 4971:1014 SimpleTech
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 3.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 9
> idVendor 0x4971 SimpleTech
> idProduct 0x1014
> bcdDevice 0.00
> iManufacturer 10 HGST
> iProduct 11 Touro Mobile 3.0
> iSerial 3 21001311250002300511
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 44
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xc0
> Self Powered
> MaxPower 2mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 8 Mass Storage
> bInterfaceSubClass 6 SCSI
> bInterfaceProtocol 80 Bulk-Only
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0400 1x 1024 bytes
> bInterval 0
> bMaxBurst 15
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0400 1x 1024 bytes
> bInterval 0
> bMaxBurst 15
> Binary Object Store Descriptor:
> bLength 5
> bDescriptorType 15
> wTotalLength 42
> bNumDeviceCaps 3
> USB 2.0 Extension Device Capability:
> bLength 7
> bDescriptorType 16
> bDevCapabilityType 2
> bmAttributes 0x00000002
> Link Power Management (LPM) Supported
> SuperSpeed USB Device Capability:
> bLength 10
> bDescriptorType 16
> bDevCapabilityType 3
> bmAttributes 0x00
> wSpeedsSupported 0x000e
> Device can operate at Full Speed (12Mbps)
> Device can operate at High Speed (480Mbps)
> Device can operate at SuperSpeed (5Gbps)
> bFunctionalitySupport 1
> Lowest fully-functional device speed is Full Speed (12Mbps)
> bU1DevExitLat 10 micro seconds
> bU2DevExitLat 32 micro seconds
> Container ID Device Capability:
> bLength 20
> bDescriptorType 16
> bDevCapabilityType 4
> bReserved 0
> ContainerID {00010203-0405-0607-0800-000000000000}
> Device Status: 0x0001
> Self Powered
>
> See [1] for a journalctl-log with xhci-debugging enabled. I also made an
> usbmon-trace [2].
>
> Regards,
> Merlin Chlosta
>
> [1] journalctl: http://sprunge.us/TRid
> [2] usbmon: http://sprunge.us/cTUe
> --
> 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
--
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
