linux-kernel - Re: [PATCH v2] usb: xhci: quirk for data loss in ISOC transfers

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2a02f0c3-f535-4ac0-d29f-a33e0c45cf4c@amd.com>
Date: Tue, 12 Nov 2024 19:02:40 +0530
From: "Rangoju, Raju" <raju.rangoju@....com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: linux-usb@...r.kernel.org, mathias.nyman@...el.com,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] usb: xhci: quirk for data loss in ISOC transfers



On 11/12/2024 5:54 PM, Greg KH wrote:
> On Tue, Nov 12, 2024 at 05:51:04PM +0530, Raju Rangoju wrote:
>> During the High-Speed Isochronous Audio transfers, xHCI
>> controller on certain AMD platforms experiences momentary data
>> loss. This results in Missed Service Errors (MSE) being
>> generated by the xHCI.
>>
>> The root cause of the MSE is attributed to the ISOC OUT endpoint
>> being omitted from scheduling. This can happen either when an IN
>> endpoint with a 64ms service interval is pre-scheduled prior to
>> the ISOC OUT endpoint or when the interval of the ISOC OUT
>> endpoint is shorter than that of the IN endpoint. Consequently,
>> the OUT service is neglected when an IN endpoint with a service
>> interval exceeding 32ms is scheduled concurrently (every 64ms in
>> this scenario).
>>
>> This issue is particularly seen on certain older AMD platforms.
>> To mitigate this problem, it is recommended to adjust the service
>> interval of the IN endpoint to not exceed 32ms (interval 8). This
>> adjustment ensures that the OUT endpoint will not be bypassed,
>> even if a smaller interval value is utilized.
>>
>> Signed-off-by: Raju Rangoju <Raju.Rangoju@....com>
> 
> You don't want this backported to any older kernels?  Why not?

Hi Greg, Yes, backporting is needed, but some of products were released 
back in 2018, not sure of the exact commit id to quote here for 
backporting as there were no precise commits that added this initial 
support in the first place.

Would you mind tagging it to all stable kernels. Let me know if the 
patch needs to be respinned.

> 
> thanks,
> 
> greg k-h