On Fri, 2 Aug 2013, Steven Rostedt wrote: > On Fri, 2013-08-02 at 13:59 -0400, Alan Stern wrote: > > On Fri, 2 Aug 2013, Steven Rostedt wrote: > > > > > On Fri, 2013-08-02 at 16:36 +0200, Peter Zijlstra wrote: > > > > On Fri, Aug 02, 2013 at 10:14:39AM -0400, Alan Stern wrote: > > > > > URL Clas-3286 2d.h. 1us : local_clock > > > > > <-perf_event_update_userpage > > > > > URL Clas-3286 2d.h. 2us : watchdog_overflow_callback > > > > > <-__perf_event_overflow > > > > > URL Clas-3286 2d.h. 3us : > > > > > arch_trigger_all_cpu_backtrace_handler <-nmi_handle.isra.0 > > > > > URL Clas-3286 2d.h. 3us : perf_ibs_nmi_handler > > > > > <-nmi_handle.isra.0 > > > > > URL Clas-3286 2d.h. 3us : perf_ibs_handle_irq > > > > > <-perf_ibs_nmi_handler > > > > > URL Clas-3286 2d.h. 4us : perf_ibs_handle_irq > > > > > <-perf_ibs_nmi_handler > > > > > URL Clas-3286 2d.h. 4us!: rcu_nmi_exit <-do_nmi > > > > > > > > What's cute is that the trace starts when the NMI handler does > > > > local_irq_save(), _not_ when the NMI starts, which is where the hardware > > > > actually disabled interrupts. > > > > > > Yeah, the NMI can be messing with the tracer. It's built on top of > > > lockdep, which does not handle NMIs. Perhaps we can add NMI handling to > > > the latency tracer, but that may need a bit of work to do that. > > > > Do you have any suggestions with regard to the two questions in my > > previous email? > > Do you mean the one Peter replied to? Or another one.
The one Peter replied to, where this trace output was first posted. > I have to apologize, I'm doing admin work on my Red Hat box, and it's > having network issues at the moment. That's okay. (And I finally remembered to switch to your goodmis.org email address.) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
