LKML Archive on
help / color / mirror / Atom feed
From: Mathias Nyman <>
To: Alan Stern <>,
	"Lu, Baolu" <>
Cc: "Jörg Otte" <>,
	"Linux Kernel Mailing List" <>,
	"Greg Kroah-Hartman" <>,
	"USB list" <>,
	"Linus Torvalds" <>,
	"Mauro Carvalho Chehab" <>
Subject: Re: [V4.0.0-rc3] Xhci Regression: ERROR Transfer event TRB DMA ptr not part of current TD
Date: Wed, 11 Mar 2015 17:48:04 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 11.03.2015 16:03, Alan Stern wrote:
> On Wed, 11 Mar 2015, Lu, Baolu wrote:
>>>> It's possible that there's something in usb core as well,
>>>> but I think the following was what happened:
>>>> 1. First a normal configure endpoint command is issued, it sets endpoint dequeue pointer
>>>>     to xxx400 = start of ring segment
>>>> 2. two urbs get queued -> two TDs put on endpoint ring.
>>>> 3. xhci executes those, ring is in running (idle) state. sw dequeue at xxx430, No TDs queued.
>>>>     Endpoint dequeue pointer is not written to the endpoint output context as the ring is still
>>>>     in running state (even if idle, not advancing with no TDs queued) it still shows xxx400
>>>> 4. -> something happends, xhci_endpoint_reset() is called, we do a new configure endpoint
>>>>     to 'soft reset' the endpiont, but we copy the dequeue pointer from the old endpoint
>>>>     output context to the configure endpoint input context, which re-initializes the old
>>>>     dequeue xxx400 pointer to xhci hardware, and it starts executing the old TDs from the ring.
>> Is it possible to return an error message up to client driver? The 
>> client driver then decides
>> how to handle this kind of error. It, possibly, unlink all ongoing 
>> transfers and ask host driver
>> to soft reset this endpoint. When xhci_endpoint_reset is called, there 
>> should be no ongoing
>> transfers.
> That doesn't seem to be the problem here.  Mathias is saying that all
> the transfers have indeed completed, but when reconfiguring the
> endpoint, the driver tells the controller that some transfers are still
> active (because it stores a stale copy of the dequeue pointer).
> But Mathias, what about the cycle bits in the TRBs?  Wouldn't they be
> set to indicate that the OS now owns the TRBs?  This would cause the
> endpoint to stop working, not cause the sort of error that Jörg saw.  
> Or does the reconfigure command also store a stale copy of the Dequeue
> Cycle State setting?

xhci keeps track of a producer cycle state and consumer cycle state.

These are only updated when the producer or consumer  (enqueue ptr=producer, dequeue ptr=consumer in this case)
pass the last link TRB of the last segment. The cycle bit in a TRB is only written once,
together when the producer writes the trb to the ring.

The TRB cycle bit at the dequeue pointer is compared to the consumer cycle state.  

So the cycle bit check would only mismatch if the actual sw dequeue pointer just passed the last TRB
of the last segment, and the stale dequeue pointer in the output context would roll it back past that
TRB again.


  reply	other threads:[~2015-03-11 15:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-10  9:40 Jörg Otte
2015-03-10 13:06 ` Mathias Nyman
2015-03-10 14:03   ` Jörg Otte
2015-03-10 15:36     ` Jörg Otte
2015-03-10 17:04       ` Mathias Nyman
2015-03-10 17:29         ` Alan Stern
2015-03-10 18:21           ` Mathias Nyman
2015-03-10 18:49             ` Alan Stern
2015-03-11  7:04               ` Lu, Baolu
2015-03-11 14:03                 ` Alan Stern
2015-03-11 15:48                   ` Mathias Nyman [this message]
2015-03-11  9:00               ` Mathias Nyman
2015-03-11 11:01         ` Jörg Otte
2015-03-11 16:16           ` Jörg Otte
2015-03-12  8:32             ` Mathias Nyman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [V4.0.0-rc3] Xhci Regression: ERROR Transfer event TRB DMA ptr not part of current TD' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).