On 02/09/2022 16:14, Carsten Haitzler wrote:
Do you have some idea why it's taking so long to need a longer timeout?
Not sure exactly in this particular case. The madvise06 test calls sync() and writes a "3" to /proc/sys/vm/drop_caches; if there's a lot of stuff in the cache, that seems to take longer than the default timeout of 30s on the Morello board. Subsequent calls are fast but then there's nothing further to write to storage or drop from cache.
30s does seem like a long time for this (?) but I don't know much about
sync() or dropping caches to say. Slow writes to fs? Slow cache access?
In any case I've been finding it hard to replicate. Attempting to fill cache by reading the entire fs to /dev/null but no luck so far: find / -type f -exec cat '{}' >> /dev/null ;
Any ideas?
Thanks, Zach
On 8/31/22 13:42, Zachary Leaf wrote:
Some tests, e.g. madvise06 can timeout on slow systems for some operations:
... madvise06.c:104: TINFO: dropping caches Test timeouted, sending SIGKILL!
When running tests with runltp, export LTP_TIMEOUT_MUL to double the DEFAULT_TIMEOUT value, as set in tst_test.c.
Reported-by: Kevin Brodsky kevin.brodsky@arm.com Signed-off-by Zachary Leaf zachary.leaf@arm.com
runltp | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/runltp b/runltp index 4447da156..32cf39dfb 100755 --- a/runltp +++ b/runltp @@ -79,6 +79,8 @@ setup() export LTPROOT=${PWD} export TMPBASE="/tmp" export PATH="${PATH}:${LTPROOT}/testcases/bin:${LTPROOT}/bin" + # double the DEFAULT_TIMEOUT (tst_test.c) when running tests + export LTP_TIMEOUT_MUL=2 export LTP_DEV_FS_TYPE="ext2"