linux-kernel - Re: [PATCH 2/3] xhci: Fix control transfer error on Etron xHCI host

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHN5xi3UEJJ2aPuF3y0PHoqzb6xhmD+UG3YZyh2Ut_hk0H58gg@mail.gmail.com>
Date: Fri, 13 Sep 2024 13:25:06 +0800
From: Kuangyi Chiang <ki.chiang65@...il.com>
To: Mathias Nyman <mathias.nyman@...ux.intel.com>
Cc: gregkh@...uxfoundation.org, mathias.nyman@...el.com, 
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org, 
	stable@...r.kernel.org
Subject: Re: [PATCH 2/3] xhci: Fix control transfer error on Etron xHCI host

Hi,

Thank you for the review.

Mathias Nyman <mathias.nyman@...ux.intel.com> 於 2024年9月11日 週三 下午11:05寫道：
>
> On 11.9.2024 8.17, Kuangyi Chiang wrote:
> > Performing a stability stress test on a USB3.0 2.5G ethernet adapter
> > results in errors like this:
> >
> > [   91.441469] r8152 2-3:1.0 eth3: get_registers -71
> > [   91.458659] r8152 2-3:1.0 eth3: get_registers -71
> > [   91.475911] r8152 2-3:1.0 eth3: get_registers -71
> > [   91.493203] r8152 2-3:1.0 eth3: get_registers -71
> > [   91.510421] r8152 2-3:1.0 eth3: get_registers -71
> >
> > The r8152 driver will periodically issue lots of control-IN requests
> > to access the status of ethernet adapter hardware registers during
> > the test.
> >
> > This happens when the xHCI driver enqueue a control TD (which cross
> > over the Link TRB between two ring segments, as shown) in the endpoint
> > zero's transfer ring. Seems the Etron xHCI host can not perform this
> > TD correctly, causing the USB transfer error occurred, maybe the upper
> > driver retry that control-IN request can solve problem, but not all
> > drivers do this.
> >
> > |     |
> > -------
> > | TRB | Setup Stage
> > -------
> > | TRB | Link
> > -------
> > -------
> > | TRB | Data Stage
> > -------
> > | TRB | Status Stage
> > -------
> > |     |
> >
>
> What if the link TRB is between Data and Status stage, does that
> case work normally?

I am not sure, I don't encounter this case, maybe OK.

>
> > To work around this, the xHCI driver should enqueue a No Op TRB if
> > next available TRB is the Link TRB in the ring segment, this can
> > prevent the Setup and Data Stage TRB to be breaked by the Link TRB.
>
> There are some hosts that need the 'Chain' bit set in the Link TRB,
> does that work in this case?

No, it doesn't work. It seems to be a hardware issue.

>
> Thanks
> Mathias
>

Thanks,
Kuangyi Chiang