Watchguard XTM 5 Series
-
Argh!
I finally got pfSense working on my XTM 535 with Dual Core E5300 / 4GB RAM. Took me forever to figure out how to unlock my own BIOS, get it booting from USB and installed via SSD. Had a ton of issues with the CF card. Now I read your post about AES-NI.
I am disappoint :-[
-
Think about how much you learned along the way though. ;)
You're still good for some time to come anyway as I said.
Steve
-
Argh!
I finally got pfSense working on my XTM 535 with Dual Core E5300 / 4GB RAM. Took me forever to figure out how to unlock my own BIOS, get it booting from USB and installed via SSD. Had a ton of issues with the CF card. Now I read your post about AES-NI.
I am disappoint :-[
[/quote]I wouldn't be disappointed. Still plenty of time left. In my case I am still just tweaking my first XTM box and I have a second backup box on the way. I also have a Q9505s CPU on the way. It will be weeks before it's all configured and operational.
For me going with XTM 5 was a calculated decision since I was aware of the upcoming AES-NI limitation. So I also investigated alternatives to pfSense in order to avoid retiring the hardware prematurely.
Changing the subject, is anyone with a handy SPI programmer willing to insert the two ASCII sequences (unit serial number & the second sequence) into a modified BIOS to confirm if the unit accepts such hybrid BIOS and recognized the serial number?
-
Not sure what you're asking there. You want to change the unit's serial number?
I don't think that is stored in the BIOS. Changing the serial also seems morally dubious at best! ??? Maybe I'm misunderstanding…
Steve
-
Hi Steve,
Several posts earlier I highlighted a few of the discoveries I made when tinkering with my XTM 5 box. One of those discoveries was that the original unit BIOS has the serial number stored in null terminated plain ASCII at offset 0x0000h in the BIOS. Likewise offset 0x0100h in the original BIOS has a null terminated ASCII string that corresponds to the barcode label on my unit that is placed immediately to the left of the power switch (the barcode correlation was highlighted to me by DeLorean). Both of those strings are wiped out when the BIOS is edited with the AMI tools. This is the reason why people with edited BIOS cannot get the original firmware to recognize the unit serial number…
All I was suggesting is that someone who cares about the original firmware can try to re-insert those strings manually into their edited / unlocked BIOS to see if it fixes the issue. I have no idea if these strings are used by the BIOS to calculate the checksum. I am myself not that adventurous because (1) I will never need to run the original WatchGuard firmware and (2) I don't have an SPI programmer in case the unit is "bricked".
Cheers.
Not sure what you're asking there. You want to change the unit's serial number?
I don't think that is stored in the BIOS. Changing the serial also seems morally dubious at best! ??? Maybe I'm misunderstanding…
Steve
-
Ah, sorry I've clearly not been paying attention. ::)
That's interesting from an academic point of view. Raises some questions.
However I must ask that any such discussion is taken off the public forum. Whilst you and I might have no need to use that for subversive reasons there will be others who try it, unfortunately.
Were you ever able to enable EIST (speedstep) successfully in your BIOS?
It's been so long since I tried it I forget exactly what success I had there. I do recall having to make several changes to set the MSR bit correctly after boot though.Thanks,
Steve -
Stephen what box have you switched to or are you still using an XTM?
-
Well you can probably imagine I have a whole host of boxes. Some might say too many! ::)
I still have the XTM5 and I use it for testing snapshots and packages etc all the time. Also useful as source or sink in throughput testing something else. I'm running an E8400 in it now. Runs solid.
I'd still love to get Speedstep working properly but finding the time to dig deep enough is difficult.I still run an X-Core-E box but it flakes out about once a week now. Just too many old components in it.
Steve
-
Has not even occurred to me since the two strings were just so obvious at the beginning of the file when viewed with a hex editor. Feel free to redact my posts.
I have not touched speedstep at all. It would require a lot of learning on my part first and I suffer from a very chronic lack of time. It would be awesome if someone got it to work correctly though.
Ah, sorry I've clearly not been paying attention. ::)
That's interesting from an academic point of view. Raises some questions.
However I must ask that any such discussion is taken off the public forum. Whilst you and I might have no need to use that for subversive reasons there will be others who try it, unfortunately.
Were you ever able to enable EIST (speedstep) successfully in your BIOS?
It's been so long since I tried it I forget exactly what success I had there. I do recall having to make several changes to set the MSR bit correctly after boot though.Thanks,
Steve -
I can now also report that the Q9505s CPU is working beautifully in my unit, but of course sans speedstep.
-
What's really annoying is that I did once have it sort of working. I had to override the DSDT table with one I had added P-state values to though.
Problem is it's so long ago now I can't remember exactly what I did. ::)
https://forum.pfsense.org/index.php?topic=43574.msg265760#msg265760
Steve
-
Greetings folks,
I am a long time tomato user preparing to move to pfsense. I recently picked up an XTM 525 via craigslist and added a SATA SSD. The installation went smoothly other than a minor hiccup with the characters not displaying properly on my terminal.
Unfortunately, the unit is a bit too noisy for my home despite using WGXepc64 for slowing down the fans. The noise appears to be originating from the CPU fan(s), which I understand are controlled by the bios. Unlike the bios in other systems, this unit 's bios is dated 4/26/2010.
I'd appreciate suggestions on how to get the bios unlocked/CPU fans silenced.
Thank You -
Your options are limited unfortunately, unless you have coding skills and time. ;)
The system fan is (relatively) easily adjustable but the CPU fans are controlled by a different chip that is only accessible via smbus and hence far more complex to access. Though by no means impossible.
You could swap out the fans. You could fit in line speed reducers/controllers.
Be aware that any of those options will reduce air-flow increasing temperatures inside the case and potentially reducing component life. You have been warned etc…. ;)
Steve
-
Thanks Stephenw10, I'll start looking into replacement fans. Unfortunately I have a feeling that I might be putting the XTM525 on sale and installing pfsense on a Dell T30 server.
Thanks once again -
I started tinkering with this a little bit and have a question. Have you essentially extracted and "disassembled" the DSDT using the Intel iasl compiler, then edited it to include the new P-states, then re-compiled and re-inserted into the BIOS? I am doing all of my tinkering from Arch Linux so overriding the BIOS supplied DSDT at boot time for testing purposes would be quite easy…
I also loaded Windows 7 onto the box and I got really weird results while testing Speedstep: CPU-Z shows the multiplier changing dynamically between 6.0x and 8.5x on my Q9505s CPU, but at exactly the same time HWiNFO64 shows the multiplier fixed at 8.5x and voltage fixed at 1.2V.
It all seems to work consistently on my "PC" which is an Asus P5KE, despite that board not officially supporting the Q9505s. I pulled and disassembled the DSDT from the P5K to see how it dynamically detects the CPU power states, as opposed to hard coding the table specific to one CPU only...
What's really annoying is that I did once have it sort of working. I had to override the DSDT table with one I had added P-state values to though.
Problem is it's so long ago now I can't remember exactly what I did. ::)
https://forum.pfsense.org/index.php?topic=43574.msg265760#msg265760
Steve
-
You can include a different DSDT table at boot in FreeBSD too so I did not need to insert it into the BIOS. But other than that, yeah.
@https://www.freebsd.org/cgi/man.cgi?query=acpi&apropos=0&sektion=0&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html:
LOADER TUNABLES
Tunables can be set at the loader(8) prompt before booting the kernel or
stored in /boot/loader.conf. Many of these tunables also have a matching
sysctl(8) entry for access after boot.acpi_dsdt_load
Enables loading of a custom ACPI DSDT.acpi_dsdt_name
Name of the DSDT table to load, if loading is enabled.Before you can do that though you need to enable the speedstep MSR in the BIOS and if I recall correctly it is locked so you need to change the speedstep lock register (or prevent it being set). I did that in my modified bios.
Steve
-
Just a quick update:
I did a bit of experimenting from Arch Linux with a standard XTM515 box (factory BIOS and factory CPU). I can confirm that in BIOS 1.3 speedstep MSR is is indeed locked, but it is already set to 0x1 by default! So no MSR changes are required at all.
I also fiddled a bit with changing the FID and VID manually by means of the c2ctl utility. I just switched FID and VID from their allowable MAX state to MIN state and run a "benchmark" in each state. The CPU is definitely behaving correctly in each state and there is a corresponding performance change reflected in the benchmark results. So speedstep control does function correctly.
When I have more time I will repeat the same test while monitoring the box power consumption to see if there is any difference.
And then I will make an attempt at cutting a modified DDST to see if it works.
-
I was unable to see any measurable power consumption difference difference when I did it but I came to the conclusion that because the processor supports deeper halt states that may be masking any effect Speedstep has there.
Steve
-
I was unable to see any measurable power consumption difference difference when I did it but I came to the conclusion that because the processor supports deeper halt states that may be masking any effect Speedstep has there.
Steve
Right, you are absolutely correct. First, here are my results with a stock unit running minimalist installation of Arch Linux:
| XTM515 State | Power [W] | Power [VA] |
| OFF | 2 | 6 |
| Booting | 63 | 63 |
| Idle (Speedstep HI) | 46 | 47 |
| Idle (Speedstep LO) | 46 | 47 |
| Load (Speedstep HI) | 81 | 82 |
| Load (Speedstep LO) | 59 | 60 |In other words speedstep has absolutely no power consumption benefit near idle state. It has huge benefit when the cores are pegged, of course, but this would defeat the purpose. So the real benefit would be in the intermediate performance states where the CPU is under partial loads - the system can then trade-off some performance for lower power consumption. Mind you, this is probably a realistic typical operating state for a firewall appliance, so having it functional may save some energy in the long run…
I might redo the same test on my upgraded unit with 4GB RAM, Q9505S CPU and Intel SSD320, just for kicks.
Peter.
-
Ah nice result. :)
For many people a low to intermediate load is where a Core2duo is likely to operate most of the time. I had thought it might be of some benefit there.Did you add P-states specific for your CPU? I recall I had some difficulty finding the 'official' values but there were plenty of suggestions on both overclocking and underclocking forum threads.
Steve
