Hi, Thats great I'll try that bios tomorrow. Regarding broadcom ethernet; Yes I'm using the latest, but my chip is actually the BCM5702 and under that download section it specifically states for server 2008 x64; "This driver does not support BCM5700, BCM5701 and BCM5702 devices.To use these devices under Vista, Windows Server 2008, Windows Server 2008 R2, or Windows 7, please use the XP or Win2K3 driver above." So I had to use the 2003 x64 driver, and although it works and installs without issue, I do have the aforementioned problem. Now; I have also tried the server 2008 x64 r2 driver but I had to force install through device manager. The driver still worked but still gave me the same problem. I think the only way forward with this chip is possibly a dedicated pci-x/pci ethernet card that supports 2008 x64. Thanks for the bios though, I'll be certain to let you know tomorrow how it goes. Danny
Hi, Well all seemed promising at first, ran a few benchmarks and it seemed to be scaling okay... then wham!.. freeze. So I went back to non-powernow bios, set RMClock to the same values as above and ran the same benchmarks... it didn't crash, and I tested scaling thoroughly and each individual pstate too. So, it appears the bios still has a problem with the scaling. You don't think it's to do with the PLL Lock time do you>? Attached are some more screens of rmclock, but I haven't adjusted these, they were already applied. Danny
Ok, I'm re-writing what I wrote here previously. I looked at the 26094.PDF again (page 277) and the calculation is as follows: StpGntTOCnt = PLL_LOCK_TIME * 1000 / 5 So with StpGntTOCnt=2000, then RMClock is setting your PLL_LOCK_TIME = 10us. Give me about 6hrs and I'll take another stab at it.
Thanks tqhoang, Does boot fail recovery simply load bios defaults after a crash or what? I'll try this bios tomorrow now because my servers busy doing some windows updates. Thanks again and I'll let you know what happens. Danny
The boot fail recovery lets you do the Phoenix Crisis Recovery. This is required if you lost power in the middle of a BIOS flash. If the bootblock of the BIOS is still intact, then you can invoke the Phoenix Crisis Recovery process. Normally if you're flashing BIOS mods, you really only want to update the bootblock once with the original factory version. Ex: Use phlash16 with /bbl option only when upgrading to the original HDAMA-G v2.18B BIOS. Then when you flash BIOS mods, you leave out the /bbl option so that it is never modified. But with that said, I'm not sure if you need to flash with the /bbl option or not to get the BFR option to work or not. Anyway, let me know how it goes.
I did upgrade to the original bios first to upgrade the bootblock, unfortunately I think I used the /bbl option on the mods. Presumably I can just reflash the original bios using /bbl then omit the /bbl again. With that said, the bootblock in the mod bioses won't be any different anyway surely? On a bad note, the test b (10us) still locks up, not straight away but I can't run it for more than a few minutes if I'm actively using the system Shame after all your work, don't think there is anything else we can try. It's odd because I left the server on for over 12 hours with rmclock using the linux found p-states and it was solid during that time. There is obviously something in rmclock not getting translated into the bios mod, but what I have no clue. Regarding PLL locking, in rmclock it states; HTT Clock PLL Lock counter (us): 100 Is the lock counter something different to the actual PLL Lock time?
Hi, Strange. This time the system was pretty stable, it crashed once but I think that was me that caused that during a benchmark. I can see the frequency scaling during the benchmark, but something else is broke now. When I run rmclock at idle the power consumption at the socket is 152Watt, when running your latest mod bios at idle the consumption is 233Watt! Huge difference... I'm going back to try the first modded bios, see if the problem exists there too.
Interesting...what that PSD object does is tie the CPU's together a single "domain" for p-state changes. Perhaps what I need to do is make CPU0 & CPU1 to Domain0 and CPU2 & CPU3 to Domain1? Let me know what you find out and if you're interested in testing another one with the above change.
Scrap that last post, I was being dumb... I was watching the power meter from across the room and didn't realise it had switched back to volts reading lol So the power is no different than it was with rmclock. As we speak I am benchmarking again, well actually it's a burn in test, stressing all the cores at once - randomly between 25-80% load. I'm using a different app (core temp 1.0 RC3) to monitor voltages, frequency and temps. I don't want to speak to soon, but I think you've found the missing link with the PSD Objects. I don't know how stable it is, but it's running a lot longer now than it was. Oops, spoke too soon I took a pic of the monitor when it crashed, but I don't think it tells us anything at all, only that it's switching properly in terms of voltage and frequency. Out of interest temps seems better now than they were. This is very annoying, more so for you I'm sure. But I'm certain it's better than it was, I can run the burn-in-test for 10+ now, whereas before it would crash out less than 2 mins, sometimes even on load of the desktop. I wonder if we should set the PLL Lock back to 2us? Regarding PSD Objects; I really don't know, do multi-cpu systems normally scale both cpus together (in sync) or independently? I guess we need to know how they normally operate. I'm willing to try anything really. I think what I'd like to do at my end is boot into linux and check the p-states with my cpus, just in case it gives us something different to work with.
You don't think this is anyway related to the 200MHz HT on CPU 1? I know the thinking is that it may be just cosmetic, but everything app I use reports it as 800 on 1 and 200 on 2.
Yes, those 3 are in the basic mod. The only thing new is the _PSD. I'll create one more before the weekend, and then check back on Monday.