Project

General

Profile

Bug #11428

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

Added by Bearny B. about 2 months ago. Updated 14 days ago.

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

100%

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

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.

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

Associated revisions

Revision f3fd77ee (diff)
Added by Viktor Gurov about 1 month ago

Do not clean dmesg.boot on Reset Log Files. Fixes #11428

Revision 035e7029 (diff)
Added by Viktor Gurov about 1 month ago

Do not clean dmesg.boot on Reset Log Files. Fixes #11428

(cherry picked from commit f3fd77ee3cbb6e547b6154d13eab5019f36025d6)

History

#2 Updated by Jim Pingle about 2 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.

#3 Updated by Bearny B. about 2 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. :)

#4 Updated by Jim Pingle about 2 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).

#5 Updated by Steve Yates about 1 month 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

#6 Updated by Jim Pingle about 1 month 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.

#7 Updated by Viktor Gurov about 1 month 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

#8 Updated by Jim Pingle about 1 month ago

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

#9 Updated by Jim Pingle about 1 month ago

  • Target version changed from CE-Next to 2.5.1

#10 Updated by Renato Botelho about 1 month ago

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

PR has been merged. Thanks!

#11 Updated by Viktor Gurov about 1 month ago

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

#12 Updated by Jim Pingle about 1 month 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.

#13 Updated by Renato Botelho about 1 month ago

Cherry-picked to RELENG_2_5_1

#14 Updated by Jim Pingle about 1 month 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.

#15 Updated by Bearny B. 24 days 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)

#16 Updated by Renato Botelho 24 days ago

  • Status changed from Feedback to Resolved

#17 Updated by Michael Spears 14 days 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.

Also available in: Atom PDF