Is someone going to do something about this? It’s still broken, though the i386 
build errors are stacking up (I just took it down from 3 known issues to 2, at 
least…). If the code is going to exist in the repo then we need to do better at 
actually making sure it builds, and so I might make the controversial 
suggestion that, so long as i386 kernel sources exist in main and are supported 
in at least one stable branch, we should have at least one kernel config that’s 
part of the default universe build, so we actually test the code rather than 
finding out it’s broken when a user reports it or it gets MFCed. This state of 
affairs doesn’t save effort, it just defers it, and if anything makes it worse 
because people have to diagnose the error, rather than it just be fixed from 
the start by the original author.

Jessica

> On 27 Jun 2026, at 16:23, Adrian Chadd <[email protected]> wrote:
> 
> please create a review for this? It sounds like they should've wrapped
> it if #ifdef amd64 or something
> 
> -a
> 
> On Sat, 27 Jun 2026 at 07:19, Harry Schmalzbauer <[email protected]> wrote:
>> 
>> On 2026-06-02 08:42, ShengYi Hung wrote:
>>> The branch main has been updated by aokblast:
>>> 
>>> URL: 
>>> https://cgit.FreeBSD.org/src/commit/?id=7b26353a59d66dc1bc611fd042a49b9e3bd13699
>>> 
>>> commit 7b26353a59d66dc1bc611fd042a49b9e3bd13699
>>> Author:     ShengYi Hung <[email protected]>
>>> AuthorDate: 2026-06-01 09:46:37 +0000
>>> Commit:     ShengYi Hung <[email protected]>
>>> CommitDate: 2026-06-02 06:41:41 +0000
>>> 
>>>     hwpstate_intel: Disable package control on hybrid CPU
>>> 
>>>     In package control mode, the performance of all cores depends on the
>>>     most recent value written to the request field. If the last write comes
>>>     from an E-core, all cores are forced to align with the E-core
>>>     performance level, resulting in significant performance degradation.
>>>     Therefore, package control is disabled on hybrid-core systems.
>>> 
>>>     Reviewed by:    olce
>>>     MFC after:      2 weeks
>>>     Sponsored by:   The FreeBSD Foundation
>>>     Sponsored by:   Framework Computer Inc
>>>     Differential Revision: https://reviews.freebsd.org/D57377
>>> ---
>>>  sys/x86/cpufreq/hwpstate_intel.c | 21 +++++++++++++++++++++
>> 
>> 
>> In lieu of a proper fix, due to lacking skills, I'm working around i386
>> incompatibility with this diff:
>> 
>> diff --git a/sys/x86/cpufreq/hwpstate_intel.c
>> b/sys/x86/cpufreq/hwpstate_intel.c
>> index db8600d7b89a..b9b68f1b14d0 100644
>> --- a/sys/x86/cpufreq/hwpstate_intel.c
>> +++ b/sys/x86/cpufreq/hwpstate_intel.c
>> @@ -321,6 +321,7 @@ sysctl_epp_select(SYSCTL_HANDLER_ARGS)
>>         return (ret);
>>  }
>> 
>> +#ifndef __i386__
>>  static void
>>  intel_hwpstate_hybrid_cb(void *ctx)
>>  {
>> @@ -328,11 +329,14 @@ intel_hwpstate_hybrid_cb(void *ctx)
>> 
>>         atomic_add_32(small_cores, PCPU_GET(small_core));
>>  }
>> +#endif
>> 
>>  void
>>  intel_hwpstate_identify(driver_t *driver, device_t parent)
>>  {
>> +#ifndef __i386__
>>         uint32_t small_cores = 0;
>> +#endif
>> 
>>         if (device_find_child(parent, "hwpstate_intel",
>> DEVICE_UNIT_ANY) != NULL)
>>                 return;
>> @@ -353,6 +357,7 @@ intel_hwpstate_identify(driver_t *driver, device_t
>> parent)
>>         if ((cpu_power_eax & CPUTPM1_HWP) == 0)
>>                 return;
>> 
>> +#ifndef __i386__
>>         /*
>>          * On hybrid-core systems, package-level control cannot be used.
>>          * It may cause all cores to run at the E-core frequency because
>> @@ -363,6 +368,7 @@ intel_hwpstate_identify(driver_t *driver, device_t
>> parent)
>>             intel_hwpstate_hybrid_cb, smp_no_rendezvous_barrier,
>> &small_cores);
>>         if (small_cores > 0 && small_cores < mp_ncores)
>>                 hwpstate_pkg_ctrl_enable = false;
>> +#endif
>> 
>>         if (BUS_ADD_CHILD(parent, 10, "hwpstate_intel",
>> device_get_unit(parent))
>>             == NULL)
>> 
>> I know i386 is not supported anymore.
>> Just in case anybody else wants to keep i368-stable/15 for bhyve guests
>> for example, where cpufreq(4) isn't attaching anyways.
>> 
>> Thanks,
>> 
>> -harry
>> 
>> 
> 

Reply via email to