[PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Giovanni Gherdovich]

Some motherboard based on the TRX40 chipset has been reported to ship
firmware lacking lowest and nominal frequency values in the
_CPC ACPI package. That is, it supports CPPC V2 but not CPPC V3.
Firmware updates aren't available.

amd-pstate requires explicit knowledge of nominal frequency, so it
can't load on this hardware. The driver already has a mechanism (the
so-called "quirks") to accommodate for missing nominal freq in ACPI
tables, so here we use it to match against CPU family, model, core
count, and BIOS version.

Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz>
---
 drivers/cpufreq/amd-pstate.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index 8bfd46d60843..532ff16dd076 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -145,6 +145,11 @@ static struct quirk_entry quirk_amd_7k62 = {
 	.lowest_freq = 550,
 };
 
+static struct quirk_entry quirk_amd_ryzen_threadripper_3000_24c = {
+	.nominal_freq = 3800,
+	.lowest_freq = 550,
+};
+
 static inline u8 freq_to_perf(union perf_cached perf, u32 nominal_freq, unsigned int freq_val)
 {
 	u32 perf_val = DIV_ROUND_UP_ULL((u64)freq_val * perf.nominal_perf, nominal_freq);
@@ -174,6 +179,22 @@ static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
 	return 0;
 }
 
+static int __init dmi_matched_trx40_bios_bug(const struct dmi_system_id *dmi)
+{
+	/**
+	 * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 socket / TRX40 chipset.
+	 */
+	if (boot_cpu_data.x86 == 0x17 &&
+	    boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x3F &&
+	    topology_num_cores_per_package() == 24) {
+		quirks = dmi->driver_data;
+		pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
+		return 1;
+	}
+
+	return 0;
+}
+
 static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
 	{
 		.callback = dmi_matched_7k62_bios_bug,
@@ -184,6 +205,16 @@ static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
 		},
 		.driver_data = &quirk_amd_7k62,
 	},
+	{
+		.callback = dmi_matched_trx40_bios_bug,
+		.ident = "AMD Ryzen Threadripper 3000",
+		.matches = {
+			DMI_MATCH(DMI_BIOS_VENDOR,  "American Megatrends International"),
+			DMI_MATCH(DMI_BIOS_VERSION, "2.80"),
+			DMI_MATCH(DMI_BIOS_DATE,    "05/17/2022"),
+		},
+		.driver_data = &quirk_amd_ryzen_threadripper_3000_24c,
+	},
 	{}
 };
 MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);
-- 
2.43.0

Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Mario Limonciello]

+ Kyle

Kyle,

By chance is this the same system that you were talking to me about offline?



On 10/7/26 09:41, Giovanni Gherdovich wrote:
> Some motherboard based on the TRX40 chipset has been reported to ship
> firmware lacking lowest and nominal frequency values in the
> _CPC ACPI package. That is, it supports CPPC V2 but not CPPC V3.
> Firmware updates aren't available.

Can you please add more information about the vendor/model of the MB, etc?
> 
> amd-pstate requires explicit knowledge of nominal frequency, so it
> can't load on this hardware. The driver already has a mechanism (the
> so-called "quirks") to accommodate for missing nominal freq in ACPI
> tables, so here we use it to match against CPU family, model, core
> count, and BIOS version.

Yeah; it's intended for this specific case of really old hardware that 
the BIOS isn't going to fix it.

I don't understand why core count matters though.

> 
> Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz>
> ---
>   drivers/cpufreq/amd-pstate.c | 31 +++++++++++++++++++++++++++++++
>   1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 8bfd46d60843..532ff16dd076 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -145,6 +145,11 @@ static struct quirk_entry quirk_amd_7k62 = {
>   	.lowest_freq = 550,
>   };
>   
> +static struct quirk_entry quirk_amd_ryzen_threadripper_3000_24c = {
> +	.nominal_freq = 3800,
> +	.lowest_freq = 550,
> +};
> +
>   static inline u8 freq_to_perf(union perf_cached perf, u32 nominal_freq, unsigned int freq_val)
>   {
>   	u32 perf_val = DIV_ROUND_UP_ULL((u64)freq_val * perf.nominal_perf, nominal_freq);
> @@ -174,6 +179,22 @@ static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
>   	return 0;
>   }
>   
> +static int __init dmi_matched_trx40_bios_bug(const struct dmi_system_id *dmi)
> +{
> +	/**
> +	 * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 socket / TRX40 chipset.
> +	 */
> +	if (boot_cpu_data.x86 == 0x17 &&
> +	    boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x3F &&
> +	    topology_num_cores_per_package() == 24) {

Does the number of cores actually matter?  Do you mean to say if you 
swap the CPU to another part CPPC works?

> +		quirks = dmi->driver_data;
> +		pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);

The BIOS bug specifically is lack of values, not invalid values, right? 
Just want to make sure I'm following this right.

> +		return 1;
> +	}
> +
> +	return 0;
> +}
> +
>   static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
>   	{
>   		.callback = dmi_matched_7k62_bios_bug,
> @@ -184,6 +205,16 @@ static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
>   		},
>   		.driver_data = &quirk_amd_7k62,
>   	},
> +	{
> +		.callback = dmi_matched_trx40_bios_bug,
> +		.ident = "AMD Ryzen Threadripper 3000",
> +		.matches = {
> +			DMI_MATCH(DMI_BIOS_VENDOR,  "American Megatrends International"),
> +			DMI_MATCH(DMI_BIOS_VERSION, "2.80"),
> +			DMI_MATCH(DMI_BIOS_DATE,    "05/17/2022"),
> +		},
> +		.driver_data = &quirk_amd_ryzen_threadripper_3000_24c,
> +	},
>   	{}
>   };
>   MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);

Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Kyle Gospodnetich]

Yes this does appear to be the same problem, thank you!

-------- Original Message --------
On Wednesday, 10/07/26 at 07:56 Mario Limonciello <mario.limonciello@amd.com> wrote:
+ Kyle

Kyle,

By chance is this the same system that you were talking to me about offline?



On 10/7/26 09:41, Giovanni Gherdovich wrote:
> Some motherboard based on the TRX40 chipset has been reported to ship
> firmware lacking lowest and nominal frequency values in the
> _CPC ACPI package. That is, it supports CPPC V2 but not CPPC V3.
> Firmware updates aren't available.

Can you please add more information about the vendor/model of the MB, etc?
>
> amd-pstate requires explicit knowledge of nominal frequency, so it
> can't load on this hardware. The driver already has a mechanism (the
> so-called "quirks") to accommodate for missing nominal freq in ACPI
> tables, so here we use it to match against CPU family, model, core
> count, and BIOS version.

Yeah; it's intended for this specific case of really old hardware that
the BIOS isn't going to fix it.

I don't understand why core count matters though.

