23.01 CPU Type System Info dashboard

[jrey]

Device Netgate 2100, all patched

I've noticed that immediately after a reboot the CPU Type information is complete.

But the longer the system runs (over days) the less information it displays.
Sometimes it will drop the CPU 0 line, other times CPU 1. (will randomly flip between the two)
eventually (again over a period of days) it will end up like this

Once it gets to this point the only thing that seems to bring the CPU detail lines back to the display is a reboot.

no errors, system seems to be running fine otherwise, just strange.
the command - (dmesg | grep -i cpu) always seems to return the correct lines

Starting CPU 1 (1)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpulist0: <Open Firmware CPU Group> on ofwbus0
cpu0: <Open Firmware CPU> on cpulist0
cpu1: <Open Firmware CPU> on cpulist0
e6000sw0: CPU port at 5
CPU 0: ARM Cortex-A53 r0p4 affinity: 0
CPU 1: ARM Cortex-A53 r0p4 affinity: 1

Not likely browser issue as other devices with different browsers will display the same at any given point in time.

Not a huge problem, just curious what else I might look at?
Logs I have checked are clear.

Thanks in advance.

[stephenw10]

Hmm, hard to see how that could happen. The code that is run to generate that simply looks at the boot output for those lines as you say:

				if (in_array($platform['name'], ['1100', '2100'])): ?>
					:<br />
<?php
					exec("dmesg | grep CPU | grep ARM", $cpus);
					foreach($cpus as $cpu) {
						echo "$cpu<br>";
					}
				endif; ?>

[23.01-RELEASE][admin@2100-3.stevew.lan]/root: dmesg | grep CPU | grep ARM
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
CPU  1: ARM Cortex-A53 r0p4 affinity:  1

As long as they are in the buffer still they should show. It would be unlikely lose only one line.

However it does seem entirely possible the message buffer would lose that data on a busy system. That code should probably be looking at dmesg.boot.

[23.05-DEVELOPMENT][root@2100-2.stevew.lan]/root: dmesg | grep CPU | grep ARM
[23.05-DEVELOPMENT][root@2100-2.stevew.lan]/root: grep CPU /var/log/dmesg.boot | grep ARM
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
CPU  1: ARM Cortex-A53 r0p4 affinity:  1

Steve

[stephenw10]

https://redmine.pfsense.org/issues/14204

[jrey]

@stephenw10

Certainly wouldn't think the system is that busy, looking at historical memory, cpu etc.

What if the in_array is no longer returning true ? That would certainly cause the lines to be missing.

Since the lines are still returned by a manual dmesg when they are not displayed on the widget it would be more suggestive of the if statement.

i may add a couple of extra display "debug" lines just to see what is displayed for the "name" in the array, where it is actually going.
It's not something I watch, but occasionally I expand the system info to see if everything looks sane and notice those lines are gone. and now just curious.

JR

[stephenw10]

@jrey said in 23.01 CPU Type System Info dashboard:

What if the in_array is no longer returning true ? That would certainly cause the lines to be missing.

Yes. But it would always be both line though.

[jrey]

@stephenw10

I wonder. Can't say for certain as I wasn't at the dashboard during this time.

But prior to these time stamps, both lines displayed.
status.txt
when dashboard observed later they are not. Made me look.

(Static IP - so not the ISP cycling or anything like that
not PPPoE
No switching of devices to UPS, so not a power issue here
Wouldn't have even known that WAN seems to have bounced

Only thing in there that stands out is the reloading filter within a 2 second time frame. No other events logged anywhere that stand out

I rebooted after noticing this and display is "normal"

could the rapid filter reloading be causing something to corrupt/crash?

I've noticed that since upgrading to 23.01 there does seem to be more of these alarms on the WANGW being recorded. Upload in particular seems more challenged. going forward I'll try to keep track of gateway alarms vs. filter reloading and perhaps the dashboard issue when observed. It might be nothing, just another observation.

Thanks

[stephenw10]

Hmm, I could imagine very high loading might cause the command to not respond at all.

But simply bouncing the WAN would not do that.