On 09/10/17 16:49, Robin Murphy wrote:
> On 09/10/17 10:22, Mathias Nyman wrote:
>> On 08.10.2017 17:03, Hao Wei Tee wrote:
>>> Hi,
>>>
>>> I've been having DMA read faults with my VL805 xHCI controller when
>>> the Intel IOMMU
>>> is turned on:
>>>
>>> xhci_hcd 0000:03:00.0: xHCI Host Controller
>>> xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 2
>>> DMAR: DRHD: handling fault status reg 3
>>> DMAR: [DMA Read] Request device [03:00.0] fault addr de28a000
>>> [fault reason 01] Present bit in root entry is clear
>>> <snip many identical DMAR faults>
>>> xhci_hcd 0000:03:00.0: can't setup: -110
>>> xhci_hcd 0000:03:00.0: USB bus 2 deregistered
>>> xhci_hcd 0000:03:00.0: init 0000:03:00.0 fail, -110
>>> xhci_hcd: probe of 0000:03:00.0 failed with error -110
>>>
>>> The controller works fine, as far as I can tell, when the IOMMU is off.
>>>
>>> I've tracked it down to where CMD_RESET is sent to the controller in
>>> xhci_reset,
>>> [1] called from xhci_gen_setup in xhci.c. It seems that when the
>>> command register
>>> is being polled in the xhci_handshake after that, the controller tries
>>> to do a
>>> DMA read from an address that is apparently invalid (?). Eventually
>>> xhci_handshake
>>> times out.
>>>
>>> I've tried setting the XHCI_NO_64BIT_SUPPORT quirks flag as someone
>>> suggested in
>>> an earlier thread here [2] about a similar/the same(?) device, but
>>> that doesn't
>>> seem to have worked.
>>>
>>> Help, please. I have no idea how to debug this further.
>>>
>>
>> Could it maybe be related to a iommu/vt-d: Fix scatterlist offset
>> handling fix:
>> https://lists.linuxfoundation.org/pipermail/iommu/2017-September/024371.html
>>
>>
>> Can you check if that patch is included?
>>
>> The author Robin Murphy (CC) Also had some recent issues with a VIA
>> VL805 controller
>>
>> https://marc.info/?l=linux-usb&m=150730678304383&w=2
>
> I'm pretty confident this is unrelated to the intel-iommu issue that
> my patch above addresses. On my arm64 test system, the VL805 is
> consistently playing up even *without* an IOMMU - dd'ing from a USB3
> mass storage device throws up a series of block layer errors like this:
>
> [ 138.658733] sd 2:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07
> driverbyte=0x00
> [ 138.666853] sd 2:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 00 00 a8 00
> 01 80 00
> [ 138.674369] print_req_error: I/O error, dev sdb, sector 168
>
>
> Brain dump so far:
>
> - I can reliably produce these errors using dd with a block size of
> 128K or greater; more generally they seem correlated with
> dma_map_sg() calls where the scatterlist is 32 or more entries long.
>
> - without the IOMMU, block sizes >=128K all settle down into a
> suspiciously-periodic error every 2048 sectors.
>
> - with the IOMMU, the faulting write address is always the first byte
> of a page immediately following a valid XHCI DMA mapping; I'm no USB
> expert, but having now generated the debug log below, this might
> actually just be a symptom of the queue getting out of whack earlier.
>
> - FWIW, neither XHCI_NO_64BIT_SUPPORT as mentioned in the other thread,
> nor XHCI_BROKEN_STREAMS per the other VIA quirk, makes any visible
> difference.
>
> - The same device works quite happily in USB 2.0 ports on the same
> system (via on-SoC EHCI), and with a different USB 3.0 PCIe card
> based on a Renesas uPD720201.
Actually, I tell a lie there - I was getting confused with the results
from the USB3-ethernet adapter. With the Renesas card, dd'ing from the
USB3-SATA adapter *does* still generate the same periodic error every
2048 sectors with block sizes >= 128K, but it recovers an awful lot
quicker each time, and never triggers IOMMU faults. The USB 2.0 host
has no issues.
Robin.
--->8---
lsusb -v output for this cheap no-name adapter plugged into the
Renesas card, complete with 100% reproducible stall in the process:
Bus 004 Device 003: ID 13fd:3940 Initio Corporation
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x13fd Initio Corporation
idProduct 0x3940
bcdDevice 3.09
iManufacturer 1 TS1GSDOM
iProduct 2 22V
iSerial 3 32303131313230313030303041303030
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 44
bNumInterfaces 1
bConfigurationValue 1
iCo[ 1014.305508] xhci_hcd 0000:04:00.0: Stalled endpoint for slot 1 ep 0
[ 1014.314281] xhci_hcd 0000:04:00.0: Cleaning up stalled endpoint ring
[ 1014.320574] xhci_hcd 0000:04:00.0: Finding endpoint context
[ 1014.326094] xhci_hcd 0000:04:00.0: Cycle state = 0x1
[ 1014.331010] xhci_hcd 0000:04:00.0: New dequeue segment = ffff800053590600
(virtual)
[ 1014.338593] xhci_hcd 0000:04:00.0: New dequeue pointer = 0xffabf940 (DMA)
[ 1014.345314] xhci_hcd 0000:04:00.0: Queueing new dequeue state
[ 1014.351008] xhci_hcd 0000:04:00.0: Set TR Deq Ptr cmd, new deq seg =
ffff800053590600 (0xffabf000 dma), new deq ptr = ffff00000a655940 (0xffabf940
dma), new cycle = 1
[ 1014.365730] xhci_hcd 0000:04:00.0: // Ding dong!
[ 1014.370307] xhci_hcd 0000:04:00.0: Giveback URB ffff80005b0ad000, len = 0,
expected = 4, status = -32
[ 1014.379476] xhci_hcd 0000:04:00.0: Ignoring reset ep completion code of 1
[ 1014.386206] xhci_hcd 0000:04:00.0: Successful Set TR Deq Ptr cmd, deq =
@ffabf940
nfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 36mA
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 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 7
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0a EP 10 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 7
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 22
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000002
HIRD 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 128 micro seconds
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