>
> Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz>
> ---
>   drivers/cpufreq/amd-pstate.c | 31 +++++++++++++++++++++++++++++++
>   1 file changed, 31 insertions(+)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 8bfd46d60843..532ff16dd076 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -145,6 +145,11 @@ static struct quirk_entry quirk_amd_7k62 = {
>   	.lowest_freq = 550,
>   };
>
> +static struct quirk_entry quirk_amd_ryzen_threadripper_3000_24c = {
> +	.nominal_freq = 3800,
> +	.lowest_freq = 550,
> +};
> +
>   static inline u8 freq_to_perf(union perf_cached perf, u32 nominal_freq, unsigned int freq_val)
>   {
>   	u32 perf_val = DIV_ROUND_UP_ULL((u64)freq_val * perf.nominal_perf, nominal_freq);
> @@ -174,6 +179,22 @@ static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
>   	return 0;
>   }
>
> +static int __init dmi_matched_trx40_bios_bug(const struct dmi_system_id *dmi)
> +{
> +	/**
> +	 * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 socket / TRX40 chipset.
> +	 */
> +	if (boot_cpu_data.x86 == 0x17 &&
> +	    boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x3F &&
> +	    topology_num_cores_per_package() == 24) {

Does the number of cores actually matter?  Do you mean to say if you
swap the CPU to another part CPPC works?

> +		quirks = dmi->driver_data;
> +		pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);

The BIOS bug specifically is lack of values, not invalid values, right?
Just want to make sure I'm following this right.

> +		return 1;
> +	}
> +
> +	return 0;
> +}
> +
>   static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
>   	{
>   		.callback = dmi_matched_7k62_bios_bug,
> @@ -184,6 +205,16 @@ static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
>   		},
>   		.driver_data = &quirk_amd_7k62,
>   	},
> +	{
> +		.callback = dmi_matched_trx40_bios_bug,
> +		.ident = "AMD Ryzen Threadripper 3000",
> +		.matches = {
> +			DMI_MATCH(DMI_BIOS_VENDOR,  "American Megatrends International"),
> +			DMI_MATCH(DMI_BIOS_VERSION, "2.80"),
> +			DMI_MATCH(DMI_BIOS_DATE,    "05/17/2022"),
> +		},
> +		.driver_data = &quirk_amd_ryzen_threadripper_3000_24c,
> +	},
>   	{}
>   };
>   MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);

Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Mario Limonciello]

Kyle,

Can you please confirm more about your system?  System Model, vendor, 
BIOS version, BIOS vendor, CPU model.

Thanks,

On 10/7/26 10:04, Kyle Gospodnetich wrote:
> Yes this does appear to be the same problem, thank you!
> 
> -------- Original Message --------
> On Wednesday, 10/07/26 at 07:56 Mario Limonciello <mario.limonciello@amd.com> wrote:
> + Kyle
> 
> Kyle,
> 
> By chance is this the same system that you were talking to me about offline?
> 
> 
> 
> On 10/7/26 09:41, Giovanni Gherdovich wrote:
>> Some motherboard based on the TRX40 chipset has been reported to ship
>> firmware lacking lowest and nominal frequency values in the
>> _CPC ACPI package. That is, it supports CPPC V2 but not CPPC V3.
>> Firmware updates aren't available.
> 
> Can you please add more information about the vendor/model of the MB, etc?
>>
>> amd-pstate requires explicit knowledge of nominal frequency, so it
>> can't load on this hardware. The driver already has a mechanism (the
>> so-called "quirks") to accommodate for missing nominal freq in ACPI
>> tables, so here we use it to match against CPU family, model, core
>> count, and BIOS version.
> 
> Yeah; it's intended for this specific case of really old hardware that
> the BIOS isn't going to fix it.
> 
> I don't understand why core count matters though.
> 
>>
>> Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz>
>> ---
>>    drivers/cpufreq/amd-pstate.c | 31 +++++++++++++++++++++++++++++++
>>    1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
>> index 8bfd46d60843..532ff16dd076 100644
>> --- a/drivers/cpufreq/amd-pstate.c
>> +++ b/drivers/cpufreq/amd-pstate.c
>> @@ -145,6 +145,11 @@ static struct quirk_entry quirk_amd_7k62 = {
>>    	.lowest_freq = 550,
>>    };
>>
>> +static struct quirk_entry quirk_amd_ryzen_threadripper_3000_24c = {
>> +	.nominal_freq = 3800,
>> +	.lowest_freq = 550,
>> +};
>> +
>>    static inline u8 freq_to_perf(union perf_cached perf, u32 nominal_freq, unsigned int freq_val)
>>    {
>>    	u32 perf_val = DIV_ROUND_UP_ULL((u64)freq_val * perf.nominal_perf, nominal_freq);
>> @@ -174,6 +179,22 @@ static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
>>    	return 0;
>>    }
>>
>> +static int __init dmi_matched_trx40_bios_bug(const struct dmi_system_id *dmi)
>> +{
>> +	/**
>> +	 * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 socket / TRX40 chipset.
>> +	 */
>> +	if (boot_cpu_data.x86 == 0x17 &&
>> +	    boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x3F &&
>> +	    topology_num_cores_per_package() == 24) {
> 
> Does the number of cores actually matter?  Do you mean to say if you
> swap the CPU to another part CPPC works?
> 
>> +		quirks = dmi->driver_data;
>> +		pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
> 
> The BIOS bug specifically is lack of values, not invalid values, right?
> Just want to make sure I'm following this right.
> 
>> +		return 1;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>    static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
>>    	{
>>    		.callback = dmi_matched_7k62_bios_bug,
>> @@ -184,6 +205,16 @@ static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
>>    		},
>>    		.driver_data = &quirk_amd_7k62,
>>    	},
>> +	{
>> +		.callback = dmi_matched_trx40_bios_bug,
>> +		.ident = "AMD Ryzen Threadripper 3000",
>> +		.matches = {
>> +			DMI_MATCH(DMI_BIOS_VENDOR,  "American Megatrends International"),
>> +			DMI_MATCH(DMI_BIOS_VERSION, "2.80"),
>> +			DMI_MATCH(DMI_BIOS_DATE,    "05/17/2022"),
>> +		},
>> +		.driver_data = &quirk_amd_ryzen_threadripper_3000_24c,
>> +	},
>>    	{}
>>    };
>>    MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);
> 

Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Kyle Gospodnetich]

AMD Ryzen Threadripper 3960X
MSI TRX40-PRO-10G
https://www.msi.com/Motherboard/TRX40-PRO-10G/support
I am using 7C60v1A3(Beta version), I will update to the latest today -- just learning that exists.
dmidecode reports that as:
Vendor: American Megatrends International, LLC.
Version: 1.80

I've had to disable pstate with:
amd_pstate.enable=0 initcall_blacklist=amd-pstate

Without that my system grinds to a hault, takes upwards of 15 minutes just to hit the desktop.

Thanks, let me know if anything else is needed.
-Kyle Gospodnetich


On Wednesday, October 7th, 2026 at 8:06 AM, Mario Limonciello <mario.limonciello@amd.com> wrote:

> Kyle,
> 
> Can you please confirm more about your system?  System Model, vendor,
> BIOS version, BIOS vendor, CPU model.
> 
> Thanks,
> 
> On 10/7/26 10:04, Kyle Gospodnetich wrote:
> > Yes this does appear to be the same problem, thank you!
> >
> > -------- Original Message --------
> > On Wednesday, 10/07/26 at 07:56 Mario Limonciello <mario.limonciello@amd.com> wrote:
> > + Kyle
> >
> > Kyle,
> >
> > By chance is this the same system that you were talking to me about offline?
> >
> >
> >
> > On 10/7/26 09:41, Giovanni Gherdovich wrote:
> >> Some motherboard based on the TRX40 chipset has been reported to ship
> >> firmware lacking lowest and nominal frequency values in the
> >> _CPC ACPI package. That is, it supports CPPC V2 but not CPPC V3.
> >> Firmware updates aren't available.
> >
> > Can you please add more information about the vendor/model of the MB, etc?
> >>
> >> amd-pstate requires explicit knowledge of nominal frequency, so it
> >> can't load on this hardware. The driver already has a mechanism (the
> >> so-called "quirks") to accommodate for missing nominal freq in ACPI
> >> tables, so here we use it to match against CPU family, model, core
> >> count, and BIOS version.
> >
> > Yeah; it's intended for this specific case of really old hardware that
> > the BIOS isn't going to fix it.
> >
> > I don't understand why core count matters though.
> >
> >>
> >> Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz>
> >> ---
> >>    drivers/cpufreq/amd-pstate.c | 31 +++++++++++++++++++++++++++++++
> >>    1 file changed, 31 insertions(+)
> >>
> >> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> >> index 8bfd46d60843..532ff16dd076 100644
> >> --- a/drivers/cpufreq/amd-pstate.c
> >> +++ b/drivers/cpufreq/amd-pstate.c
> >> @@ -145,6 +145,11 @@ static struct quirk_entry quirk_amd_7k62 = {
> >>    	.lowest_freq = 550,
> >>    };
> >>
> >> +static struct quirk_entry quirk_amd_ryzen_threadripper_3000_24c = {
> >> +	.nominal_freq = 3800,
> >> +	.lowest_freq = 550,
> >> +};
> >> +
> >>    static inline u8 freq_to_perf(union perf_cached perf, u32 nominal_freq, unsigned int freq_val)
> >>    {
> >>    	u32 perf_val = DIV_ROUND_UP_ULL((u64)freq_val * perf.nominal_perf, nominal_freq);
> >> @@ -174,6 +179,22 @@ static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
> >>    	return 0;
> >>    }
> >>
> >> +static int __init dmi_matched_trx40_bios_bug(const struct dmi_system_id *dmi)
> >> +{
> >> +	/**
> >> +	 * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 socket / TRX40 chipset.
> >> +	 */
> >> +	if (boot_cpu_data.x86 == 0x17 &&
> >> +	    boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x3F &&
> >> +	    topology_num_cores_per_package() == 24) {
> >
> > Does the number of cores actually matter?  Do you mean to say if you
> > swap the CPU to another part CPPC works?
> >
> >> +		quirks = dmi->driver_data;
> >> +		pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
> >
> > The BIOS bug specifically is lack of values, not invalid values, right?
> > Just want to make sure I'm following this right.
> >
> >> +		return 1;
> >> +	}
> >> +
> >> +	return 0;
> >> +}
> >> +
> >>    static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
> >>    	{
> >>    		.callback = dmi_matched_7k62_bios_bug,
> >> @@ -184,6 +205,16 @@ static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
> >>    		},
> >>    		.driver_data = &quirk_amd_7k62,
> >>    	},
> >> +	{
> >> +		.callback = dmi_matched_trx40_bios_bug,
> >> +		.ident = "AMD Ryzen Threadripper 3000",
> >> +		.matches = {
> >> +			DMI_MATCH(DMI_BIOS_VENDOR,  "American Megatrends International"),
> >> +			DMI_MATCH(DMI_BIOS_VERSION, "2.80"),
> >> +			DMI_MATCH(DMI_BIOS_DATE,    "05/17/2022"),
> >> +		},
> >> +		.driver_data = &quirk_amd_ryzen_threadripper_3000_24c,
> >> +	},
> >>    	{}
> >>    };
> >>    MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);
> >
> 
>

Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Kyle Gospodnetich]

Missed one,

Release Date: 05/17/2022


On Wednesday, October 7th, 2026 at 10:36 AM, Kyle Gospodnetich <me@kylegospodneti.ch> wrote:

> AMD Ryzen Threadripper 3960X
> MSI TRX40-PRO-10G
> https://www.msi.com/Motherboard/TRX40-PRO-10G/support
> I am using 7C60v1A3(Beta version), I will update to the latest today -- just learning that exists.
> dmidecode reports that as:
> Vendor: American Megatrends International, LLC.
> Version: 1.80
> 
> I've had to disable pstate with:
> amd_pstate.enable=0 initcall_blacklist=amd-pstate
> 
> Without that my system grinds to a hault, takes upwards of 15 minutes just to hit the desktop.
> 
> Thanks, let me know if anything else is needed.
> -Kyle Gospodnetich
> 
> 
> On Wednesday, October 7th, 2026 at 8:06 AM, Mario Limonciello <mario.limonciello@amd.com> wrote:
> 
> > Kyle,
> >
> > Can you please confirm more about your system?  System Model, vendor,
> > BIOS version, BIOS vendor, CPU model.
> >
> > Thanks,
> >
> > On 10/7/26 10:04, Kyle Gospodnetich wrote:
> > > Yes this does appear to be the same problem, thank you!
> > >
> > > -------- Original Message --------
> > > On Wednesday, 10/07/26 at 07:56 Mario Limonciello <mario.limonciello@amd.com> wrote:
> > > + Kyle
> > >
> > > Kyle,
> > >
> > > By chance is this the same system that you were talking to me about offline?
> > >
> > >
> > >
> > > On 10/7/26 09:41, Giovanni Gherdovich wrote:
> > >> Some motherboard based on the TRX40 chipset has been reported to ship
> > >> firmware lacking lowest and nominal frequency values in the
> > >> _CPC ACPI package. That is, it supports CPPC V2 but not CPPC V3.
> > >> Firmware updates aren't available.
> > >
> > > Can you please add more information about the vendor/model of the MB, etc?
> > >>
> > >> amd-pstate requires explicit knowledge of nominal frequency, so it
> > >> can't load on this hardware. The driver already has a mechanism (the
> > >> so-called "quirks") to accommodate for missing nominal freq in ACPI
> > >> tables, so here we use it to match against CPU family, model, core
> > >> count, and BIOS version.
> > >
> > > Yeah; it's intended for this specific case of really old hardware that
> > > the BIOS isn't going to fix it.
> > >
> > > I don't understand why core count matters though.
> > >
> > >>
> > >> Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz>
> > >> ---
> > >>    drivers/cpufreq/amd-pstate.c | 31 +++++++++++++++++++++++++++++++
> > >>    1 file changed, 31 insertions(+)
> > >>
> > >> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> > >> index 8bfd46d60843..532ff16dd076 100644
> > >> --- a/drivers/cpufreq/amd-pstate.c
> > >> +++ b/drivers/cpufreq/amd-pstate.c
> > >> @@ -145,6 +145,11 @@ static struct quirk_entry quirk_amd_7k62 = {
> > >>    	.lowest_freq = 550,
> > >>    };
> > >>
> > >> +static struct quirk_entry quirk_amd_ryzen_threadripper_3000_24c = {
> > >> +	.nominal_freq = 3800,
> > >> +	.lowest_freq = 550,
> > >> +};
> > >> +
> > >>    static inline u8 freq_to_perf(union perf_cached perf, u32 nominal_freq, unsigned int freq_val)
> > >>    {
> > >>    	u32 perf_val = DIV_ROUND_UP_ULL((u64)freq_val * perf.nominal_perf, nominal_freq);
> > >> @@ -174,6 +179,22 @@ static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
> > >>    	return 0;
> > >>    }
> > >>
> > >> +static int __init dmi_matched_trx40_bios_bug(const struct dmi_system_id *dmi)
> > >> +{
> > >> +	/**
> > >> +	 * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 socket / TRX40 chipset.
> > >> +	 */
> > >> +	if (boot_cpu_data.x86 == 0x17 &&
> > >> +	    boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x3F &&
> > >> +	    topology_num_cores_per_package() == 24) {
> > >
> > > Does the number of cores actually matter?  Do you mean to say if you
> > > swap the CPU to another part CPPC works?
> > >
> > >> +		quirks = dmi->driver_data;
> > >> +		pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
> > >
> > > The BIOS bug specifically is lack of values, not invalid values, right?
> > > Just want to make sure I'm following this right.
> > >
> > >> +		return 1;
> > >> +	}
> > >> +
> > >> +	return 0;
> > >> +}
> > >> +
> > >>    static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
> > >>    	{
> > >>    		.callback = dmi_matched_7k62_bios_bug,
> > >> @@ -184,6 +205,16 @@ static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
> > >>    		},
> > >>    		.driver_data = &quirk_amd_7k62,
> > >>    	},
> > >> +	{
> > >> +		.callback = dmi_matched_trx40_bios_bug,
> > >> +		.ident = "AMD Ryzen Threadripper 3000",
> > >> +		.matches = {
> > >> +			DMI_MATCH(DMI_BIOS_VENDOR,  "American Megatrends International"),
> > >> +			DMI_MATCH(DMI_BIOS_VERSION, "2.80"),
> > >> +			DMI_MATCH(DMI_BIOS_DATE,    "05/17/2022"),
> > >> +		},
> > >> +		.driver_data = &quirk_amd_ryzen_threadripper_3000_24c,
> > >> +	},
> > >>    	{}
> > >>    };
> > >>    MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);
> > >
> >
> >

Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Mario Limonciello]

OK, let's wait and see what happens after you upgrade.  New versions of 
FW and the behavior please.

On 10/7/26 12:43, Kyle Gospodnetich wrote:
> Missed one,
> 
> Release Date: 05/17/2022
> 
> 
> On Wednesday, October 7th, 2026 at 10:36 AM, Kyle Gospodnetich <me@kylegospodneti.ch> wrote:
> 
>> AMD Ryzen Threadripper 3960X
>> MSI TRX40-PRO-10G
>> https://www.msi.com/Motherboard/TRX40-PRO-10G/support
>> I am using 7C60v1A3(Beta version), I will update to the latest today -- just learning that exists.
>> dmidecode reports that as:
>> Vendor: American Megatrends International, LLC.
>> Version: 1.80
>>
>> I've had to disable pstate with:
>> amd_pstate.enable=0 initcall_blacklist=amd-pstate
>>
>> Without that my system grinds to a hault, takes upwards of 15 minutes just to hit the desktop.
>>
>> Thanks, let me know if anything else is needed.
>> -Kyle Gospodnetich
>>
>>
>> On Wednesday, October 7th, 2026 at 8:06 AM, Mario Limonciello <mario.limonciello@amd.com> wrote:
>>
>>> Kyle,
>>>
>>> Can you please confirm more about your system?  System Model, vendor,
>>> BIOS version, BIOS vendor, CPU model.
>>>
>>> Thanks,
>>>
>>> On 10/7/26 10:04, Kyle Gospodnetich wrote:
>>>> Yes this does appear to be the same problem, thank you!
>>>>
>>>> -------- Original Message --------
>>>> On Wednesday, 10/07/26 at 07:56 Mario Limonciello <mario.limonciello@amd.com> wrote:
>>>> + Kyle
>>>>
>>>> Kyle,
>>>>
>>>> By chance is this the same system that you were talking to me about offline?
>>>>
>>>>
>>>>
>>>> On 10/7/26 09:41, Giovanni Gherdovich wrote:
>>>>> Some motherboard based on the TRX40 chipset has been reported to ship
>>>>> firmware lacking lowest and nominal frequency values in the
>>>>> _CPC ACPI package. That is, it supports CPPC V2 but not CPPC V3.
>>>>> Firmware updates aren't available.
>>>>
>>>> Can you please add more information about the vendor/model of the MB, etc?
>>>>>
>>>>> amd-pstate requires explicit knowledge of nominal frequency, so it
>>>>> can't load on this hardware. The driver already has a mechanism (the
>>>>> so-called "quirks") to accommodate for missing nominal freq in ACPI
>>>>> tables, so here we use it to match against CPU family, model, core
>>>>> count, and BIOS version.
>>>>
>>>> Yeah; it's intended for this specific case of really old hardware that
>>>> the BIOS isn't going to fix it.
>>>>
>>>> I don't understand why core count matters though.
>>>>
>>>>>
>>>>> Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz>
>>>>> ---
>>>>>     drivers/cpufreq/amd-pstate.c | 31 +++++++++++++++++++++++++++++++
>>>>>     1 file changed, 31 insertions(+)
>>>>>
>>>>> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
>>>>> index 8bfd46d60843..532ff16dd076 100644
>>>>> --- a/drivers/cpufreq/amd-pstate.c
>>>>> +++ b/drivers/cpufreq/amd-pstate.c
>>>>> @@ -145,6 +145,11 @@ static struct quirk_entry quirk_amd_7k62 = {
>>>>>     	.lowest_freq = 550,
>>>>>     };
>>>>>
>>>>> +static struct quirk_entry quirk_amd_ryzen_threadripper_3000_24c = {
>>>>> +	.nominal_freq = 3800,
>>>>> +	.lowest_freq = 550,
>>>>> +};
>>>>> +
>>>>>     static inline u8 freq_to_perf(union perf_cached perf, u32 nominal_freq, unsigned int freq_val)
>>>>>     {
>>>>>     	u32 perf_val = DIV_ROUND_UP_ULL((u64)freq_val * perf.nominal_perf, nominal_freq);
>>>>> @@ -174,6 +179,22 @@ static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
>>>>>     	return 0;
>>>>>     }
>>>>>
>>>>> +static int __init dmi_matched_trx40_bios_bug(const struct dmi_system_id *dmi)
>>>>> +{
>>>>> +	/**
>>>>> +	 * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 socket / TRX40 chipset.
>>>>> +	 */
>>>>> +	if (boot_cpu_data.x86 == 0x17 &&
>>>>> +	    boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x3F &&
>>>>> +	    topology_num_cores_per_package() == 24) {
>>>>
>>>> Does the number of cores actually matter?  Do you mean to say if you
>>>> swap the CPU to another part CPPC works?
>>>>
>>>>> +		quirks = dmi->driver_data;
>>>>> +		pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
>>>>
>>>> The BIOS bug specifically is lack of values, not invalid values, right?
>>>> Just want to make sure I'm following this right.
>>>>
>>>>> +		return 1;
>>>>> +	}
>>>>> +
>>>>> +	return 0;
>>>>> +}
>>>>> +
>>>>>     static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
>>>>>     	{
>>>>>     		.callback = dmi_matched_7k62_bios_bug,
>>>>> @@ -184,6 +205,16 @@ static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
>>>>>     		},
>>>>>     		.driver_data = &quirk_amd_7k62,
>>>>>     	},
>>>>> +	{
>>>>> +		.callback = dmi_matched_trx40_bios_bug,
>>>>> +		.ident = "AMD Ryzen Threadripper 3000",
>>>>> +		.matches = {
>>>>> +			DMI_MATCH(DMI_BIOS_VENDOR,  "American Megatrends International"),
>>>>> +			DMI_MATCH(DMI_BIOS_VERSION, "2.80"),
>>>>> +			DMI_MATCH(DMI_BIOS_DATE,    "05/17/2022"),
>>>>> +		},
>>>>> +		.driver_data = &quirk_amd_ryzen_threadripper_3000_24c,
>>>>> +	},
>>>>>     	{}
>>>>>     };
>>>>>     MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);
>>>>
>>>
>>>

Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Kyle Gospodnetich]

Looks like it's finally fixed with that last BIOS release, it's been years!

Platform Firmware Information
	Vendor: American Megatrends International, LLC.
	Version: 1.A4
	Release Date: 06/15/2026

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
amd-pstate-epp

And no performance issues. Thanks!


On Wednesday, October 7th, 2026 at 11:08 AM, Mario Limonciello <mario.limonciello@amd.com> wrote:

> OK, let's wait and see what happens after you upgrade.  New versions of
> FW and the behavior please.
> 
> On 10/7/26 12:43, Kyle Gospodnetich wrote:
> > Missed one,
> >
> > Release Date: 05/17/2022
> >
> >
> > On Wednesday, October 7th, 2026 at 10:36 AM, Kyle Gospodnetich <me@kylegospodneti.ch> wrote:
> >
> >> AMD Ryzen Threadripper 3960X
> >> MSI TRX40-PRO-10G
> >> https://www.msi.com/Motherboard/TRX40-PRO-10G/support
> >> I am using 7C60v1A3(Beta version), I will update to the latest today -- just learning that exists.
> >> dmidecode reports that as:
> >> Vendor: American Megatrends International, LLC.
> >> Version: 1.80
> >>
> >> I've had to disable pstate with:
> >> amd_pstate.enable=0 initcall_blacklist=amd-pstate
> >>
> >> Without that my system grinds to a hault, takes upwards of 15 minutes just to hit the desktop.
> >>
> >> Thanks, let me know if anything else is needed.
> >> -Kyle Gospodnetich
> >>
> >>
> >> On Wednesday, October 7th, 2026 at 8:06 AM, Mario Limonciello <mario.limonciello@amd.com> wrote:
> >>
> >>> Kyle,
> >>>
> >>> Can you please confirm more about your system?  System Model, vendor,
> >>> BIOS version, BIOS vendor, CPU model.
> >>>
> >>> Thanks,
> >>>
> >>> On 10/7/26 10:04, Kyle Gospodnetich wrote:
> >>>> Yes this does appear to be the same problem, thank you!
> >>>>
> >>>> -------- Original Message --------
> >>>> On Wednesday, 10/07/26 at 07:56 Mario Limonciello <mario.limonciello@amd.com> wrote:
> >>>> + Kyle
> >>>>
> >>>> Kyle,
> >>>>
> >>>> By chance is this the same system that you were talking to me about offline?
> >>>>
> >>>>
> >>>>
> >>>> On 10/7/26 09:41, Giovanni Gherdovich wrote:
> >>>>> Some motherboard based on the TRX40 chipset has been reported to ship
> >>>>> firmware lacking lowest and nominal frequency values in the
> >>>>> _CPC ACPI package. That is, it supports CPPC V2 but not CPPC V3.
> >>>>> Firmware updates aren't available.
> >>>>
> >>>> Can you please add more information about the vendor/model of the MB, etc?
> >>>>>
> >>>>> amd-pstate requires explicit knowledge of nominal frequency, so it
> >>>>> can't load on this hardware. The driver already has a mechanism (the
> >>>>> so-called "quirks") to accommodate for missing nominal freq in ACPI
> >>>>> tables, so here we use it to match against CPU family, model, core
> >>>>> count, and BIOS version.
> >>>>
> >>>> Yeah; it's intended for this specific case of really old hardware that
> >>>> the BIOS isn't going to fix it.
> >>>>
> >>>> I don't understand why core count matters though.
> >>>>
> >>>>>
> >>>>> Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz>
> >>>>> ---
> >>>>>     drivers/cpufreq/amd-pstate.c | 31 +++++++++++++++++++++++++++++++
> >>>>>     1 file changed, 31 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> >>>>> index 8bfd46d60843..532ff16dd076 100644
> >>>>> --- a/drivers/cpufreq/amd-pstate.c
> >>>>> +++ b/drivers/cpufreq/amd-pstate.c
> >>>>> @@ -145,6 +145,11 @@ static struct quirk_entry quirk_amd_7k62 = {
> >>>>>     	.lowest_freq = 550,
> >>>>>     };
> >>>>>
> >>>>> +static struct quirk_entry quirk_amd_ryzen_threadripper_3000_24c = {
> >>>>> +	.nominal_freq = 3800,
> >>>>> +	.lowest_freq = 550,
> >>>>> +};
> >>>>> +
> >>>>>     static inline u8 freq_to_perf(union perf_cached perf, u32 nominal_freq, unsigned int freq_val)
> >>>>>     {
> >>>>>     	u32 perf_val = DIV_ROUND_UP_ULL((u64)freq_val * perf.nominal_perf, nominal_freq);
> >>>>> @@ -174,6 +179,22 @@ static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
> >>>>>     	return 0;
> >>>>>     }
> >>>>>
> >>>>> +static int __init dmi_matched_trx40_bios_bug(const struct dmi_system_id *dmi)
> >>>>> +{
> >>>>> +	/**
> >>>>> +	 * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 socket / TRX40 chipset.
> >>>>> +	 */
> >>>>> +	if (boot_cpu_data.x86 == 0x17 &&
> >>>>> +	    boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x3F &&
> >>>>> +	    topology_num_cores_per_package() == 24) {
> >>>>
> >>>> Does the number of cores actually matter?  Do you mean to say if you
> >>>> swap the CPU to another part CPPC works?
> >>>>
> >>>>> +		quirks = dmi->driver_data;
> >>>>> +		pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
> >>>>
> >>>> The BIOS bug specifically is lack of values, not invalid values, right?
> >>>> Just want to make sure I'm following this right.
> >>>>
> >>>>> +		return 1;
> >>>>> +	}
> >>>>> +
> >>>>> +	return 0;
> >>>>> +}
> >>>>> +
> >>>>>     static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
> >>>>>     	{
> >>>>>     		.callback = dmi_matched_7k62_bios_bug,
> >>>>> @@ -184,6 +205,16 @@ static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
> >>>>>     		},
> >>>>>     		.driver_data = &quirk_amd_7k62,
> >>>>>     	},
> >>>>> +	{
> >>>>> +		.callback = dmi_matched_trx40_bios_bug,
> >>>>> +		.ident = "AMD Ryzen Threadripper 3000",
> >>>>> +		.matches = {
> >>>>> +			DMI_MATCH(DMI_BIOS_VENDOR,  "American Megatrends International"),
> >>>>> +			DMI_MATCH(DMI_BIOS_VERSION, "2.80"),
> >>>>> +			DMI_MATCH(DMI_BIOS_DATE,    "05/17/2022"),
> >>>>> +		},
> >>>>> +		.driver_data = &quirk_amd_ryzen_threadripper_3000_24c,
> >>>>> +	},
> >>>>>     	{}
> >>>>>     };
> >>>>>     MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);
> >>>>
> >>>
> >>>
> 
>

Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Mario Limonciello]

Well that's great news.

Giorvanni - are you sure you don't have a BIOS update available from 
your vendor?

I would much rather not carry a quirk like this if it has been fixed in 
latest BIOS.

