From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Tue, 24 Mar 2020 19:11:24 +0100 Subject: [RFT PATCH v1 1/5] Revert "usb: ehci-hcd: Keep async schedule running" In-Reply-To: <6a8e4710-a309-91cd-9b23-a54d02743691@denx.de> References: <20200322130031.10455-1-lukma@denx.de> <20200322130031.10455-2-lukma@denx.de> <7232a38a-3c6a-e397-21fc-5e2bff55f578@denx.de> <20200323075749.7c845b24@jawa> <357a2fb1-44e5-100a-63c9-1a9e6a1fd21a@denx.de> <20200323134135.3341635c@jawa> <20200324080617.7d979d09@jawa> <6a8e4710-a309-91cd-9b23-a54d02743691@denx.de> Message-ID: <20200324191124.3c78f53c@jawa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Marek, > On 3/24/20 8:06 AM, Lukasz Majewski wrote: > > Hi Marek, > > Hi, > > [...] > > >>>> You should probably figure out why this doesn't work first and > >>>> then add fixes on top. > >>> > >>> Haven't you seen such problem during code development on your > >>> setup when developing this patch? > >> > >> During the development of the patch, I don't remember, sorry. I > >> most certainly saw various failure modes, however those should not > >> be present mainline. > > > > The issue is that the qhtoken is not updated at all. > > > > Maybe you remember - is Linux using async setup by default (as > > introduced in SHA1: 02b0e1a36c5bc20174299312556ec4e266872bd6) ? > > If I recall correctly, it is using async schedule for bulk transfers. > But the code is available, so you can double-check that. > > >> I tested this patch with the problematic USB sticks on R-Car Gen3 > >> and with SMSC95xx USB ethernet adapter last weekend and I didn't > >> see a problem. > > > > Ok. > > > > For i.MX6Q: > > The SHA1: 02b0e1a36c5bc20174299312556ec4e266872bd6 patch causes the > > iMX6Q to fail after a few minutes of testing. General in i.MX6Q the > > usb is NOT robust at all. > > > > For i.MX53: > > With patch 02b0e1a36c5bc20174299312556ec4e266872bd6 applied it also > > breaks after a few minutes. > > So on CI HDRC , there is some difference in behavior. That is what you > need to find and fix then. The conclusion is that some boards/implementations are broken. > > > With this patch series applied it works for 2 days now without any > > issue. > > Except performance is totally degraded So we do have _very_ fast USB which breaks after a few minutes of constant testing (with procedure stated earlier). > and there is still no clear > explanation _why_ any of these patches are needed Haven't I explicitly explained in previous mails why XACTARR error shall be handled? Nor the original thread did it? Wasn't the cover-letter verbose enough? > and/or whether doing > write to a block device with these patches may cause data corruption. So I will ask differently - what _may_ happen when the "TD - token=XXXX" error shows up and the board hangs? Wouldn't we risk some unwanted storage corruption? Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: