linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Khalid Aziz <khalid.aziz@oracle.com>
Cc: gregkh@linuxfoundation.org, erkka.talvitie@vincit.fi,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC RESEND PATCH 0/1] USB EHCI: repeated resets on full and low speed devices
Date: Tue, 1 Sep 2020 12:18:48 -0400	[thread overview]
Message-ID: <20200901161848.GF587030@rowland.harvard.edu> (raw)
In-Reply-To: <0ec31395-56d9-c490-4e42-1c27bbc69df3@oracle.com>

On Tue, Sep 01, 2020 at 08:51:14AM -0700, Khalid Aziz wrote:
> >> At the time of failure, when we reach this conditional, token is
> >> either 0x80408d46 or 0x408d46 which means following bits are set:
> >>
> >> QTD_STS_STS, QTD_STS_MMF, QTD_STS_HALT, QTD_IOC, QTD_TOGGLE
> >>
> >> and 
> >>
> >>         QTD_PID = 1
> >>         QTD_CERR = 3
> >>         QTD_LENGTH = 0x40 (64)
> >>
> >> This causes  the branch "(token & QTD_STS_MMF) && (QTD_PID(token) ==
> >> PID_CODE_IN" to be taken and qtd_copy_status() returns EPROTO. This
> >> return value in qh_completions() results in ehci_clear_tt_buffer()
> >> being called:

I didn't mention this before, but that combination of events doesn't 
make sense.  The MMF bit is supposed to get set only for queue heads in 
the periodic list, that is, only for interrupt transactions.  But 
ehci_clear_tt_buffer() doesn't do anything for interrupt endpoints; it 
tests specifically for that right at the start.

Maybe your EHCI controller is setting the MMF bit when it shouldn't.  
The usbmon output will help clear this up.

Or maybe the hubs you are testing don't work right.  That's the only 
reason I can think of for the failures you see with the USB-3 
controller; the way it operates is very different from the way EHCI 
does.

Alan Stern

  reply	other threads:[~2020-09-01 16:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-31 16:08 [RFC PATCH 0/1] USB EHCI: repeated resets on full and low speed devices Khalid Aziz
2020-08-31 16:08 ` [RFC PATCH 1/1] usb: ehci: Remove erroneous return of EPROTO upon detection of stall Khalid Aziz
2020-08-31 16:23   ` [RFC RESEND " Khalid Aziz
2020-09-04 15:19   ` [RFC " Greg KH
2020-09-04 16:43     ` Khalid Aziz
2020-08-31 16:23 ` [RFC RESEND PATCH 0/1] USB EHCI: repeated resets on full and low speed devices Khalid Aziz
2020-09-01  2:31 ` Alan Stern
2020-09-01 15:51   ` Khalid Aziz
2020-09-01 16:18     ` Alan Stern [this message]
     [not found]   ` <608418fa-b0ce-c2a4-ad79-fe505c842587@oracle.com>
2020-09-01 16:36     ` Alan Stern
2020-09-01 17:00       ` Khalid Aziz
2020-09-01 19:51         ` Alan Stern
2020-09-01 22:54           ` Khalid Aziz
2020-09-02  1:44             ` Alan Stern

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20200901161848.GF587030@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=erkka.talvitie@vincit.fi \
    --cc=gregkh@linuxfoundation.org \
    --cc=khalid.aziz@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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).