Hi Daniel, Any comments for this thread? On Wed, Oct 26, 2022 at 11:52 AM richard clark <richard.xnu.clark@xxxxxxxxx> wrote: > > Hi Daniel, > > On Tue, Oct 25, 2022 at 3:16 PM Daniel Bristot de Oliveira > <bristot@xxxxxxxxxx> wrote: > > > > Hi Richard! > > > > On 10/25/22 09:10, richard clark wrote: > > > Hi Daniel, > > > I got several dmsg outputs like this after I insmod the 'wip' into > > > system(with printk+dump_stack reactor, trivial changes for the wip): > > > > Which version of the monitor are you using? I make this question because the > > latest version of the monitor is not "loadable module" yet. So my guess is that > > you are using a version from the paper? > > After switching to the builtin 'wip' monitor and enable it and the > 'printk' reactor... > > > > > [78706.972957] event sched_waking not expected in the state preemptive > > > [78706.972963] CPU: 2 PID: 410 Comm: kworker/2:4 Tainted: G > > > OE 5.15.70-rt50 #1 > > > [78706.972972] Workqueue: events igb_watchdog_task [igb] > > > [78706.973000] Call Trace: > > > [78706.973003] <IRQ> > > > [78706.973006] dump_stack_lvl+0x61/0x86 > > > [78706.973016] dump_stack+0x10/0x18 > > > [78706.973022] handle_sched_wakeup+0x92/0xd0 [rv_poc] > > > [78706.973028] ttwu_do_wakeup+0xc3/0x1d0 > > > [78706.973038] ttwu_do_activate+0x6e/0x100 > > > [78706.973044] try_to_wake_up+0x209/0x700 > > > [78706.973049] ? hrtimer_interrupt+0x11f/0x230 > > > [78706.973059] wake_up_process+0x15/0x30 > > > [78706.973065] irq_exit_rcu+0x9b/0xe0 > > > [78706.973074] sysvec_apic_timer_interrupt+0x92/0xd0 > > > [78706.973082] </IRQ> > > > [78706.973083] <TASK> > > > [78706.973084] asm_sysvec_apic_timer_interrupt+0x1b/0x20 > > > > > > Does that mean something is not unexpected in the system? > > > > Not necessarily, this monitor shows a limitation of tracing, as explained in > > the kernel documentation: > > the dmesg shows below information with that enabled 'wip' monitor: > > root@robotics:/sys/kernel/debug/tracing/rv/monitors# dmesg > ... > [ 332.834168] rv: monitor wip does not allow event sched_waking on > state preemptive > [ 353.833699] rv: monitor wip does not allow event sched_waking on > state preemptive > [ 354.833679] rv: monitor wip does not allow event sched_waking on > state preemptive > ... > I took a look at the discussion at > https://lore.kernel.org/all/f2ca7336162b6dc45f413cfe4e0056e6aa32e7ed.1559051152.git.bristot@xxxxxxxxxx/ > seems that patch was trying to resolve the limitation of the tracing: > the __preempt_count_add() and its trace func is not atomic, does that > mean this issue is still in my system from the dmesg output above? > Another question is, except that the trace limitation, do we have some > specific examples to show that maybe an 'unexpected' event happens > against the current state? > > Thanks! > > > > > https://docs.kernel.org/trace/rv/monitor_wip.html > > > > Anyway, I suggest you using the upstream version of the monitors... > > > > -- Daniel > > > > > Thanks, > > > Richard > >
|