From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) by mx.groups.io with SMTP id smtpd.web11.163259.1669755117961353041 for ; Tue, 29 Nov 2022 12:51:58 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=b4P3q0cT; spf=pass (domain: apple.com, ip: 17.171.2.68, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 2ATKiYJF050464; Tue, 29 Nov 2022 12:51:57 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=ByyoO/gPzs9Sgo7mc/RQ2K1td+tHOsxSI3ZKCYuwKx0=; b=b4P3q0cTF/c+h7s2krsoLr20e8WmLlHEPE1I1xBmt9Lpzo9cYlKsV1iXfxp3TeypjiB6 b39rM+NAFsKeuwMQNuHebUZh6GnCP0e43RAxYkSaGWnYzZYysn+cKxD+NTn4YPr1zdFE PdaILu8SdH1L6THNdgI3ff4SDvVHpMznvse3R/QiZKYwhhmqCj9kurn2GXhv9aRpzmpS FRIFoVAn1db+F547eCrAquj6Mr3icz0VqY3F1BTL6ehZJOgbO3rljld2DOCFkUtHvD3l 6jKUpNCoydAppMXfYlznkbcOvZ6Dfvi/nnWmNpBWpHH5DQfSMQzOmqAijqVwCgGmh16H NQ== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 3m3gbx696j-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 29 Nov 2022 12:51:57 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) with ESMTPS id <0RM4005FINAKTOJ0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Tue, 29 Nov 2022 12:51:57 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) id <0RM400G00N2UM700@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 29 Nov 2022 12:51:56 -0800 (PST) X-Va-A: X-Va-T-CD: 1165e9c0719fe41fbe3697a31693ed97 X-Va-E-CD: 25f46ca760d41dd3a9adb394019714a6 X-Va-R-CD: e4a80525cd49b32666b3f576cb98a70f X-Va-CD: 0 X-Va-ID: 679caf26-af25-48b1-a5b4-96b0d50472d9 X-V-A: X-V-T-CD: 1165e9c0719fe41fbe3697a31693ed97 X-V-E-CD: 25f46ca760d41dd3a9adb394019714a6 X-V-R-CD: e4a80525cd49b32666b3f576cb98a70f X-V-CD: 0 X-V-ID: 8af80a29-565c-43b0-90e6-2d3444b61547 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.545,18.0.895 definitions=2022-11-29_11:2022-11-29,2022-11-29 signatures=0 Received: from smtpclient.apple (unknown [17.11.2.230]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) with ESMTPSA id <0RM4001ORNAJ4800@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 29 Nov 2022 12:51:56 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 16.0 \(3731.200.22\)) Subject: Re: [edk2-devel] USB: reducing/removing EHCI and XHCI logging when bulk transfer requests timeout From: "Andrew Fish" In-reply-to: <5fc5a8d3-c187-9ebf-99f0-640e6e48e52a@quicinc.com> Date: Tue, 29 Nov 2022 12:51:45 -0800 Cc: devel@edk2.groups.io Message-id: References: <4CCB8106-9E27-483D-B128-3BA11EE428BE@apple.com> <5fc5a8d3-c187-9ebf-99f0-640e6e48e52a@quicinc.com> To: Rebecca Cran X-Mailer: Apple Mail (2.3731.200.22) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.545,18.0.895 definitions=2022-11-29_11:2022-11-29,2022-11-29 signatures=0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable > On Nov 29, 2022, at 11:47 AM, Rebecca Cran = wrote: >=20 > On 11/29/22 12:43, Andrew Fish via groups.io wrote: >>> On Nov 29, 2022, at 11:12 AM, Rebecca Cran = wrote: >>>=20 >>> I've been working on the UsbNetworkPkg drivers that Richard Ho = submitted. One problem I've run into is that since we poll for bulk = requests, most of the time they will timeout - and currently both EHCI = and XHCI drivers log errors when that happens, which results in log spam = and makes interacting with the system very difficult (e.g. using UiApp). >>>=20 >>> I was wondering if we might consider adding some mechanism to omit = those messages if the user desires, perhaps on a per-build basis? >>>=20 >> Are those DEBUG prints or report status code? >=20 > They're DEBUG prints. >=20 If they happen a lot maybe they should be DEBUG_VERBOSE? Thanks, Andrew Fish > --=20 > Rebecca Cran