Watchguard XTM 5 Series
-
Just supported by the chipset. None of the BIOS mods went that deep.
-
@Xerox I can't remember if the system was picky about the RAM modules, but I think I just used some out of the PC I pulled the CPU out of.
Also to note, I apparently have a slightly different version that has all the needed connections for dual hard drives. Had to hack a plastic 3.5" to dual 2.5" adapter to fit them inside. Don't recall if I ever added pictures of that to this thread or not, but pretty sure my serial port mod is here. -
@mcdonnjd RAM choice is very picky. For Intel CPU generation of this era, the only RAM that will allow 8Gb is called High Density. It appears to be quite rare and expensive if it does appear on fleabay. Watch out for the RAM advertised as High Density but is specific to AMD CPU, this wont work. I've not been able to find some that Im willing to pay for. Last I found, the seller wanted 100€ for it and its not worth that any more IMO. 4Gb has always been plenty for me
-
@CodeJACK Hmmm... Maybe it didn't come out of the PC the CPU came from then. Pretty sure the CPU came from one of our HP office machines and I doubt they had anything special. I'd have to check the shelf at work to see if I still have any of it. Think I did have some extra that I kept on the shelf, but I don't remember as it's been many years since I did this and I think I've finally gotten rid of the DDR2. (I probably documented what RAM I used earlier in the thread, but probably not where I scavenged it from.)
-
Hi all ,
I am attempting to rebuild the coretemp.ko module to fix the issue with Xeons and wrong temperatures.
I have run into a problem. How do I fix this error message?
KLD coretemp2.ko: depends on kernel - not available or version mismatch
linker_load_file: ./coretemp2.ko - unsupported file typeI downloaded and built it again FreeBSD 14 Alpha 3
How do I proceed?
Thanks
-
Kernel modules usually require the exact kernel to load against (or very close to it). Does the module load against your build box?
You will need either the actual pfSense kernel source or a closer FreeBSD version.
-
@stephenw10 said in Watchguard XTM 5 Series:
Kernel modules usually require the exact kernel to load against (or very close to it). Does the module load against your build box?
You will need either the actual pfSense kernel source or a closer FreeBSD version.
Where can I get Freebsd 14 Current?
I cannot find any iso images as 14 has not yet been released.
-
Alpha3 is the 14 current version: https://download.freebsd.org/snapshots/ISO-IMAGES/14.0/
Which pfSense version are you using? 2.7 is built on an older FreeBSD 14 version.
-
@stephenw10 said in Watchguard XTM 5 Series:
Alpha3 is the 14 current version: https://download.freebsd.org/snapshots/ISO-IMAGES/14.0/
Which pfSense version are you using? 2.7 is built on an older FreeBSD 14 version.
Using 2.7
What version of FreeBsd 14 is is built against?
-
Looks like the last merge to the FreeBSD src was Mar 30th: https://github.com/pfsense/FreeBSD-src/commits/RELENG_2_7_0
But really I would expect to need to build against the pfSense 2.7 src for this. Better to post in development.
-
Hi, I am trying to find some information about ACPI and AML to be able to generate this for the CPU I've put in (Xeon L5420) but since there's over 1000 post here I'm not finding this easy! How would one go about finding the data that goes in to this file so it can be correctly generated?
Right I see you basically have to boot and test out various values to see if they work and the system is stable, sounds like a fun weekend project...
-
So I created the file, built it into the BIOS, flashed it, linux seems to think it works (cpupower) but pfsense shows:
est0: failed to enable SpeedStep est1: failed to enable SpeedStep est2: failed to enable SpeedStep est3: failed to enable SpeedStep
I've also tried copying the .aml to the device and loading it in /boot/loader.conf.local and get the same error, any way to debug this further?
-
Yup, pretty much! Some CPUs seem very difficult to find any 'official' values for. Best guesses seem to work. Mostly.
The ones I did I started with something that was close and added or modified the P state definitions. IIRC there were some ACPI errors/warnings the compiler threw put I was able to correct too.
-
Is Speedstep enabled in the BIOS? It's disabled by default IIRC
-
@stephenw10 I get 5 warnings, 48 remarks, the only ones relating to processor are to use device() instead - which I haven't done, assuming that the legacy processor() one is still OK. I do not have a speedstep option in BIOS, I did look around for one but didn't see anything, this is what I have in the CPU menu:
-
Hmm, you can use cpuctl to read the CPU register directly once it's booted. Been a while since I've tried that.
Normally if Speedstep is disabled though est shows it's unable to attach. Hmm.
-
@stephenw10 cpuctl doesn't seem to be a default installed package
I have tried loading the default unlocked BIOS and comparing it with my modified BIOS in linux, with the default one cpupower gets nothing, with my modified one it gets the values I put in and seemingly it can change the frequency, it just appears to be pfsense that can't for some reason
-
cpuctl is a kernel module, the actual command is
cpucontrol
[2.7.0-RELEASE][admin@t70.stevew.lan]/root: kldstat Id Refs Address Size Name 1 45 0xffffffff80200000 339d810 kernel 2 1 0xffffffff8359e000 5ba0d8 zfs.ko 3 1 0xffffffff83b5a000 76f8 cryptodev.ko 4 1 0xffffffff84120000 2220 cpuctl.ko 5 1 0xffffffff84123000 3248 ichsmb.ko 6 1 0xffffffff84127000 2178 smbus.ko 7 1 0xffffffff8412a000 5ee0 ig4.ko 8 1 0xffffffff84130000 9288 aesni.ko 9 1 0xffffffff8413a000 20e8 coretemp.ko 10 1 0xffffffff8413d000 13808 dummynet.ko [2.7.0-RELEASE][admin@t70.stevew.lan]/root: cpucontrol Usage: cpucontrol [-vh] [-d datadir] [-m msr[=value] | -i level | -i level,level_type | -e | -u] device
-
I don't recall exactly which bit it is but you can read the MSR contaning it to check as shown here: https://forum.netgate.com/post/338671
-
@stephenw10 Doing that I get:
MSR 0x198: 0x47174717 0x06004717
Which is the top speed I have in my DSDT:
Name (_PSS, Package (0x04) // Performance Supported States { // Values below for Intel Xeon L5420 Package (0x06) { 2500, // f in MHz 50000, // P in mW 10, // Transition latency in us 10, // Bus Master latency in us 0x00004717, // value written to PERF_CTL; fid=71 (0x47), vid=23 (0x17) 0x00004717 // value of PERF_STATE after successful transition; fid=71 (0x47), vid=23 (0x17) }, Package (0x06) { 2333, // f in MHz 45800, // P in mW 10, // Transition latency in us 10, // Bus Master latency in us 0x00000715, // value written to PERF_CTL; fid=0x07, vid=0x15 0x00000715 // value of PERF_STATE after successful transition; fid=0x07, vid=0x15 }, ...
Not sure which register the lock bit would be in (or where a list of registers are)
When I was trying c2ctl on linux, I was getting this:
Current Target Min. Max. FID: 71 10 71 71 VID: 23 30 23 23 ESIT_ENABLE = FALSE ESIT_LOCK = TRUE
Which was prior to having inserted the dsdt, does this mean that speedstep is locked and can't be used?