Re: [PATCH 01/14] cpufreq/amd-pstate: Show a warning when a CPU fails to setup

[Mario Limonciello]

On 2/10/2025 07:50, Gautham R. Shenoy wrote:
> On Mon, Feb 10, 2025 at 05:29:24PM +0530, Dhananjay Ugwekar wrote:
> > On 2/7/2025 3:26 AM, Mario Limonciello wrote:
> > > From: Mario Limonciello <mario.limonciello@xxxxxxx>
> > >
> > > I came across a system that MSR_AMD_CPPC_CAP1 for some CPUs isn't
> > > populated.  This is an unexpected behavior that is most likely a
> > > BIOS bug. In the event it happens I'd like users to report bugs
> > > to properly root cause and get this fixed.
> >
> > I'm okay with this patch, but I see a similar pr_debug in caller cpufreq_online(),
> > so not sure if this is strictly necessary.
> >
> > 1402                 /*
> > 1403                  * Call driver. From then on the cpufreq must be able
> > 1404                  * to accept all calls to ->verify and ->setpolicy for this CPU.
> > 1405                  */
> > 1406                 ret = cpufreq_driver->init(policy);
> > 1407                 if (ret) {
> > 1408                         pr_debug("%s: %d: initialization failed\n", __func__,
> > 1409                                  __LINE__);
> > 1410                         goto out_free_policy;
> > 1411
>
> Well, the pr_debug() doesn't always get printed unless the loglevel is
> set to debug, which is usually done by the developers and not the end
> users.
>
> However you have a point that since the code jumps to free_cpudata1 on
> failures from amd_pstate_init_perf(), amd_pstate_init_freq(),
> amd_pstate_init_boost_support(), freq_qos_add_request(). So the
> pr_warn() doesn't indicate that the failure is due to
> MSR_AMD_CPPC_CAP1 not being populated.

Right; my point is that without the warning no one knows there is a problem.

I don't expect we can anticipate all the potential causes, and I want 
anyone who hits this to raise a bug and we can ask them to turn on 
dynamic debug / ftrace and then triage it.