Try again the fill test but with all-in-order

This commit is contained in:
Rodrigo Arias 2024-07-10 12:21:24 +02:00
parent 93936cbe14
commit 9ee8fb06dc
2 changed files with 20 additions and 8 deletions

View File

@ -1114,3 +1114,22 @@ and then begins filling it, printing the progress in the output.
written=57344K, addr=0x3f9f000020 OK
Let's see if we can trace the page fault.
In today's meeting, Jonnatan suggests test the memtool program with all-in-order
configuration. I should also try to reproduce this hang with a "production"
bitstream (from master).
Let's do the quick CSR test first, and then we go back to the ftrace testing,
which will take more time.
Here are the commands I was testing, but nothing comes out of the console, even
after booting with the `tp_printk trace_buf_size=1M` boot options:
mkdir -p /sys/kernel/debug/
mount -t debugfs none /sys/kernel/debug/
td=/sys/kernel/debug/tracing
echo nop > $td/current_tracer
echo 100 > $td/max_graph_depth
echo do_page_fault > $td/set_graph_function
echo function_graph > $td/current_tracer

View File

@ -88,15 +88,8 @@
export PATH=${config.system.build.extraUtils}/bin
mkdir -p /sys/kernel/debug/
mount -t debugfs none /sys/kernel/debug/
td=/sys/kernel/debug/tracing
echo nop > $td/current_tracer
echo 100 > $td/max_graph_depth
echo do_page_fault > $td/set_graph_function
echo function_graph > $td/current_tracer
csrtool all-in-order
#memtool chain $((512 * 1024))
memtool fill $((512 * 1024 * 1024))
# Unlikely to reach this point