[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4912F45A.9000505@redhat.com>
Date: Thu, 06 Nov 2008 08:42:50 -0500
From: Prarit Bhargava <prarit@...hat.com>
To: Ingo Molnar <mingo@...e.hu>
CC: linux-kernel@...r.kernel.org, tglx@...utronix.de,
mark.langsdorf@....com
Subject: Re: [PATCH] Warn of incorrect cpu_khz on AMD systems
> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists