Re: [PATCH] Warn of incorrect cpu_khz on AMD systems

From: Prarit Bhargava
Date: Thu Nov 06 2008 - 08:44:39 EST



Cannot we avoid this situation somehow? The calibrate_cpu() function is quite ugly and does a dangerous thing by ignoring the reservation.


Yes, I noticed that too -- it's really the crux of the problem. If no_ctr_free is a last resort boot option. But I wonder if it should exist at all.

I was originally thinking the system should just stop booting if no_ctr_free and panic() ... and I'm willing to make that patch.

The likelihood of hitting this is low, below .0125% of the time. But when it does hit, it is nasty and difficult to diagnose.
The last thing that I thought could be wrong was that cpu_khz was busted.

This whole sequence is sloppy:

for (i = 0; i < 4; i++)
if (avail_to_resrv_perfctr_nmi_bit(i))
break;
no_ctr_free = (i == 4);
if (no_ctr_free) {
i = 3;
rdmsrl(MSR_K7_EVNTSEL3, evntsel3);
wrmsrl(MSR_K7_EVNTSEL3, 0);
rdmsrl(MSR_K7_PERFCTR3, pmc3);
} else {
reserve_perfctr_nmi(MSR_K7_PERFCTR0 + i);
reserve_evntsel_nmi(MSR_K7_EVNTSEL0 + i);
}

no_ctr_free = (i == 4);
if (no_ctr_free) {
+ printk(KERN_WARN "Warning: AMD perfctrs busy ... "
+ "cpu_khz value may be incorrect.\n");

also, please use a WARN() instead so that kerneloops.org picks it up.


Will do -- but do you think a panic() is more appropriate?

P.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/