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

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

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

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

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

[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