On Tue, 4 Jun 2024 18:04:22 +0100 Mark Rutland <mark.rutl...@arm.com> wrote:
> > There may have been something arch specific that I'm unaware about. I'll > > look at that deeper. > > It looks like e are lines in the trace that it doesn't expect: > > + cat trace > + grep -v ^# > + grep 970 > + wc -l > + count_pid=0 > + cat trace > + grep -v ^# > + grep -v 970 > + wc -l > + count_other=3 > + [ 0 -eq 0 -o 3 -ne 0 ] > + fail PID filtering not working? > > ... where we expect that count_other to be 0. > > I hacked in a 'cat trace' just before the 'fail' and that shows: > > + cat trace > # tracer: function_graph > # > # CPU DURATION FUNCTION CALLS > # | | | | | | | > 3) ! 143.685 us | kernel_clone(); > 3) ! 127.055 us | kernel_clone(); > 1) ! 127.170 us | kernel_clone(); > 3) ! 126.840 us | kernel_clone(); > > I'm not sure if that's legitimate output the test is failing to account > for or if that indicates a kernel-side issue. Bah, I just ran the test.d/ftrace/func-filter-pid.tc and it fails too. This did pass my other tests that do run ftracetests. Hmm, I just ran it on my test box that does the tests and it passes there. I wonder if there's some config option that makes it fail :-/ Well, now that I see it fail, I can investigate. -- Steve
