|
[AMD Official Use Only - General]
I hit the same issue when verifying USB ECM driver and temporarily change the MNP_SYS_POLL_INTERVAL to 5 sec to make system boots to EFI shell. ECM has USB interrupt endpoint however not sure if it triggers when the packet sent from another end. If it does, then we can have the mechanism to check if the packet is ready in the USB NIC Receive function instead of changing the USB bulk transfer timeout.
Abner
toggle quoted message
Show quoted text
-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca
Cran via groups.io
Sent: Wednesday, November 30, 2022 7:06 AM
To: devel@edk2.groups.io; afish@...; Rebecca Cran
<quic_rcran@...>
Subject: Re: [edk2-devel] USB: reducing/removing EHCI and XHCI logging when
bulk transfer requests timeout
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
On 11/29/22 13:51, Andrew Fish via groups.io wrote:
On Nov 29, 2022, at 11:47 AM, Rebecca Cran <quic_rcran@...>
wrote:
On 11/29/22 12:43, Andrew Fish via groups.io wrote:
On Nov 29, 2022, at 11:12 AM, Rebecca Cran <quic_rcran@...>
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
|
|
|
On 11/29/22 13:51, Andrew Fish via groups.io wrote: On Nov 29, 2022, at 11:47 AM, Rebecca Cran <quic_rcran@...> wrote:
On 11/29/22 12:43, Andrew Fish via groups.io wrote:
On Nov 29, 2022, at 11:12 AM, Rebecca Cran <quic_rcran@...> 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
|
|
|
Andrew Fish
On Nov 29, 2022, at 11:47 AM, Rebecca Cran <quic_rcran@...> wrote:
On 11/29/22 12:43, Andrew Fish via groups.io wrote:
On Nov 29, 2022, at 11:12 AM, Rebecca Cran <quic_rcran@...> 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? Thanks, Andrew Fish --
Rebecca Cran
|
|
|
Rebecca Cran <quic_rcran@...>
On 11/29/22 12:43, Andrew Fish via groups.io wrote:
On Nov 29, 2022, at 11:12 AM, Rebecca Cran <quic_rcran@...> 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. -- Rebecca Cran
|
|
|
Andrew Fish
On Nov 29, 2022, at 11:12 AM, Rebecca Cran <quic_rcran@...> 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? Thanks, Andrew Fish --
Rebecca Cran
|
|
|
Rebecca Cran <quic_rcran@...>
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?
--
Rebecca Cran
|
|
|
