> Is there any way to detect if the nmi watchdog actually caused the
> timeout? I don't understand the hardware well enough to do it without
You can check if the counter used overflowed :
#define CTR_OVERFLOWED(n) (!((n) & (1U<<31)))
#define CTRL_READ(l,h,msrs,c) do {rdmsr(MSR_P6_PERFCTR0, (l), (h));} while (0)
CTR_READ(low, high, msrs, i);
if (CTR_OVERFLOWED(low)) {
... found
like oprofile does.
I've accidentally deleted your patch, but weren't you unconditionally
returning "break out of loop" from the watchdog ? I'm not very clear on
the difference between NOTIFY_DONE and NOTIFY_OK anyway...
> Plus, can't you get more than one cause of an NMI? Shouldn't you check
> them all?
Shouldn't the NMI stay asserted ? At least with perfctr, two counters
causes two interrupts (actually there's a bug in mainline oprofile on
that that I'll fix when Linus is back)
regards
john
-- "This is playing, not work, therefore it's not a waste of time." - Zath - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/