| Message ID | 8248a5f80a8aa7cd391fa36a907d342fad38563b.1598887346.git.khalid@gonehiking.org |
|---|---|
| State | New |
| Headers | show |
| Series | USB EHCI: repeated resets on full and low speed devices | expand |
On 9/4/20 9:19 AM, Greg KH wrote: > On Mon, Aug 31, 2020 at 10:08:43AM -0600, Khalid Aziz wrote: >> With the USB 3.0/3.1 controller on MSI B450-A Pro Max motherboard, >> full speed and low speed devices see constant resets making >> keyboards and mouse unreliable and unusable. These resets are caused >> by detection of stall in qtd_copy_status() and returning EPROTO >> which in turn results in TT buffers in hub being cleared. Hubs do >> not seem to repsond well to this and seem to hang which causes >> further USB transactions to time out. A reset finally clears the >> issue until we repeat the cycle all over again. >> >> Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com> >> Cc: Khalid Aziz <khalid@gonehiking.org> >> --- >> drivers/usb/host/ehci-q.c | 4 ---- >> 1 file changed, 4 deletions(-) >> >> diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c >> index 8a5c9b3ebe1e..7d4b2bc4633c 100644 >> --- a/drivers/usb/host/ehci-q.c >> +++ b/drivers/usb/host/ehci-q.c >> @@ -214,10 +214,6 @@ static int qtd_copy_status ( >> * When MMF is active and PID Code is IN, queue is halted. >> * EHCI Specification, Table 4-13. >> */ >> - } else if ((token & QTD_STS_MMF) && >> - (QTD_PID(token) == PID_CODE_IN)) { >> - status = -EPROTO; >> - /* CERR nonzero + halt --> stall */ >> } else if (QTD_CERR(token)) { >> status = -EPIPE; >> > > Removing this check is not a good idea, any chance you can come up with > some other test instead for this broken hardware? > > What about getting a USB hub that works? :) > I agree removing that check is not the right way to fix this problem. It just so happens, the USB resets disappear when that check is removed. It is more likely that check needs to be refined further to differentiate between a hub that was unplugged (reason for the original commit) and a hub that is seeing split transaction errors on full/low speed devices. I am not sure if hardware is broken. I currently am using one of the four hubs I have in a working configuration. The hub I was using before motherboard replacement on my desktop stopped working with new motherboard. Suspecting hardware defect on the motherboard, I bought a PCI plug in USB 2.0 card but that showed the same failure. So I got two more USB hubs just in case my existing hubs were broken. In all I tried seven combinations of hardware and five of them failed the same way. Every one of these hubs, keyboards, mouse and tablet works with no problems on my laptop. All high speed and super speed devices (various storage devices I have) work flawlessly on my desktop plugged into any port or any hub. My desktop is a Ryzen 5 3600X in an MSI B450-A pro max motherboard. Previous motherboard on my desktop was an ASRock Z77 Extreme motherboard with Intel core i7-3770. My laptop is an Intel i5-7300U in a Lenovo thinkpad. Somehow hubs are getting set up differently for split transactions full/low speed devices between two machines. Since I have a working configuration of hardware, my next steps are to use my desktop with working configuration of hardware and then go deeper into USB debugging to find out what is wrong with non-working configurations. Thanks, Khalid
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c index 8a5c9b3ebe1e..7d4b2bc4633c 100644 --- a/drivers/usb/host/ehci-q.c +++ b/drivers/usb/host/ehci-q.c @@ -214,10 +214,6 @@ static int qtd_copy_status ( * When MMF is active and PID Code is IN, queue is halted. * EHCI Specification, Table 4-13. */ - } else if ((token & QTD_STS_MMF) && - (QTD_PID(token) == PID_CODE_IN)) { - status = -EPROTO; - /* CERR nonzero + halt --> stall */ } else if (QTD_CERR(token)) { status = -EPIPE;
With the USB 3.0/3.1 controller on MSI B450-A Pro Max motherboard, full speed and low speed devices see constant resets making keyboards and mouse unreliable and unusable. These resets are caused by detection of stall in qtd_copy_status() and returning EPROTO which in turn results in TT buffers in hub being cleared. Hubs do not seem to repsond well to this and seem to hang which causes further USB transactions to time out. A reset finally clears the issue until we repeat the cycle all over again. Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com> Cc: Khalid Aziz <khalid@gonehiking.org> --- drivers/usb/host/ehci-q.c | 4 ---- 1 file changed, 4 deletions(-)