hwpmc / amd panic when stopping pmcstat
Andriy Gapon
avg at FreeBSD.org
Tue Nov 8 07:42:19 UTC 2016
panic: [pmc,1473] pp_pmcval outside of expected range cpu=2 ri=17
pp_pmcval=fffffffffa529f5b pm_reloadcount=10000
(kgdb) p pp->pp_pmcs[17].pp_pmc->pm_state
$2 = PMC_STATE_DELETED
Those are interesting bits. The counter is logically stopped and the value read
from the hardware is small (become huge after "munging"). My theory is that, at
least for AMD processors, a counter keeps running after overflowing.
At the same time, amd_intr() takes an early way out if pm_state !=
PMC_STATE_RUNNING. So, the counter is allowed to overflow if it's logically
stopped. But that makes the assertion in pmc_process_csw_out() invalid.
It seems that the following patch fixes the problem.
But I wonder if there is a better, perhaps hardware specific, fix.
Also, maybe the condition should be pm_state == PMC_STATE_RUNNING instead of
pm_state != PMC_STATE_DELETED.
diff --git a/sys/dev/hwpmc/hwpmc_mod.c b/sys/dev/hwpmc/hwpmc_mod.c
index 55dc499b1c40e..36bcccb8c27ac 100644
--- a/sys/dev/hwpmc/hwpmc_mod.c
+++ b/sys/dev/hwpmc/hwpmc_mod.c
@@ -1431,8 +1431,8 @@ pmc_process_csw_out(struct thread *td)
* save the reading.
*/
- if (pp != NULL && pp->pp_pmcs[ri].pp_pmc != NULL) {
-
+ if (pm->pm_state != PMC_STATE_DELETED && pp != NULL &&
+ pp->pp_pmcs[ri].pp_pmc != NULL) {
KASSERT(pm == pp->pp_pmcs[ri].pp_pmc,
("[pmc,%d] pm %p != pp_pmcs[%d] %p", __LINE__,
pm, ri, pp->pp_pmcs[ri].pp_pmc));
--
Andriy Gapon
More information about the freebsd-current
mailing list