henrikbrixandersen
commented
1 year ago Why is this a bug?
Closed nordic-piks closed 1 year ago
henrikbrixandersen
commented
1 year ago Why is this a bug?
Laczen
commented
1 year ago @nordic-piks, the test does not loop endlessly. Be a bit more patient. The test should stop after 400 reboots.
laurenmurphyx64
commented
1 year ago @Laczen So can we close this? It seems like from the log the oldest reboot count isn't increasing.
Laczen
commented
1 year ago @Laczen So can we close this? It seems like from the log the oldest reboot count isn't increasing.
@laurenmurphyx64, it is expected that the oldest reboot count isn't increasing, this will only increase if the flash space has been exhausted. IMO this can be closed. I will remove my assignment.
nordic-piks
commented
1 year ago I would like to reopen this issue. The test fails due to timeout waiting for expected output on console: https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/subsys/nvs/sample.yaml#L12 At my execution, test failed at timeout after 85 sec - I believe this is default value. If this test requires more time, this should be noted in sample.yaml - custom timeout provided. If it is "long", that should be also marked by adding tag "slow". Please see https://docs.zephyrproject.org/latest/develop/test/twister.html for details. @laurenmurphyx64 Please reopen this issue.
Laczen
commented
1 year ago @nordic-piks change the title to "samples: subsys: nvs: sample.nvs.basic does not complete within twister default timeout".
nordic-piks
commented
1 year ago @nordic-piks change the title to "samples: subsys: nvs: sample.nvs.basic does not complete within twister default timeout".
Done, thanks.
FRASTM
commented
1 year ago Also seen on many stm32 platforms : b_u585i_iot02a, disco_l475_iot1, nucleo_f091rc, nucleo_f103rb, nucleo_f207zg, nucleo_f429zi, nucleo_g071rb, nucleo_g474re, nucleo_h743zi, nucleo_l073rz, nucleo_l152re, nucleo_wb55rg, nucleo_wl55jc, stm32f3_disco, stm32l562e_dk.
Laczen
commented
1 year ago @nordic-piks, there are two possible ways to treat this "bug":
MAX_REBOOT in the test (https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/subsys/nvs/src/main.c#L59),BTW this "bug" could be appearing as a result of code changes not related to the sample at all. If as a result of code changes the boot proces is slowed down this will result in a timeout problem.
nordic-piks
commented
1 year ago @nordic-piks, there are two possible ways to treat this "bug":
- Adapt the yaml file to better fit the test (as you proposed),
- Reduce the
MAX_REBOOTin the test (https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/subsys/nvs/src/main.c#L59),BTW this "bug" could be appearing as a result of code changes not related to the sample at all. If as a result of code changes the boot proces is slowed down this will result in a timeout problem.
For my perspective, step 1 is needed to improve documentation (and execution). The step 2 depends what is expected to be checked in this sample.
FRASTM
commented
1 year ago Does the https://github.com/zephyrproject-rtos/zephyr/pull/52742 help in your case ? It fixes the testcase for any the stm32 board.
nordic-piks
commented
1 year ago Does the #52742 help in your case ? It fixes the testcase for any the stm32 board.
Indeed it helps!
Laczen
commented
1 year ago As I mentioned, this problem is not related to the sample at all. Some change at a different subsystem (moving printk into log_printk) resulted in a failure of the test.
Describe the bug The samples/subsys/nvs/sample.nvs.basic loops endlessly
Observed for
To Reproduce Steps to reproduce the behavior:
Expected behavior Valid console output
Impact Not clear
Logs and console output
Environment (please complete the following information):