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 written=57344K, addr=0x3f9f000020 OK
Let's see if we can trace the page fault. 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 export PATH=${config.system.build.extraUtils}/bin
mkdir -p /sys/kernel/debug/ csrtool all-in-order
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
#memtool chain $((512 * 1024))
memtool fill $((512 * 1024 * 1024)) memtool fill $((512 * 1024 * 1024))
# Unlikely to reach this point # Unlikely to reach this point