On Fri, Jun 21, 2013 at 3:17 PM, Tom Cook <tom.k.cook@xxxxxxxxx> wrote: > On Fri, Jun 21, 2013 at 12:21 PM, Tom Cook <tom.k.cook@xxxxxxxxx> wrote: > [snip] >> I think I'm nearly starting to get my head around what's going on >> here. The USB driver uses FIQs, which normally isn't a problem >> because nothing would interrupt the FIQ handler (or if it did, it >> wouldn't generate a page fault). But cyclictest runs at a higher >> priority than the USB handler and generates page faults (at least when >> it is initialising). Eventually it interrupts a USB FIQ handler and >> the memory manager doesn't know what to do with a page fault in a FIQ >> handler, so it oopses. Does that sound about right? > > Or, of course, perhaps the tracer is instrumenting the USB FIQ handler > with a hardware watchpoint. These turn up as data aborts, which are > unhandled in FIQ mode. Some evidence for this is that if I use > set_ftrace_filter to restrict the tracing to only a few system > functions then the crash doesn't happen. On that note, is there a way to disable ftrace for fiq handlers in the source code? Something must be done about hard irqs, since data aborts are not handled there, either. Does trace_hardirq_enter deal with this in some way? Tom -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
