[...] >>> >> Unfortunately, the call-trace remains when doing an offlining of cpu1. >>> >> ( It's good to see it's reproducible. ) >>> > >>> > Was the tracepoint enabled? Or was there some other rcu call that >>> > triggered this. Or would cpu_online(smp_processor_id()) return true at >>> > this point? >>> > >>> >>> Thanks Steve for jumping into this one! >>> >>> Good point. >>> I looked at my kernel-config (which I already sent :-)). >>> >>> Do I need to enable...? >>> >>> # CONFIG_RCU_TRACE is not set >>> >>> ...or even more? >>> >> >> What I meant by the tracepoint being enabled, was not that it was >> configured in (I'm assuming it was), but that you started tracing? >> >> echo 1 > /sys/kernel/debug/tracing/events/enable >> >> or >> >> echo 1 > /sys/kernel/debug/tracing/events/tlb/tlb_flushed/enable >> > > NO, I did not start any tracing before doing my testing. > > # cat /sys/kernel/debug/tracing/events/enable > 0 > > # echo 1 > /sys/kernel/debug/tracing/events/enable > > # cat /sys/kernel/debug/tracing/events/enable > X > > # LC_ALL=C cat /sys/kernel/debug/tracing/events/tlb/tlb_flushed/enable > cat: /sys/kernel/debug/tracing/events/tlb/tlb_flushed/enable: No such > file or directory > > Looks like I need to enable...? > > # CONFIG_DEBUG_TLBFLUSH is not set > Here my new kernel-config (not sure if I really need them to be enabled): $ ./scripts/diffconfig /boot/config-3.19.0-rc7-next-20150204.7-iniza-small /boot/config-3.19.0-rc7-next-20150204.9-iniza-small DEBUG_TLBFLUSH n -> y RCU_TRACE n -> y TREE_RCU_TRACE n -> y Steve, this was a typo it's called tlb_flush not tlb_flush*ed*: # cat /sys/kernel/debug/tracing/events/tlb/tlb_flush/enable 1 [ 391.090381] intel_pstate CPU 1 exiting [ 391.104491] smpboot: CPU 1 is now offline - Sedat - -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
