On Wed, Jan 29, 2014 at 12:50:04PM +0200, Xenia Ragiadakou wrote: > On 29/01/2014 12:08 μμ, Rafał Miłecki wrote: > >I've enabled some debugging in xhci-dbg.c, does it help? > >xhci_hcd 0000:04:00.0: xHCI capability registers at ffffc90004e60000: > >xhci_hcd 0000:04:00.0: CAPLENGTH AND HCIVERSION 0x960020: > >xhci_hcd 0000:04:00.0: CAPLENGTH: 0x20 > >xhci_hcd 0000:04:00.0: HCIVERSION: 0x96 > >xhci_hcd 0000:04:00.0: HCSPARAMS 1: 0x4000820 > >xhci_hcd 0000:04:00.0: Max device slots: 32 > >xhci_hcd 0000:04:00.0: Max interrupters: 8 > >xhci_hcd 0000:04:00.0: Max ports: 4 > >xhci_hcd 0000:04:00.0: HCSPARAMS 2: 0x17f1 > >xhci_hcd 0000:04:00.0: Isoc scheduling threshold: 1 > >xhci_hcd 0000:04:00.0: Maximum allowed segments in event ring: 15 > >xhci_hcd 0000:04:00.0: HCSPARAMS 3 0x0: > >xhci_hcd 0000:04:00.0: Worst case U1 device exit latency: 0 > >xhci_hcd 0000:04:00.0: Worst case U2 device exit latency: 0 > >xhci_hcd 0000:04:00.0: HCC PARAMS 0x200f180: > >xhci_hcd 0000:04:00.0: HC generates 32 bit addresses > >xhci_hcd 0000:04:00.0: FIXME: more HCCPARAMS debugging > >xhci_hcd 0000:04:00.0: RTSOFF 0x1000: > > > > Hi Rafał, > > Like Bjørn already pointed out, I think too the problem is that the > USB3.0 host controller does not support 64 bit addressing (this can > be seen from the first bit of HCC PARAMS that is 0) but the patch > does not take it into account and blindly tries to perform 64bit > write accesses just because your system is 64bit. My mistake. I will > try to find a solution for that and send a patch when I ll return > home. I think the solution should be to just revert the writeq patch, and leave the xhci_write64 in place. We can always optimize that function later to do a writeq if the host supports 64-bit writes, but we'll have to analyze whether the performance impact of doing so makes sense. Sarah Sharp -- 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