PFSense on a DEC3840 (Netboard A20)
-
This post is deleted! -
@stephenw10 here is some of the code changes that he was referring to:
"To make sure the OS can find the serial port, you need to remove some pre production acpi hack, this https://github.com/freebsd/freebsd-src/commit/35af9331 should do the trick.
The 10gbps network card needs a driver, which AMD upstreams to https://github.com/freebsd/freebsd-src/tree/main/sys/dev/axgbe, we do have some additional bug fixes which will likely land later on (you can find them now in our repo, https://github.com/opnsense/src)"
can these changes be applied via a module or does it need to be applied in the kernel itself?
-
Ok, that is in 2.6 so the first thing to do there is just try a 2.6 snapshot:
https://github.com/pfsense/FreeBSD-src/commit/a7c68340584c942792188ad50593d4ef15cc8982#diff-96de3fc05e938f0fd1d95debb8e797e7c1da4645867d1722e01b1eff85e17186Steve
-
@stephenw10 the most recent snapshot of 2.6 stalls at the spot below:
-
So slightly further?
-
-
@stephenw10 support from Decisio metioned the following as well:
"Try to add the following to loader.conf.local hw.uart.console="io:0x3f8,br:115200" "
Would this get added to the loader.conf.local after install on a donor system? or can it be done pre-install?
-
You could set that at the loader prompt before it boots.
OK> set hw.uart.console="io:0x3f8,br:115200" OK> bootYou could add it to loader.conf.local on the other system before moving is across.
That was the only line we saw which looked like it could be doing anything so it's certainly worth trying. Those are the default com1 values though.
Having read through the commits it might be setting it back to the default values after the detection quirks that were added for earlier EPYC systems were interfering.Steve
-
@stephenw10 that did the trick!! Thanks alot man!!
So the loader.conf.local file wouldn't be removed or changed during updates or anything right?
-
Ah, nice. Interesting that does anything.
Yes, that will be retained across updates.
Steve
-
@stephenw10 One more thing, the cpu is being detected in PFSense as 2 cache groups x2cores. could this cause any performance impact? and is there a way to define what type of cores they are?
-
That's just how the CPU/BIOS reports it. I wouldn't expect it to make any difference.
More concerning is the fact it shows as running at 1200MHz. Does it ever rise from that?
You might need to enable powerd if you haven't already. Assuming there is a driver to support switching it.
Steve
-
@stephenw10 Yea that was my other concern, it does not. If i disable PowerD, running " sysctl dev.cpu.0.freq " shows 2100. But with PowerD it stays at 1200 and that's with running multiple speed tests at gigabit over wireguard and not.
So i have disabled PowerD for now as the CPU temp is pretty steady at about 115 Fahrenheit.
-
Hmm, well if it changes when you enable it that shows it can set the frequency.
What profile did you use? Hi-Adaptive is usually the best to use.
It doesn't make a huge amount of difference to power consumption on modern CPUs anyway though.Steve
-
@stephenw10 I tried it Hi-Adaptive and Maximum, both stayed at 1200.
-
Hmm, I mean there is a possibility that CPU loading never gets high enough to start ramping up. Or that it's not detecting the loading correctly.
Try running:
sysctl -a | grep freqSo you see cpu frequency levels shown?
If so you can try killing powerd and setting the level manually.
Steve
-
@stephenw10 it returns the following:
Would the command to set it manually be " set dev.cpu.0.freq_levels=2100/1890" ?
[2.6.0-DEVELOPMENT][root@core.sycamore]/root: sysctl -a | grep freq kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.TSC.frequency: 2096114517 kern.ntp_pll.time_freq: 85052405328768 kern.ntp_pll.pps_freq: 89169788928000 device cpufreq kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.LAPIC.frequency: 49907470 kern.acct_chkfreq: 15 net.inet.sctp.sack_freq: 2 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 debug.uart_poll_freq: 50 machdep.tsc_freq: 2096114517 machdep.i8254_freq: 1193182 machdep.acpi_timer_freq: 3579545 dev.cpufreq.0.%parent: cpu0 dev.cpufreq.0.%pnpinfo: dev.cpufreq.0.%location: dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%desc: dev.cpufreq.%parent: dev.hwpstate.0.freq_settings: 2100/1890 1700/1445 1200/990 dev.cpu.0.freq_levels: 2100/1890 1700/1445 1200/990 dev.cpu.0.freq: 2100 -
Ah, OK. Looks like it's working.
Kill the powerd process then:
sysctl dev.cpu.0.freq=1700Or whichever speed you want.
The second number there is meant to be power consumption in mW. But I've always found it to be somewhat random!Steve
-
@stephenw10 that command did change the freq in the console:
-
Then maybe your test simply didn't load up the CPU enough.