On 10/7/26 13:30, Kyle Gospodnetich wrote:
> Looks like it's finally fixed with that last BIOS release, it's been years!
> 
> Platform Firmware Information
> 	Vendor: American Megatrends International, LLC.
> 	Version: 1.A4
> 	Release Date: 06/15/2026
> 
> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
> amd-pstate-epp
> 
> And no performance issues. Thanks!
> 
> 
> On Wednesday, October 7th, 2026 at 11:08 AM, Mario Limonciello <mario.limonciello@amd.com> wrote:
> 
>> OK, let's wait and see what happens after you upgrade.  New versions of
>> FW and the behavior please.
>>
>> On 10/7/26 12:43, Kyle Gospodnetich wrote:
>>> Missed one,
>>>
>>> Release Date: 05/17/2022
>>>
>>>
>>> On Wednesday, October 7th, 2026 at 10:36 AM, Kyle Gospodnetich <me@kylegospodneti.ch> wrote:
>>>
>>>> AMD Ryzen Threadripper 3960X
>>>> MSI TRX40-PRO-10G
>>>> https://www.msi.com/Motherboard/TRX40-PRO-10G/support
>>>> I am using 7C60v1A3(Beta version), I will update to the latest today -- just learning that exists.
>>>> dmidecode reports that as:
>>>> Vendor: American Megatrends International, LLC.
>>>> Version: 1.80
>>>>
>>>> I've had to disable pstate with:
>>>> amd_pstate.enable=0 initcall_blacklist=amd-pstate
>>>>
>>>> Without that my system grinds to a hault, takes upwards of 15 minutes just to hit the desktop.
>>>>
>>>> Thanks, let me know if anything else is needed.
>>>> -Kyle Gospodnetich
>>>>
>>>>
>>>> On Wednesday, October 7th, 2026 at 8:06 AM, Mario Limonciello <mario.limonciello@amd.com> wrote:
>>>>
>>>>> Kyle,
>>>>>
>>>>> Can you please confirm more about your system?  System Model, vendor,
>>>>> BIOS version, BIOS vendor, CPU model.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> On 10/7/26 10:04, Kyle Gospodnetich wrote:
>>>>>> Yes this does appear to be the same problem, thank you!
>>>>>>
>>>>>> -------- Original Message --------
>>>>>> On Wednesday, 10/07/26 at 07:56 Mario Limonciello <mario.limonciello@amd.com> wrote:
>>>>>> + Kyle
>>>>>>
>>>>>> Kyle,
>>>>>>
>>>>>> By chance is this the same system that you were talking to me about offline?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10/7/26 09:41, Giovanni Gherdovich wrote:
>>>>>>> Some motherboard based on the TRX40 chipset has been reported to ship
>>>>>>> firmware lacking lowest and nominal frequency values in the
>>>>>>> _CPC ACPI package. That is, it supports CPPC V2 but not CPPC V3.
>>>>>>> Firmware updates aren't available.
>>>>>>
>>>>>> Can you please add more information about the vendor/model of the MB, etc?
>>>>>>>
>>>>>>> amd-pstate requires explicit knowledge of nominal frequency, so it
>>>>>>> can't load on this hardware. The driver already has a mechanism (the
>>>>>>> so-called "quirks") to accommodate for missing nominal freq in ACPI
>>>>>>> tables, so here we use it to match against CPU family, model, core
>>>>>>> count, and BIOS version.
>>>>>>
>>>>>> Yeah; it's intended for this specific case of really old hardware that
>>>>>> the BIOS isn't going to fix it.
>>>>>>
>>>>>> I don't understand why core count matters though.
>>>>>>
>>>>>>>
>>>>>>> Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz>
>>>>>>> ---
>>>>>>>      drivers/cpufreq/amd-pstate.c | 31 +++++++++++++++++++++++++++++++
>>>>>>>      1 file changed, 31 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
>>>>>>> index 8bfd46d60843..532ff16dd076 100644
>>>>>>> --- a/drivers/cpufreq/amd-pstate.c
>>>>>>> +++ b/drivers/cpufreq/amd-pstate.c
>>>>>>> @@ -145,6 +145,11 @@ static struct quirk_entry quirk_amd_7k62 = {
>>>>>>>      	.lowest_freq = 550,
>>>>>>>      };
>>>>>>>
>>>>>>> +static struct quirk_entry quirk_amd_ryzen_threadripper_3000_24c = {
>>>>>>> +	.nominal_freq = 3800,
>>>>>>> +	.lowest_freq = 550,
>>>>>>> +};
>>>>>>> +
>>>>>>>      static inline u8 freq_to_perf(union perf_cached perf, u32 nominal_freq, unsigned int freq_val)
>>>>>>>      {
>>>>>>>      	u32 perf_val = DIV_ROUND_UP_ULL((u64)freq_val * perf.nominal_perf, nominal_freq);
>>>>>>> @@ -174,6 +179,22 @@ static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
>>>>>>>      	return 0;
>>>>>>>      }
>>>>>>>
>>>>>>> +static int __init dmi_matched_trx40_bios_bug(const struct dmi_system_id *dmi)
>>>>>>> +{
>>>>>>> +	/**
>>>>>>> +	 * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 socket / TRX40 chipset.
>>>>>>> +	 */
>>>>>>> +	if (boot_cpu_data.x86 == 0x17 &&
>>>>>>> +	    boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x3F &&
>>>>>>> +	    topology_num_cores_per_package() == 24) {
>>>>>>
>>>>>> Does the number of cores actually matter?  Do you mean to say if you
>>>>>> swap the CPU to another part CPPC works?
>>>>>>
>>>>>>> +		quirks = dmi->driver_data;
>>>>>>> +		pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
>>>>>>
>>>>>> The BIOS bug specifically is lack of values, not invalid values, right?
>>>>>> Just want to make sure I'm following this right.
>>>>>>
>>>>>>> +		return 1;
>>>>>>> +	}
>>>>>>> +
>>>>>>> +	return 0;
>>>>>>> +}
>>>>>>> +
>>>>>>>      static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
>>>>>>>      	{
>>>>>>>      		.callback = dmi_matched_7k62_bios_bug,
>>>>>>> @@ -184,6 +205,16 @@ static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
>>>>>>>      		},
>>>>>>>      		.driver_data = &quirk_amd_7k62,
>>>>>>>      	},
>>>>>>> +	{
>>>>>>> +		.callback = dmi_matched_trx40_bios_bug,
>>>>>>> +		.ident = "AMD Ryzen Threadripper 3000",
>>>>>>> +		.matches = {
>>>>>>> +			DMI_MATCH(DMI_BIOS_VENDOR,  "American Megatrends International"),
>>>>>>> +			DMI_MATCH(DMI_BIOS_VERSION, "2.80"),
>>>>>>> +			DMI_MATCH(DMI_BIOS_DATE,    "05/17/2022"),
>>>>>>> +		},
>>>>>>> +		.driver_data = &quirk_amd_ryzen_threadripper_3000_24c,
>>>>>>> +	},
>>>>>>>      	{}
>>>>>>>      };
>>>>>>>      MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);
>>>>>>
>>>>>
>>>>>
>>
>>

Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Giovanni Gherdovich]

Hello Mario, Kyle,

Kyle:
thanks for checking BIOS updates, you and I have a very similar
motherboard in fact; the one I'm working with is the MSI "TRX40 PRO WIFI".

Mario:
Yes I suppose I do have a BIOS update; sorry, it escaped my notice.
After Kyle's successful test, I checked msi.com and indeed there's a
BIOS release at https://www.msi.com/Motherboard/TRX40-PRO-WIFI/support
from last June (version 7C60v294 from 2026-06-23).

I need to ask the openSUSE user who reported this problem to test the
new BIOS (I don't have direct access to this machine). I'll let you know.


Thanks,
Giovanni

On Wed Oct 7, 2026 20:32, Mario Limonciello wrote:
> Well that's great news.
> 
> Giorvanni - are you sure you don't have a BIOS update available from your vendor?
> 
> I would much rather not carry a quirk like this if it has been fixed in latest BIOS.
> 
> On 10/7/26 13:30, Kyle Gospodnetich wrote:
>> Looks like it's finally fixed with that last BIOS release, it's been years!
>>
>> Platform Firmware Information
>>     Vendor: American Megatrends International, LLC.
>>     Version: 1.A4
>>     Release Date: 06/15/2026
>>
>> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
>> amd-pstate-epp
>>
>> And no performance issues. Thanks!
>>
>>
>> On Wednesday, October 7th, 2026 at 11:08 AM, Mario Limonciello <mario.limonciello@amd.com> wrote:
>>
>>> OK, let's wait and see what happens after you upgrade.  New versions of
>>> FW and the behavior please.
>>>
>>> On 10/7/26 12:43, Kyle Gospodnetich wrote:
>>>> Missed one,
>>>>
>>>> Release Date: 05/17/2022
>>>>
>>>>
>>>> On Wednesday, October 7th, 2026 at 10:36 AM, Kyle Gospodnetich <me@kylegospodneti.ch> wrote:
>>>>
>>>>> AMD Ryzen Threadripper 3960X
>>>>> MSI TRX40-PRO-10G
>>>>> https://www.msi.com/Motherboard/TRX40-PRO-10G/support
>>>>> I am using 7C60v1A3(Beta version), I will update to the latest today -- just learning that exists.
>>>>> dmidecode reports that as:
>>>>> Vendor: American Megatrends International, LLC.
>>>>> Version: 1.80
>>>>>
>>>>> I've had to disable pstate with:
>>>>> amd_pstate.enable=0 initcall_blacklist=amd-pstate
>>>>>
>>>>> Without that my system grinds to a hault, takes upwards of 15 minutes just to hit the desktop.
>>>>>
>>>>> Thanks, let me know if anything else is needed.
>>>>> -Kyle Gospodnetich
>>>>>
>>>>>
>>>>> On Wednesday, October 7th, 2026 at 8:06 AM, Mario Limonciello <mario.limonciello@amd.com> wrote:
>>>>>
>>>>>> Kyle,
>>>>>>
>>>>>> Can you please confirm more about your system?  System Model, vendor,
>>>>>> BIOS version, BIOS vendor, CPU model.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> On 10/7/26 10:04, Kyle Gospodnetich wrote:
>>>>>>> Yes this does appear to be the same problem, thank you!
>>>>>>>
>>>>>>> -------- Original Message --------
>>>>>>> On Wednesday, 10/07/26 at 07:56 Mario Limonciello <mario.limonciello@amd.com> wrote:
>>>>>>> + Kyle
>>>>>>>
>>>>>>> Kyle,
>>>>>>>
>>>>>>> By chance is this the same system that you were talking to me about offline?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 10/7/26 09:41, Giovanni Gherdovich wrote:
>>>>>>>> Some motherboard based on the TRX40 chipset has been reported to ship
>>>>>>>> firmware lacking lowest and nominal frequency values in the
>>>>>>>> _CPC ACPI package. That is, it supports CPPC V2 but not CPPC V3.
>>>>>>>> Firmware updates aren't available.
>>>>>>>
>>>>>>> Can you please add more information about the vendor/model of the MB, etc?
>>>>>>>>
>>>>>>>> amd-pstate requires explicit knowledge of nominal frequency, so it
>>>>>>>> can't load on this hardware. The driver already has a mechanism (the
>>>>>>>> so-called "quirks") to accommodate for missing nominal freq in ACPI
>>>>>>>> tables, so here we use it to match against CPU family, model, core
>>>>>>>> count, and BIOS version.
>>>>>>>
>>>>>>> Yeah; it's intended for this specific case of really old hardware that
>>>>>>> the BIOS isn't going to fix it.
>>>>>>>
>>>>>>> I don't understand why core count matters though.
>>>>>>>
>>>>>>>>
>>>>>>>> Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz>
>>>>>>>> ---
>>>>>>>>      drivers/cpufreq/amd-pstate.c | 31 +++++++++++++++++++++++++++++++
>>>>>>>>      1 file changed, 31 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
>>>>>>>> index 8bfd46d60843..532ff16dd076 100644
>>>>>>>> --- a/drivers/cpufreq/amd-pstate.c
>>>>>>>> +++ b/drivers/cpufreq/amd-pstate.c
>>>>>>>> @@ -145,6 +145,11 @@ static struct quirk_entry quirk_amd_7k62 = {
>>>>>>>>          .lowest_freq = 550,
>>>>>>>>      };
>>>>>>>>
>>>>>>>> +static struct quirk_entry quirk_amd_ryzen_threadripper_3000_24c = {
>>>>>>>> +    .nominal_freq = 3800,
>>>>>>>> +    .lowest_freq = 550,
>>>>>>>> +};
>>>>>>>> +
>>>>>>>>      static inline u8 freq_to_perf(union perf_cached perf, u32 nominal_freq, unsigned int freq_val)
>>>>>>>>      {
>>>>>>>>          u32 perf_val = DIV_ROUND_UP_ULL((u64)freq_val * perf.nominal_perf, nominal_freq);
>>>>>>>> @@ -174,6 +179,22 @@ static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
>>>>>>>>          return 0;
>>>>>>>>      }
>>>>>>>>
>>>>>>>> +static int __init dmi_matched_trx40_bios_bug(const struct dmi_system_id *dmi)
>>>>>>>> +{
>>>>>>>> +    /**
>>>>>>>> +     * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 socket / TRX40 chipset.
>>>>>>>> +     */
>>>>>>>> +    if (boot_cpu_data.x86 == 0x17 &&
>>>>>>>> +        boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x3F &&
>>>>>>>> +        topology_num_cores_per_package() == 24) {
>>>>>>>
>>>>>>> Does the number of cores actually matter?  Do you mean to say if you
>>>>>>> swap the CPU to another part CPPC works?
>>>>>>>
>>>>>>>> +        quirks = dmi->driver_data;
>>>>>>>> +        pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
>>>>>>>
>>>>>>> The BIOS bug specifically is lack of values, not invalid values, right?
>>>>>>> Just want to make sure I'm following this right.
>>>>>>>
>>>>>>>> +        return 1;
>>>>>>>> +    }
>>>>>>>> +
>>>>>>>> +    return 0;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>>      static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
>>>>>>>>          {
>>>>>>>>              .callback = dmi_matched_7k62_bios_bug,
>>>>>>>> @@ -184,6 +205,16 @@ static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
>>>>>>>>              },
>>>>>>>>              .driver_data = &quirk_amd_7k62,
>>>>>>>>          },
>>>>>>>> +    {
>>>>>>>> +        .callback = dmi_matched_trx40_bios_bug,
>>>>>>>> +        .ident = "AMD Ryzen Threadripper 3000",
>>>>>>>> +        .matches = {
>>>>>>>> +            DMI_MATCH(DMI_BIOS_VENDOR,  "American Megatrends International"),
>>>>>>>> +            DMI_MATCH(DMI_BIOS_VERSION, "2.80"),
>>>>>>>> +            DMI_MATCH(DMI_BIOS_DATE,    "05/17/2022"),
>>>>>>>> +        },
>>>>>>>> +        .driver_data = &quirk_amd_ryzen_threadripper_3000_24c,
>>>>>>>> +    },
>>>>>>>>          {}
>>>>>>>>      };
>>>>>>>>      MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);
>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
> 

Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Giovanni Gherdovich]

Hello Mario,

[moving Kyle to BCC, I hope it's OK]

in my last message I forgot to reply to the rest of your questions;
see below. In any event, next step for me is testing the latest bios,
as there seems to be an update.

On Wed Oct 7, 2026 16:56, Mario Limonciello wrote:
> 
> Can you please add more information about the vendor/model of the MB, etc?

right.

Motherboard is MSI, model is TRX40 PRO WIFI, CPU is AMD Ryzen Threadripper 3960X.
https://www.msi.com/Motherboard/TRX40-PRO-WIFI
Practically the same system as Kyle.

>> amd-pstate requires explicit knowledge of nominal frequency, so it
>> can't load on this hardware. The driver already has a mechanism (the
>> so-called "quirks") to accommodate for missing nominal freq in ACPI
>> tables, so here we use it to match against CPU family, model, core
>> count, and BIOS version.
> 
> Yeah; it's intended for this specific case of really old hardware that the BIOS isn't going to fix it.
> 
> I don't understand why core count matters though.

