From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by mx.groups.io with SMTP id smtpd.web11.2338.1669763139789982787 for ; Tue, 29 Nov 2022 15:05:40 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="signature has expired" header.i=@bsdio.com header.s=fm2 header.b=mlYQOF5a; spf=pass (domain: bsdio.com, ip: 64.147.123.21, mailfrom: rebecca@bsdio.com) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id AAC3532009E2; Tue, 29 Nov 2022 18:05:38 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 29 Nov 2022 18:05:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdio.com; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1669763138; x= 1669849538; bh=5TFTZG96ilBLgR2XVBIDKy1aij2KUyXWC9dse4+qCaM=; b=m lYQOF5asEblkCncKEu77I/vIayozU2n9iUNszad5q0G5iahAy1kBFyiz1OFfw0m9 6lS67MnJbohVhmTFpGOB6gLqgzQUloMdwswQ24sCaUQ+R/QXxgM/wlmd3uJVXCNG GtgOLIpaBG07R/evLuI1nBgyCHPDzZjU8XoaUVhmvkwr3H3PCizYpqqd8CJUFsj8 8FnQXQ7IXE6cpSvwzSfNMnE36IHFS57u5odTs2QvsoTWHQOlKppwTsUfK5cKvPZg WLgbMYw1iDAeXHMGw5win1RPZqEDoSFvJJ7Q0y/bBTVgalWfcHO4rS3IOUrGaNuM EObtVdie1jn7jZ+PRlnDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1669763138; x=1669849538; bh=5 TFTZG96ilBLgR2XVBIDKy1aij2KUyXWC9dse4+qCaM=; b=QtxPa6hCLyPdTV/7j INZ+Ktd2Bs+siXrNsNH/EtIIm4ZXngGEDmuXS1hN5vezidC2NMoMsNHhsiuM57jL L5BnOMfIyt/WIyqAqoWYWcq5vt4ytCjVJWtzx0/vn0cjwsZnZUoWF4ThkPC6sluR P0bcAkZkMnLIkMFU7DShAbX+QVZwfTJYGj/c2+R/oWckK8o3B13kJPYwkTgfY1By xahnf6vUoQL0pAU1w/rnSgNQ+hk88aatCcIvJ5Nl1zd0pcNHeio+WUEv3D9pqOSW 7+6koWyLO9ThH+t12lpSnzFIPVCzx4eRIbOMcYsDDkJtyeOdCVJrwb8VKCg2l1yg D4J9A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrtddvgddtiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesthejre dttdefjeenucfhrhhomheptfgvsggvtggtrgcuvehrrghnuceorhgvsggvtggtrgessghs ughiohdrtghomheqnecuggftrfgrthhtvghrnhepleduvedtledtvedvuedugeeuudeiie dtueduvdffueekfeejffduvdetjeevffdvnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomheprhgvsggvtggtrgessghsughiohdrtghomh X-ME-Proxy: Feedback-ID: i5b994698:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 29 Nov 2022 18:05:37 -0500 (EST) Message-ID: <1592010b-700d-865d-41be-a2100f8203f2@bsdio.com> Date: Tue, 29 Nov 2022 16:05:36 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [edk2-devel] USB: reducing/removing EHCI and XHCI logging when bulk transfer requests timeout To: devel@edk2.groups.io, afish@apple.com, Rebecca Cran References: <4CCB8106-9E27-483D-B128-3BA11EE428BE@apple.com> <5fc5a8d3-c187-9ebf-99f0-640e6e48e52a@quicinc.com> From: "Rebecca Cran" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/29/22 13:51, Andrew Fish via groups.io wrote: >> On Nov 29, 2022, at 11:47 AM, Rebecca Cran wrote: >> >> On 11/29/22 12:43, Andrew Fish via groups.io wrote: >>>> On Nov 29, 2022, at 11:12 AM, Rebecca Cran wrote: >>>> >>>> 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). >>>> >>>> I was wondering if we might consider adding some mechanism to omit those messages if the user desires, perhaps on a per-build basis? >>>> >>> Are those DEBUG prints or report status code? >> They're DEBUG prints. > If they happen a lot maybe they should be DEBUG_VERBOSE? I think the UsbNetworkPkg drivers are probably unique in that the network stack polls for packets every 10ms, which will cause them to issue a bulk transfer request with a timeout of 1ms. So as long as there aren't packets being sent, the timeout messages will occur continuously. Putting them under DEBUG_VERBOSE would certainly work. -- Rebecca Cran