You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
//sw/device/tests/crypto:rsa_3072_verify_functest_wycheproof_fpga_cw310_test_rom TIMEOUT in 900.0s
//sw/device/tests/crypto:rsa_3072_verify_functest_wycheproof_sim_verilator TIMEOUT in 900.0s
Investigating for known good commit.
It's hanging on vector 170 on cw310 (165 for verilator) (seemingly waiting for OTBN to complete) Instrumenting with logging info, has an effect on where it stalls so I should figure out halting and getting IP over GDB to see where it hangs when uninstrumented.
These are some of the longest tests we have -- I think it's possible they are genuinely timing out, not hanging. The Verilator one definitely will not finish in 900s, I think it takes about 7h. I'll look into the FPGA tests and see whether this is hanging or if we just need to split the tests into two Bazel targets/increase the timeout.
Are we putting the entropy source into auto mode for those tests? And if not, are the tests possibly exhausting the boot-time entropy?
That happened to me when I raised the FPGA frequency in #19368 and found keymgr_sideload_otbn_test started failing. OTBN would get stuck waiting for entropy to complete a secure wipe.
Investigating for known good commit.
It's hanging on vector 170 on cw310 (165 for verilator) (seemingly waiting for OTBN to complete) Instrumenting with logging info, has an effect on where it stalls so I should figure out halting and getting IP over GDB to see where it hangs when uninstrumented.
Originally posted by @drewmacrae in #15877 (comment)
The text was updated successfully, but these errors were encountered: