USB test error - USB data packet verify failed

[Mark_Huang]

Hi,

We meet this USB error randomly.
The test condition is to run BurnIn test for 5 mins and then restart the system. (S0->S5->S0)
Once this error happened, it happened during each booting.
The error quantity (7) is the same during each booting.
After re-plug USB loopback, the error can be gone.
However it could happen again while we keep doing this test with several systems.

Would you consider it could be caused by test tool, USB loopback, windows OS, or our hardware?


This is the LED status of USB loopback.
Only two LED keep ON.


Thanks,
Mark

[HamidK (PassMark)]

Hi,

Can you provide more information about the device under test? e.g. motherboard, CPU
Have you ensured that the BIOS and device drivers are up to date? USB errors can sometimes be caused by outdated BIOS or USB drivers.
How many USB2 plugs are connected to the machine? It appears from the screenshot that you have one USB3 and 2x USB2 plugs. Is that correct?
Do you get the same error if you only connect USB2 plugs? or even just one USB2 plug?
Do you observe the same error if you unplug and reconnect all the plugs after booting and then running BurnIn test?

[Mark_Huang]

Hi HamidK,

OS is Windows Server 2019 build 17763 (64-bit),
BurnIn test tool is 10.2 1010.
CPU is Intel Xeon D-1712TR CPU @ 2.00GHz.
Memory is 4x innodisk M4U0-AGS1KCEMP27.
Driver is the latest one from intel. (Chipset-10.1.19485.8386-Public-Server.zip)
BIOS is our latest one.

It looks Windows OS can recognize USB loopback well during the errors happened.


How many USB2 plugs are connected to the machine? It appears from the screenshot that you have one USB3 and 2x USB2 plugs. Is that correct?
=> As you can find in the log, we plug 2x USB2.0 and 1x USB3.0 loopback with the latest driver from PassMark.

Do you get the same error if you only connect USB2 plugs? or even just one USB2 plug?
=> This has to check. But it may take times, as I mentioned it happened randomly.
Please provide a setup you'd like to know. I can try to run it.

Do you observe the same error if you unplug and reconnect all the plugs after booting and then running BurnIn test?
=> Yes, once I un-plug the USB loopback and plug it again. It can fix it.
I just re-plugged one loopback. And the error is gone on this loopback.
But the other one without re-plugging still has those errors.


One hint, we are use 5V standby for USB power. It means USB loopback had the power all the time even at S5 state.
Is it possible that USB loopback became crash inside and need a reset (un-powered once) to recover it?

Thanks,
Mark

[HamidK (PassMark)]

The problem could be related to the use of 5V standby to power up the plugs. Our speculation is that the plugs occasionally fail to enumerate properly after entering S0. However, we cannot confirm this without having the hardware under test. To identify the cause of this failure, we recommend using a protocol analyzer to capture the communication between the host and USB plugs. If you have a protocol analyzer and can provide us with the trace, we would be happy to further investigate this.

[Mark_Huang]

Hi HamidK, Thanks for your feedback.
Unfortunately we don't have the USB protocol analyzer on hand. We are trying to get one.

Yesterday we found this issue again.
This time we changed BurnIn test tool to v9.1 (1003).
OS is still Windows Server 2019 build 17763 (64-bit). => BurnIn test tool can be run with it, right?

We did some checking with other tools while the issue happened.
1. Windows device manager can recognize USB2.0 loopback well
2. USB Device Tree Viewer can recognize USB2.0 loopback well
3. We used USB2Test to run USB test.
a. Loopback mode can not run either
b. Benchmark mode can run well with avg. 363 Mb/s
Here is the log for above a/b test. USB2TestLog.txt

I found an USB setting of Burn In test tool as below.
Can we use 3x USB3.0 loopback to run as 2x USB2.0 and 1x USB3.0 lookback?

[HamidK (PassMark)]

Thank you for your feedback. We think that the issue is not related to the BurnIn test but rather related to hardware (the device under test) or firmware. Please share the trace file with us once you've obtained the protocol analyzer. This will help us diagnose the issue more effectively.

Regarding your last question, yes, you can indeed force USB 3.0 loopback plugs to be recognized as USB 2.0 devices, allowing them to function at USB 2.0 speeds. This could serve as a temporary solution while you await the arrival of the protocol analyzer.