I've been trying to find something about the use of pcc_cpufreq and how to load it but nothing so far.
I found this:

groucho@devuan:~$ sudo modprobe -c | grep -i pcc_cpufreq
alias acpi*:ACPI0007:* pcc_cpufreq
alias acpi*:LNXCPU:* pcc_cpufreq
groucho@devuan:~$ 

I don't get the whole alias idea but lsmod says this ...

groucho@devuan:~$ lsmod | grep -i _cpufreq
pcc_cpufreq            16384  0
acpi_cpufreq           24576  1
groucho@devuan:~$ 

Is it that loading pcc_cpufreq will always load acpi_cpufreq and not pcc_cpufreq?

The driver is a kernel module:

groucho@devuan:~$ grep -i _cpufreq /boot/config-4.19.0-16-amd64
CONFIG_X86_PCC_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ_CPB=y
groucho@devuan:~$ 

I've read that the pcc-cpufreq driver doesn't scale with > 4 CPUs and the ondemand governor.

But my Sun Ultra 24 box uses the Intel Core2 Q9550 processor which has just 4 CPUs and I am quite willing to dispense with the scaling if I can use the pcc-cpufreq driver to troubleshoot the shudown problem in my system.

Thanks in advance.

Best,

A.

I see.

No.
I didn't figure that one out.

A chap that posted on bugzilla.kernel.org told me.

He has two identical workstations.
One runs a proprietary OS called Unraid which is based on Slackware, the other plain Linux.

One of the workstations had the shutdown issue while the other (identical) runs Unraid and does not get the bad shutdowns.
The first WS BIOS has since been patched but the second one has not.

See https://bugzilla.kernel.org/show_bug.cgi?id=210689#c4.

Imagine me trying to get anything out of it.  8^7

Yes, I know.
But I forget, being accustomed to using cat and then grep from ages ago.

Eventually, I guess.

Thanks for your input.

Best,

A.

How did you determine that Slackware system uses pcc instead of acpi?

And btw:

Useless use of cat:

grep _cpufreq /proc/modules

This what is going on before blocking it:

groucho@devuan:~$ cpupower frequency-info # supplied by the linux-cpupower package
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us
  hardware limits: 2.00 GHz - 2.83 GHz
  available frequency steps:  2.83 GHz, 2.34 GHz, 2.00 GHz
  available cpufreq governors: ondemand performance schedutil
  current policy: frequency should be within 2.00 GHz and 2.83 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 2.03 GHz (asserted by call to kernel)
  boost state support:
    Supported: no
    Active: no
groucho@devuan:~$

This is the result:

groucho@devuan:~$ cpupower frequency-info # supplied by the linux-cpupower package
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  CPUs which run at the same hardware frequency: Not Available
  CPUs which need to have their frequency coordinated by software: Not Available
  maximum transition latency:  Cannot determine or is not supported.
Not Available
  available cpufreq governors: Not Available
  Unable to determine current policy
  current CPU frequency: Unable to call hardware
  current CPU frequency:  Unable to call to kernel
  boost state support:
    Supported: no
    Active: no
groucho@devuan:~$

But is would seem that if acpi_cpufreq is not loaded, pcc_cpufreq is not loade either:

groucho@devuan:~$ lsmod | grep -i cpu
groucho@devuan:~$ lsmod | grep -i freq
groucho@devuan:~$ lsmod | grep cpu
groucho@devuan:~$ lsmod | grep _cpufreq
groucho@devuan:~$

groucho@devuan:~$ cat /proc/modules | grep _cpufreq
groucho@devuan:~$ 

Thanks for your input.

Best,

A.

Is it possible to make the system use pcc_cpufreq instead of acpi_cpufreq?

You could try blocking the acpi_cpufreq module from the GRUB menu by pressing "e" with the Devuan entry highlighted then add this to the end of the line that starts with "linux":

module_blacklist=acpi_cpufreq

Then press <ctrl>+x (at the same time) to boot the modified entry and use this to check if pcc_cpufreq is being used:

cpupower frequency-info # supplied by the linux-cpupower package

If that works then either add the kernel parameter to GRUB_CMDLINE_LINUX in /etc/default/grub and run update-grub or use https://wiki.archlinux.org/index.php/Ke … probe.d/_2 to block it permanently.

Running up to date Devuan Beowulf 3.1.0:

groucho@devuan:~$ uname -a
Linux devuan 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
groucho@devuan:~$ 

My Sun Ultra 24 box has for the longes time had a persistent bad shutdown issue to which I have not been able to find a soluton, even by injecting a modified DSDT file at boot time.
It has been present across many Linux kernels and distributions.

See https://bugzilla.kernel.org/show_bug.cgi?id=201965

I have recently learned that this issue could be related to the cpu scaling driver.

It seems that a proprietary Slackware based OS which uses pcc_cpufreq instead of acpi_cpufreq does not show the problem when run on a workstation which, running another Linux distribution using acpi_cpufreq, does.

Although the WS is not a Sun U24 such as mine, the problem is exactly the same one, presenting the same symptoms.

See:
https://bugzilla.kernel.org/show_bug.cgi?id=199349#c4
https://lkml.org/lkml/2018/11/13/857.

Both modules are present in my installation, the one in use being acpi_cpufreq:

groucho@devuan:~$ lsmod | grep cpu
pcc_cpufreq            16384  0
acpi_cpufreq           24576  1
groucho@devuan:~$ 

groucho@devuan:~$ cat /proc/modules | grep _cpufreq
pcc_cpufreq 16384 0 - Live 0x0000000000000000
acpi_cpufreq 24576 1 - Live 0x0000000000000000
groucho@devuan:~$ 

Is it possible to make the system use pcc_cpufreq instead of acpi_cpufreq?
Testing without a module that seems to have issues could get me a solution. 

My CPU is a Core2 Q9550 - Yorkfield.

Thanks in advance,

A.