Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefer max CPU frequency from /sys over DMI info #102

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bitfehler
Copy link

Currently, the first module to set the max CPU frequency (capacity) is dmi. The cpufreq module only overwrites this value if it determined a value greater than the one from DMI.

However, as the dmidecode man page [1] states:

More often than not, information contained in the DMI tables is
inaccurate, incomplete or simply wrong.

[1] https://linux.die.net/man/8/dmidecode

I can attest to that, insofar as many of the servers I manage report a hugely exaggerated max frequency in the DMI data, whereas the sysfs data from the cpufreq module is always correct.

With the current approach of only overwriting the value if it is greater than the one from DMI, these exaggerated values show up in the final output of lshw.

This commit always prefers the max CPU frequency value from the cpufreq module, unless it is 0 (i.e. failed to determine).

Currently, the first module to set the max CPU frequency (capacity) is
`dmi`. The `cpufreq` module only overwrites this value if it determined
a value greater than the one from DMI.

However, as the dmidecode man page [1] states:

> More often than not, information contained in the DMI tables is
> inaccurate, incomplete or simply wrong.

[1] https://linux.die.net/man/8/dmidecode

I can attest to that, insofar as many of the servers I manage report
a hugely exaggerated max frequency in the DMI data, whereas the sysfs
data from the `cpufreq` module is always correct.

With the current approach of only overwriting the value if it is greater
than the one from DMI, these exaggerated values show up in the final
output of `lshw`.

This commit always prefers the max CPU frequency value from the
`cpufreq` module, unless it is `0` (i.e. failed to determine).

Signed-off-by: Conrad Hoffmann <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant