pre-merge-basic: move hotplug test to end of the test list - #67
Anil (qcom-anilyada) wants to merge 1 commit into
Conversation
Running hotplug immediately after boot causes intermittent failures with the error "[hotplug] CPU1 offline returned EBUSY" as the system has not fully settled down before the hotplug operation is issued. Moving hotplug to the end of the test list gives the system enough time to stabilize before the test runs. Signed-off-by: Anil Yadav <anilyada@qti.qualcomm.com>
Milosz Wasilewski (mwasilew)
left a comment
Milosz Wasilewski (mwasilew)
left a comment
There was a problem hiding this comment.
Sorry, but this is not the way to go. You need to find the root cause of the issue, not change the order of the tests. In fact it should be possible to run tests in a random order.
I agree that ideally hotplug tests should be order-independent and runnable in any sequence. We are not trying to mask the issue via ordering. The failure is due to boot-time stabilization gap in LAVA execution model. However, what we’re observing in LAVA is not just a logical dependency on test order, but a platform readiness timing issue immediately after boot.
As a result, invoking CPU hotplug very early intermittently returns: |
|
This sounds like either bug in the kernel, init process or the test. |
hotplug is a disruptive CPU-topology mutation test, so it should not be the first post-boot readiness test in a pre-merge sequence. Anil (@qcom-anilyada) Do you have any observations on whether moving the test sequence has resulted in any reported test failures? |
What should happen if I only run hotplug test in a test job? |
|
Here are the jobs to compare all requested scenarios:
|
|
As you demonstrated, there is a problem with a test script. |
I will address this in test by deferring CPUs that return EBUSY after the normal retry window, continuing with the remaining CPUs, and retrying the deferred CPUs at the end. That keeps CPU0 covered, avoids adding a larger fixed boot sleep. If a CPU still returns EBUSY during the deferred pass, the test will still fail with the existing dmesg evidence. With that script-side fix, the lava-test-plans reordering becomes optional rather than required for correctness. |
|
Sounds good to me. Are there any other signals that could be used to determine that the "initialization" phase is completed at the boot time? |
3 participants
Running hotplug immediately after boot causes intermittent failures with the error "[hotplug] CPU1 offline returned EBUSY" as the system has not fully settled down before the hotplug operation is issued. Moving hotplug to the end of the test list gives the system enough time to stabilize before the test runs.
Signed-off-by: Anil Yadav anilyada@qti.qualcomm.com