Project

General

Profile

Actions

Bug #11428

closed

CPU details are incorrect in the System Information widget after resetting log files

Added by Bearny B. 7 months ago. Updated 6 months ago.

Status:
Resolved
Priority:
Very Low
Assignee:
Category:
Dashboard
Target version:
Start date:
02/16/2021
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.5.0
Affected Architecture:
All

Description

Some CPU Type information disappear after reset the log files under Status.
This happen on VMWare with 2.5.0 RC and same happen on build computer.


Files

cpu1.JPG (21.4 KB) cpu1.JPG Befor RESET LOG FILES Bearny B., 02/16/2021 02:52 PM
cpu2.JPG (20.2 KB) cpu2.JPG After RESET LOG FILES Bearny B., 02/16/2021 02:52 PM
Actions #2

Updated by Jim Pingle 7 months ago

  • Subject changed from CPU Type, some information disappear on 2.5.0 RC to CPU core details disappear after resetting log files
  • Priority changed from Normal to Very Low
  • Target version changed from 2.6.0 to Future
  • Private changed from Yes to No

This is because the number of packages and cores is currently scraped from /var/log/dmesg.boot, and when you reset all log files, that file gets reset since it's also a log file.

There doesn't appear to be any way to get the equivalent information out of sysctl (e.g. under kern.smp.*), since that seems to only count the total number of cores and not the number of physical CPUs ("packages"). We can't rely on it being in the kernel message buffer either since that gets cycled out as new messages come in.

It's cosmetic only and only affects the rare occasion someone resets log files, so given the very low impact and lack of easy workaround, I don't see it being worth dedicating a lot of resources to fix. If someone happens to come up with a viable workaround, feel free to submit a PR.

Actions #3

Updated by Bearny B. 7 months ago

Jim Pingle wrote:

This is because the number of packages and cores is currently scraped from /var/log/dmesg.boot, and when you reset all log files, that file gets reset since it's also a log file.

There doesn't appear to be any way to get the equivalent information out of sysctl (e.g. under kern.smp.*), since that seems to only count the total number of cores and not the number of physical CPUs ("packages"). We can't rely on it being in the kernel message buffer either since that gets cycled out as new messages come in.

It's cosmetic only and only affects the rare occasion someone resets log files, so given the very low impact and lack of easy workaround, I don't see it being worth dedicating a lot of resources to fix. If someone happens to come up with a viable workaround, feel free to submit a PR.

Hi Jim,

Okay, thanks for the information. It didn't happen with previous pfSense versions so that's why I report it :)
But, what about AES-NI CPU Crypto: Yes (active) change to AES-NI CPU Crypto: NO after RESET LOG FILES. I do have Intel CPU that supports AES and I use couple of OpenVPN too. :)

Actions #4

Updated by Jim Pingle 7 months ago

Same issue with finding the CPU flags to see what the CPU supports.

On older versions, dmesg.boot wasn't cleared, but also on older versions there wasn't a log tab for dmesg.boot and there is now (Status > System Logs, System tab, OS Boot sub-tab).

Actions #5

Updated by Steve Yates 7 months ago

Would it work to just copy the file to dmesg.boot.current or whatever, after each boot, and then parse that? It should always be small (?) and dmesg.boot could be rotated on demand.

e.g. cron:
@reboot sleep 120 && cp /var/log/dmesg.boot /var/log/dmesg.boot.current

Actions #6

Updated by Jim Pingle 7 months ago

The dmesg.boot file is the copy of the kernel message buffer for that purpose.

Resetting log files should not be necessary on 2.5.0/21.02 and forward often enough for this to be a concern.

People may have been in the habit of doing it for various reasons on old versions with clog (like changing log sizes/options) but that isn't necessary anymore.

Actions #7

Updated by Viktor Gurov 7 months ago

Jim Pingle wrote:

The dmesg.boot file is the copy of the kernel message buffer for that purpose.

Resetting log files should not be necessary on 2.5.0/21.02 and forward often enough for this to be a concern.

People still need to reset log files in some cases (e.g. clearing history)

keep dmesg.boot on log reset, as it is the copy of the kernel message buffer, and not a log file:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/173

Actions #8

Updated by Jim Pingle 7 months ago

  • Status changed from New to Pull Request Review
  • Target version changed from Future to CE-Next
Actions #9

Updated by Jim Pingle 7 months ago

  • Target version changed from CE-Next to 2.5.1
Actions #10

Updated by Renato Botelho 7 months ago

  • Status changed from Pull Request Review to Waiting on Merge
  • Assignee set to Viktor Gurov

PR has been merged. Thanks!

Actions #11

Updated by Viktor Gurov 7 months ago

  • Status changed from Waiting on Merge to Feedback
  • % Done changed from 0 to 100
Actions #12

Updated by Jim Pingle 7 months ago

To test:

On a system without the fix:

  • Check System Information Widget on the Dashboard for "AES-NI CPU Crypto: Yes"
  • Reset all log files from Status > System Logs, Settings tab
  • View the OS Boot log at Status > System Logs, System, OS Boot. It will be empty.
  • Check System Information Widget on the Dashboard and it now displays "AES-NI CPU Crypto: No"
  • Reboot and check the widget again, and the expected value has returned.

Repeat the test again on a snapshot with the fix and resetting the log files will not change the dashboard output nor will it clear the OS boot log.

Actions #13

Updated by Renato Botelho 7 months ago

Cherry-picked to RELENG_2_5_1

Actions #14

Updated by Jim Pingle 7 months ago

  • Subject changed from CPU core details disappear after resetting log files to CPU details are incorrect in the System Information widget after resetting log files

Updating subject for release notes.

Actions #15

Updated by Bearny B. 6 months ago

Bearny B. wrote:

Some CPU Type information disappear after reset the log files under Status.
This happen on VMWare with 2.5.0 RC and same happen on build computer.

Jim Pingle wrote:

Updating subject for release notes.

It has been fixed in 2.5.1 RC (latest snapshot) and 2.6.0 DEV (latest snapshot)

Actions #16

Updated by Renato Botelho 6 months ago

  • Status changed from Feedback to Resolved
Actions #17

Updated by Michael Spears 6 months ago

Bearny B. wrote:

Bearny B. wrote:

Some CPU Type information disappear after reset the log files under Status.
This happen on VMWare with 2.5.0 RC and same happen on build computer.

Jim Pingle wrote:

Updating subject for release notes.

It has been fixed in 2.5.1 RC (latest snapshot) and 2.6.0 DEV (latest snapshot)

Tested on 21.02.2-RC (amd64) built on Thu Apr 01 11:53:58 EDT 2021, fix confirmed.

Actions

Also available in: Atom PDF