From: Khalid Aziz <khalid.aziz@oracle.com>
To: Alan Stern <stern@rowland.harvard.edu>
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 11:00:16 -0600 [thread overview]
Message-ID: <4d1ab90a-ec55-85e8-d646-cfa58f08d449@oracle.com> (raw)
In-Reply-To: <20200901163602.GG587030@rowland.harvard.edu>
On 9/1/20 10:36 AM, Alan Stern wrote:
> On Tue, Sep 01, 2020 at 09:15:46AM -0700, Khalid Aziz wrote:
>> On 8/31/20 8:31 PM, Alan Stern wrote:
>>> Can you collect a usbmon trace showing an example of this problem?
>>>
>>
>> I have attached usbmon traces for when USB hub with keyboards and mouse
>> is plugged into USB 2.0 port and when it is plugged into the NEC USB 3.0
>> port.
>
> The usbmon traces show lots of errors, but no Clear-TT events. The
> large number of errors suggests that you've got a hardware problem;
> either a bad hub or bad USB connections.
That is what I thought initially which is why I got additional hubs and
a USB 2.0 PCI card to test. I am seeing errors across 3 USB controllers,
4 USB hubs and 4 slow/full speed devices. All of the hubs and slow/full
devices work with zero errors on my laptop. My keyboard/mouse devices
and 2 of my USB hubs predate motherboard update and they all worked
flawlessly before the motherboard upgrade. Some combinations of these
also works with no errors on my desktop with new motherboard that I had
listed in my original email:
2. USB 2.0 controller - WORKS
5. USB 3.0/3.1 controller -> Bus powered USB 2.0 hub - WORKS
I am not seeing a common failure here that would point to any specific
hardware being bad. Besides, that one code change (which I still can't
say is the right code change) in ehci-q.c makes USB 2.0 controller work
reliably with all my devices.
--
Khalid
next prev parent reply other threads:[~2020-09-01 17:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-31 16:08 [RFC " 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
[not found] ` <608418fa-b0ce-c2a4-ad79-fe505c842587@oracle.com>
2020-09-01 16:36 ` Alan Stern
2020-09-01 17:00 ` Khalid Aziz [this message]
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=4d1ab90a-ec55-85e8-d646-cfa58f08d449@oracle.com \
--to=khalid.aziz@oracle.com \
--cc=erkka.talvitie@vincit.fi \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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
all inboxes | Powered by JetHome®