My thinking was:

1. I want to make the "quirk" to match as many chips as possible, to
    make it more useful and worthwhile.
2. The doc I have, "Power and Thermal Data Sheet" (publication #56736
    in the AMD doc library), is for family 0x17, models 0x30-0x3F
    processors.
3. Problem: these have different nominal frequencies, depending on the
    core count. Specifically:
    24 cores: 3800 MHz (like the Ryzen 3090x I need)
    32 cores: 3700 Mhz
    64 cores: 2900 MHz
4. Thus I decided to match for family 0x17, model 0x30-0x3f, 24 cores.
    Without the core count constraint, I couldn't tell which of the
    three nominal frequencies above should apply.

>> @@ -174,6 +179,22 @@ static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
>>       return 0;
>>   }
>> +static int __init dmi_matched_trx40_bios_bug(const struct dmi_system_id *dmi)
>> +{
>> +    /**
>> +     * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 socket / TRX40 chipset.
>> +     */
>> +    if (boot_cpu_data.x86 == 0x17 &&
>> +        boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x3F &&
>> +        topology_num_cores_per_package() == 24) {
> 
> Does the number of cores actually matter?  Do you mean to say if you swap the CPU to another part CPPC works?

No no. It was either wide matching (models 0x30-0x3f) but constraint
on #cores, or narrow matching for the exact CPU in my motherboard, (model 0x31).
Since I'm hard-coding data into the kernel, I figured wide matching
would make the quirk more applicable to potentially other affected
systems, hence more useful.

>> +        quirks = dmi->driver_data;
>> +        pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
> 
> The BIOS bug specifically is lack of values, not invalid values, right? Just want to make sure I'm following this right.

Correct, BIOS is lacking the values. That info message "Overriding"
is taken verbatim from the other "quirk" in the source, but strictly
speaking inaccurate. Values weren't there to begin with.

All that said, I've asked the openSUSE user to test the newer BIOS,
we'll see what that gives.


Thanks,
Giovanni

Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Mario Limonciello]

On 10/7/26 14:38, Giovanni Gherdovich wrote:
> Hello Mario,
> 
> [moving Kyle to BCC, I hope it's OK]
> 
> in my last message I forgot to reply to the rest of your questions;
> see below. In any event, next step for me is testing the latest bios,
> as there seems to be an update.
> 
> On Wed Oct 7, 2026 16:56, Mario Limonciello wrote:
>>
>> Can you please add more information about the vendor/model of the MB, 
>> etc?
> 
> right.
> 
> Motherboard is MSI, model is TRX40 PRO WIFI, CPU is AMD Ryzen 
> Threadripper 3960X.
> https://www.msi.com/Motherboard/TRX40-PRO-WIFI
> Practically the same system as Kyle.
> 
>>> amd-pstate requires explicit knowledge of nominal frequency, so it
>>> can't load on this hardware. The driver already has a mechanism (the
>>> so-called "quirks") to accommodate for missing nominal freq in ACPI
>>> tables, so here we use it to match against CPU family, model, core
>>> count, and BIOS version.
>>
>> Yeah; it's intended for this specific case of really old hardware that 
>> the BIOS isn't going to fix it.
>>
>> I don't understand why core count matters though.
> 
> My thinking was:
> 
> 1. I want to make the "quirk" to match as many chips as possible, to
>     make it more useful and worthwhile.
> 2. The doc I have, "Power and Thermal Data Sheet" (publication #56736
>     in the AMD doc library), is for family 0x17, models 0x30-0x3F
>     processors.
> 3. Problem: these have different nominal frequencies, depending on the
>     core count. Specifically:
>     24 cores: 3800 MHz (like the Ryzen 3090x I need)
>     32 cores: 3700 Mhz
>     64 cores: 2900 MHz
> 4. Thus I decided to match for family 0x17, model 0x30-0x3f, 24 cores.
>     Without the core count constraint, I couldn't tell which of the
>     three nominal frequencies above should apply.

If there does need to be a quirk I guess I would actually say there 
should be 3 quirks then. One for each core count version.>
>>> @@ -174,6 +179,22 @@ static int __init 
>>> dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
>>>       return 0;
>>>   }
>>> +static int __init dmi_matched_trx40_bios_bug(const struct 
>>> dmi_system_id *dmi)
>>> +{
>>> +    /**
>>> +     * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 
>>> socket / TRX40 chipset.
>>> +     */
>>> +    if (boot_cpu_data.x86 == 0x17 &&
>>> +        boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model 
>>> <= 0x3F &&
>>> +        topology_num_cores_per_package() == 24) {
>>
>> Does the number of cores actually matter?  Do you mean to say if you 
>> swap the CPU to another part CPPC works?
> 
> No no. It was either wide matching (models 0x30-0x3f) but constraint
> on #cores, or narrow matching for the exact CPU in my motherboard, 
> (model 0x31).
> Since I'm hard-coding data into the kernel, I figured wide matching
> would make the quirk more applicable to potentially other affected
> systems, hence more useful.
> 
>>> +        quirks = dmi->driver_data;
>>> +        pr_info("Overriding nominal and lowest frequencies for 
>>> %s\n", dmi->ident);
>>
>> The BIOS bug specifically is lack of values, not invalid values, 
>> right? Just want to make sure I'm following this right.
> 
> Correct, BIOS is lacking the values. That info message "Overriding"
> is taken verbatim from the other "quirk" in the source, but strictly
> speaking inaccurate. Values weren't there to begin with.
> 
> All that said, I've asked the openSUSE user to test the newer BIOS,
> we'll see what that gives.
> 
> 
> Thanks,
> Giovanni

Thanks!  Based on the findings from the BIOS update everything in this 
thread should be enough to either make a v2 incorporating feedback 
(mostly making it clearer) or to drop the patch.

Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Giovanni Gherdovich]

On Wed Oct 7, 2026 21:45, Mario Limonciello wrote:
> On 10/7/26 14:38, Giovanni Gherdovich wrote:
>> On Wed Oct 7, 2026 16:56, Mario Limonciello wrote:
>>> [...]
>>> I don't understand why core count matters though.
>>
>> My thinking was:
>>
>> 1. I want to make the "quirk" to match as many chips as possible, to
>>     make it more useful and worthwhile.
>> 2. The doc I have, "Power and Thermal Data Sheet" (publication #56736
>>     in the AMD doc library), is for family 0x17, models 0x30-0x3F
>>     processors.
>> 3. Problem: these have different nominal frequencies, depending on the
>>     core count. Specifically:
>>     24 cores: 3800 MHz (like the Ryzen 3090x I need)
>>     32 cores: 3700 Mhz
>>     64 cores: 2900 MHz
>> 4. Thus I decided to match for family 0x17, model 0x30-0x3f, 24 cores.
>>     Without the core count constraint, I couldn't tell which of the
>>     three nominal frequencies above should apply.
> 
> If there does need to be a quirk I guess I would actually say there
> should be 3 quirks then. One for each core count version.

Makes sense.

>> All that said, I've asked the openSUSE user to test the newer BIOS,
>> we'll see what that gives.
> 
> Thanks!  Based on the findings from the BIOS update everything in
> this thread should be enough to either make a v2 incorporating
> feedback (mostly making it clearer) or to drop the patch.

Yes I think so. Thanks a lot for your support so far.


Giovanni