On 16/10/17 12:54, Hao Wei Tee wrote: > On 12/10/2017 21:36, Mathias Nyman wrote: >> You could try booting with xhci_hcd.dyndbg=+p added to the kernel command line. > > I can't find anything relevant... Hmm. Is your VL805 on the motherboard or an add-on card? One other possibly important difference that comes to mind is that on my arm64 system Linux is the only agent to ever touch the xHCI - UEFI doesn't even try to probe it. It seems likely that a full-featured PC firmware might have been more hands-on, especially if the controller is on-board. > Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=... rw intel_iommu=on xhci_hcd.dyndbg=+p > ACPI: DMAR 0x00000000DE2C20E0 000078 (v01 INTEL SNB 00000001 INTL 00000001) > DMAR: IOMMU enabled > DMAR: Host address width 36 > DMAR: DRHD base: 0x000000fed90000 flags: 0x1 > DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c9008020660262 ecap f0105a > DMAR: RMRR base: 0x000000dec75000 end: 0x000000dec83fff > DMAR-IR: IOAPIC id 2 under DRHD base 0xfed90000 IOMMU 0 > DMAR-IR: HPET id 0 under DRHD base 0xfed90000 > DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. > DMAR-IR: Enabled IRQ remapping in x2apic mode > DMAR: No ATSR found > DMAR: dmar0: Using Queued invalidation > DMAR: Setting RMRR: > DMAR: Setting identity map for device 0000:00:1a.0 [0xdec75000 - 0xdec83fff] > DMAR: Setting identity map for device 0000:00:1d.0 [0xdec75000 - 0xdec83fff] It seems noteworthy that these RMRRs are within about 10MB of the faulting address... > DMAR: Prepare 0-16MiB unity mapping for LPC > DMAR: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff] > DMAR: Intel(R) Virtualization Technology for Directed I/O > ... > iommu: Adding device 0000:03:00.0 to group 11 > ... > xhci_hcd 0000:03:00.0: xHCI Host Controller > xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 2 > xhci_hcd 0000:03:00.0: xHCI capability registers at ffffc3ed00c99000: > xhci_hcd 0000:03:00.0: CAPLENGTH AND HCIVERSION 0x1000020: > xhci_hcd 0000:03:00.0: CAPLENGTH: 0x20 > xhci_hcd 0000:03:00.0: HCIVERSION: 0x100 > xhci_hcd 0000:03:00.0: HCSPARAMS 1: 0x5000420 > xhci_hcd 0000:03:00.0: Max device slots: 32 > xhci_hcd 0000:03:00.0: Max interrupters: 4 > xhci_hcd 0000:03:00.0: Max ports: 5 > xhci_hcd 0000:03:00.0: HCSPARAMS 2: 0xfc000031 > xhci_hcd 0000:03:00.0: Isoc scheduling threshold: 1 > xhci_hcd 0000:03:00.0: Maximum allowed segments in event ring: 3 > xhci_hcd 0000:03:00.0: HCSPARAMS 3 0xe70004: > xhci_hcd 0000:03:00.0: Worst case U1 device exit latency: 4 > xhci_hcd 0000:03:00.0: Worst case U2 device exit latency: 231 > xhci_hcd 0000:03:00.0: HCC PARAMS 0x2841eb: > xhci_hcd 0000:03:00.0: HC generates 64 bit addresses > xhci_hcd 0000:03:00.0: HC hasn't Contiguous Frame ID Capability > xhci_hcd 0000:03:00.0: HC can't generate Stopped - Short Package event > xhci_hcd 0000:03:00.0: FIXME: more HCCPARAMS debugging > xhci_hcd 0000:03:00.0: RTSOFF 0x200: > xhci_hcd 0000:03:00.0: xHCI operational registers at ffffc3ed00c99020: > xhci_hcd 0000:03:00.0: USBCMD 0x0: > xhci_hcd 0000:03:00.0: HC is being stopped > xhci_hcd 0000:03:00.0: HC has finished hard reset > xhci_hcd 0000:03:00.0: Event Interrupts disabled > xhci_hcd 0000:03:00.0: Host System Error Interrupts disabled > xhci_hcd 0000:03:00.0: HC has finished light reset > xhci_hcd 0000:03:00.0: USBSTS 0x1: > xhci_hcd 0000:03:00.0: Event ring is empty > xhci_hcd 0000:03:00.0: No Host System Error > xhci_hcd 0000:03:00.0: HC is halted > xhci_hcd 0000:03:00.0: ffffc3ed00c99420 port status reg = 0x40000ee1 > xhci_hcd 0000:03:00.0: ffffc3ed00c99424 port power reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99428 port link reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c9942c port reserved reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99430 port status reg = 0x2a0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99434 port power reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99438 port link reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c9943c port reserved reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99440 port status reg = 0x2a0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99444 port power reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99448 port link reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c9944c port reserved reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99450 port status reg = 0x2a0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99454 port power reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99458 port link reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c9945c port reserved reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99460 port status reg = 0x2a0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99464 port power reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c99468 port link reg = 0x0 > xhci_hcd 0000:03:00.0: ffffc3ed00c9946c port reserved reg = 0x0 > xhci_hcd 0000:03:00.0: QUIRK: Resetting on resume > xhci_hcd 0000:03:00.0: // Halt the HC > xhci_hcd 0000:03:00.0: Resetting HCD > xhci_hcd 0000:03:00.0: // Reset the HC > 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 ...and that correspondingly for this to be a Linux-allocated IOVA would mean over 540MB having been mapped for DMA already, which seems somewhat less likely than it being some leftover physical address from firmware. Can you try instrumenting xhci_segment_alloc() to get an idea of what the actual DMA addresses of the various queues are at this point? Robin. > ... > 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 > -- 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
