On 29.08.2015 17:06, Steinar H. Gunderson wrote:
On Sat, Aug 29, 2015 at 12:17:25AM +0200, Steinar H. Gunderson wrote:
I've noticed (with the CONFIG_PM=y kernel) that sometimes this comes up when
inserting the device:

[  136.370917] usb 3-2: Set SEL for device-initiated U2 failed.

I don't know if it's relevant.

I've also noticed these started coming now, although I'm not sure if they
are related; I see DMAR is mentioned, so it might be related to the fact
that I gave the device to KVM (via VT-d) a bit earlier in the same boot
(although qemu was long shut down by this point):

[ 8240.586544] DMAR: DRHD: handling fault status reg 3
[ 8240.586560] DMAR: DMAR:[DMA Write] Request device [00:14.0] fault addr 
ffef0000
                DMAR:[fault reason 05] PTE Write access is not set
[ 8240.586665] DMAR: DRHD: handling fault status reg 3
[ 8240.586678] DMAR: DMAR:[DMA Write] Request device [00:14.0] fault addr 
ffee8000
                DMAR:[fault reason 05] PTE Write access is not set
[ 8240.586792] DMAR: DRHD: handling fault status reg 3
[ 8240.586803] DMAR: DMAR:[DMA Write] Request device [00:14.0] fault addr 
ffee0000
                DMAR:[fault reason 05] PTE Write access is not set
[ 8240.586813] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 6 comp_code 13
[ 8240.586824] xhci_hcd 0000:00:14.0: Looking for event-dma 00000000fff5cf40 
trb-start 00000000ffa86520 trb-end 00000000ffa86520 seg-start 00000000ffa86000 
seg-end 00000000ffa86ff0
[ 8240.586839] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 6 comp_code 13
[ 8240.586847] xhci_hcd 0000:00:14.0: Looking for event-dma 00000000fff5cf50 
trb-start 00000000ffa86520 trb-end 00000000ffa86520 seg-start 00000000ffa86000 
seg-end 00000000ffa86ff0

/* Steinar */


The original error, the
[  221.350440] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 20, HC 
probably busted.
A "no ping response error" is according to the specs seen when device fails to 
respond to a
ping within max exit latency limit.

The max exit latency should tell how long it can maximum take for the entire 
link between host
and device to wake up and be fully functional. Isoc transfer will send a PING 
TP max exit
latency before the first data transfer to make sure link is up and running in 
time.
This is only for SuperSpeed Isoc transfers

So either we have miscalculated to Max exit transfer, and link really isn't yet 
ready,
or then there could be some other powermanagement issue with getting the link 
up and running.


I think setting the max exit lantecy to 0 will prevent sending the PING TP to 
wake the link,
(and maybe even prevent the link from going to any kind of power saving state)

Other option is to just increase the max exit latency value and see if it helps.

I think the SuperSpeed Isoc transfers and exit latency code Isn't very common 
and code might
need some looking after.

Turning the max exit latency to zero could be done with something like this:

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 526ebc0..e78b7cd 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4667,7 +4667,7 @@ int xhci_enable_usb3_lpm_timeout(struct usb_hcd *hcd,
                mel = 0;
        }
- ret = xhci_change_max_exit_latency(xhci, udev, mel);
+       ret = xhci_change_max_exit_latency(xhci, udev, 0);
        if (ret)
                return ret;
        return hub_encoded_timeout;
@@ -4686,7 +4686,7 @@ int xhci_disable_usb3_lpm_timeout(struct usb_hcd *hcd,
                return 0;
mel = calculate_max_exit_latency(udev, state, USB3_LPM_DISABLED);
-       ret = xhci_change_max_exit_latency(xhci, udev, mel);
+       ret = xhci_change_max_exit_latency(xhci, udev, 0);
        if (ret)
                return ret;
        return 0;


The "ERROR Transfer event TRB DMA ptr not part of curren..." errors are a bit 
worrying.
I was hoping these would no longer occur after the last off by one fix:

commit 7895086afde2a05fa24a0e410d8e6b75ca7c8fdd
    xhci: fix off by one error in TRB DMA address boundary check

-Mathias

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to