e9aef19e2b
Any daemon executed in init-stage2.sh may interfere with LAVA signals, since any threaded output to console may clutter the signals, which are based on the log output. E.g: This job https://gitlab.freedesktop.org/gallo/mesa/-/jobs/20779120#L2102 has failed because capture-devcoredump.sh was alive and emitting kernel messages to the console during the LAVA signal handling, mangling the output and making the LAVA to fail to check the results of the job. Another problem is that CONFIG_DEBUG_STACK_USAGE Kconfig is enabled. This causes process exit to dump a `RESULT=[ 246.756067] lava-test-case (156) used greatest stack depth: ... bytes left` kernel message to the logs corrupting LAVA signal message. Empirically, it happens one in every 280 jobs. To solve that, compose the lava-test-case custom script with a short sleep to give time for kernel to dump the message clearly and a exit command to keep the return code from init-stage2.sh script. Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15938> |
||
|---|---|---|
| .. | ||
| capture-devcoredump.sh | ||
| generate-env.sh | ||
| init-stage1.sh | ||
| init-stage2.sh | ||
| intel-gpu-freq.sh | ||
| start-x.sh | ||