• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Problems overclocking 6276 extra spicy (4P)

Xeven

n00b
Joined
Dec 13, 2010
Messages
23
Greetings gents, I'm having trouble getting any sort of OC for my 4P setup. I've done test runs at stock and folds without hitches on (P8103/P8104s). However, once I start overclocking, it would almost immediately reboot for Method 2 (set freq/voltage). I have tried both methods:

Method_1: PSMAX 1 with Powernow On, CPB Auto
a. tpc -CM shows constant PS1
b. clockspeed shows ~2600Mhz
c. can sometimes run for an hour, sometimes a few minutes then reboots.

Method_2: Powernow Off, CPB Disabled, script:
Code:
FREQ=2600
VCORE=1.1750
sudo tpc -boostdisable
sudo tpc -fo 1
sudo tpc -set ps 2 vcore $VCORE freq $FREQ
sudo tpc -set ps 1 vcore $VCORE freq $FREQ
sudo tpc -set ps 0 vcore $VCORE freq $FREQ
sleep 1
sudo TurionPowerControl -fo 0

a. this will almost immediately reboot or after a few minutes, only tried up to 1.2V

More info
a. ht-retries doesn't seem to show any problems
b. temp@folding is ~45C CPU1/2/3/4 all nodes except node 7 @ ~38C

Queries:
a. Do I need to enable/disable anything else in the bios to get any OC stable?
b. Is there a specific bios for the H8QGL that is recommended or is the 3.0a fine?
c. Any recommendations as to what I should try next? :(

Configuration:

Motherboard: H8QGL-6F (Bios 3.0a)
Processors: 4x6276 spicy ZS232545TGG45 (2300/2600 all core turbo)
Memory: Crucial ballistix @1333 C9 (Crucial Ballistix 1866 C9)
PSU: Corsair AX1200
HSF: Corsair H60 (original version)
GPU: none (using IPMI)
TPC: 0.44RC2
O/S: Ubuntu 12.04LTS
MISC: MOS-C1 heatsinks on primary/secondary mosfets.

Thanks.
 
Last edited:
What is the All Core Turbo speed on the 6276?

DOH!!!

If all you want is 2600, then just sudo tpc -psmax 1

with the turbo on.
 
What is the All Core Turbo speed on the 6276?

DOH!!!

If all you want is 2600, then just sudo tpc -psmax 1

with the turbo on.

The all core is 2600Mhz. I want higher of course but I choose that (2600) speed to test but can't get it stable with either tpc overclock or with tpc -psmax 1. With psmax 1, it would just reboot after a few minutes or sometimes after an hour if I'm lucky. The thing that makes it weird is that it seems to be rock solid at stock, but can't even deal with the smallest of overclocks.
 
Is this script running on boot prior to fah starting?
 
Can you fold @stock without any problems as well?

I can fold at stock fine, and at 2.6Ghz with psmax 1, up to 2.8ghz at 1.1V with method 2.

But if I change clocks whilst fah is running it crashes.
 
I can fold at stock fine, and at 2.6Ghz with psmax 1, up to 2.8ghz at 1.1V with method 2.

But if I change clocks whilst fah is running it crashes.

You have it better than me then, I can't even go 2.6Ghz without it rebooting :(
 
You have it better than me then, I can't even go 2.6Ghz without it rebooting :(

I'm only running 2P though,
I was using socket 1 and 2 but I have switched to 1 and 4 to see if that makes a difference still re-building it.

I tired each CPU separately and it was fine but both together crashed.
So with the more CPUs the less stable these 6276 ES's are.
 
No expert, but I've had to fight some 4P systems:

Time to swap chips in their sockets, and look at the contacts on the chips. Ditto for the RAM.

That chip can normally run at 2600 all day long from the factory when it's cool. Either:

Power issue (voltage drop)
Heat Issue (any chip, not just CPU)
Contact Issue (any connector that passes current).
 
We have tried many things w/Spaz's setup, you may wish to go over them...

One thing we didn't try (and I'm not sure how likely that is to affect things)
is flashing ROM holes (that 3.0a BIOS package updates) with 2.0 BIOS
data.

One hole is related to SR5690; not sure about the purpose of the other one.

Process is slightly more risky than usual BIOS update but you should
be fine...

The idea is to:
1. Start with GL 2.0 BIOS package: http://www.supermicro.com/support/resources/getfile.aspx?ID=1530
2. Add flashrom: http://darkswarm.org/flashrom.exe
3. Flash GL 2.0 BIOS using flashrom:  flashrom -p internal:laptop=this_is_not_a_laptop -w H8QGL1.A28
4. Flash GL 2.0 BIOS (yet again, but) using flash.bat (just in case AFUDOS does something behind the curtains):  flash H8QGL1.A28
5. Power-off
6. Power-on

*) flashrom makes it easy to flash the whole ROM (incl. holes) in contrast to AFUDOS (tad convoluted)
 
We have tried many things w/Spaz's setup, you may wish to go over them...

One thing we didn't try (and I'm not sure how likely that is to affect things)
is flashing ROM holes (that 3.0a BIOS package updates) with 2.0 BIOS
data.

One hole is related to SR5690; not sure about the purpose of the other one.

Process is slightly more risky than usual BIOS update but you should
be fine...

The idea is to:
1. Start with GL 2.0 BIOS package: http://www.supermicro.com/support/resources/getfile.aspx?ID=1530
2. Add flashrom: http://darkswarm.org/flashrom.exe
3. Flash GL 2.0 BIOS using flashrom:  flashrom -p internal:laptop=this_is_not_a_laptop -w H8QGL1.A28
4. Flash GL 2.0 BIOS (yet again, but) using flash.bat (just in case AFUDOS does something behind the curtains):  flash H8QGL1.A28
5. Power-off
6. Power-on

*) flashrom makes it easy to flash the whole ROM (incl. holes) in contrast to AFUDOS (tad convoluted)

Sure, I'm up for it. Will try and see if it does the trick (I hope). Thanks.
 
Another thing we didn't try was bumping nb volts. It's tricky on F15h and requires
my work-in-progress TPC. We can go about doing that as well...

But first -- try 2.0 BIOS (per above), stick to psmax 1 method, and see if there are any errors
in the log or BIOS POST screen.
 
It will also be useful to determine if you've run into any MCEs: http://hardforum.com/showpost.php?p=1039812753&postcount=2
and if your BIOS prints any errors after such spontaneous reboot -- you'll probably need to disable Quiet Boot to see them.

Here's the output. Also tried setting NB to 1800 and 1600Mhz but that didn't help. I'll flash the bios just as soon as I'm physically there with the unit, just using a terminal at the moment. Thanks.

Code:
/var/log/syslog.1:May  2 21:02:41 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog.1:May  2 21:46:35 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog.1:May  2 22:03:26 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog.1:May  2 22:32:41 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog.1:May  2 22:41:53 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog.1:May  2 23:32:56 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog.1:May  2 23:59:36 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog.1:May  1 21:02:31 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog:May  2 00:33:56 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog:May  2 02:37:21 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog:May  2 02:42:46 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog:May  2 04:43:36 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog:May  3 10:10:56 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog:May  3 14:22:08 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog:May  3 14:22:08 StaMaria mcelog: warning: 16 bytes ignored in each record
/var/log/syslog:May  3 14:22:08 StaMaria mcelog: consider an update
/var/log/syslog:May  3 14:36:57 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog:May  3 14:36:57 StaMaria mcelog: warning: 16 bytes ignored in each record
/var/log/syslog:May  3 14:36:57 StaMaria mcelog: consider an update
/var/log/syslog:May  3 14:44:43 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog:May  3 14:44:43 StaMaria mcelog: warning: 16 bytes ignored in each record
/var/log/syslog:May  3 14:44:43 StaMaria mcelog: consider an update
/var/log/syslog:May  3 15:00:28 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog:May  3 15:00:28 StaMaria mcelog: warning: 16 bytes ignored in each record
/var/log/syslog:May  3 15:00:28 StaMaria mcelog: consider an update
/var/log/syslog:May  3 15:11:50 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog:May  3 15:11:50 StaMaria mcelog: warning: 16 bytes ignored in each record
/var/log/syslog:May  3 15:11:50 StaMaria mcelog: consider an update
/var/log/syslog:May  3 16:33:10 StaMaria mcelog: failed to prefill DIMM database from DMI data
/var/log/syslog:May  3 16:33:10 StaMaria mcelog: warning: 16 bytes ignored in each record
/var/log/syslog:May  3 16:33:10 StaMaria mcelog: consider an update
 
Thanks :)

Ok, not a lot of info there.

So, it very much looks like Spazturtle's issue (though let's double check the POST-screen-after-spontaneous-rebot).

I'll get a TPC build for you in the mean time.
 
But first -- try 2.0 BIOS (per above), stick to psmax 1 method, and see if there are any errors
in the log or BIOS POST screen.

Tried flashing with flashrom but failed with some a "write/read" error. Disabled IPMI but still failed with the same error. Proceeded to flash using afudos and it worked but I guess the romhole wasn't updated?
 
Yeah, they weren't updated. We'll need to flash them the AFUDOS way.
I'll get myself some tea and will be right with you ;)
 
Flashed the bios/romholes did psmax 1, was able to do 1% then the system rebooted. :( On a unrelated note, I can't seen to use LAN1/2 or PMI_LAN to connect to the network, Ubuntu or Windows server 2012 does not detect them. My LAN1/2 macs also appear as 02:10:00:00:00:00/02:10:00:00:00:01.
 
Flashed the bios/romholes did psmax 1, was able to do 1% then the system rebooted. :( On a unrelated note, I can't seen to use LAN1/2 or PMI_LAN to connect to the network, Ubuntu or Windows server 2012 does not detect them. My LAN1/2 macs also appear as 02:10:00:00:00:00/02:10:00:00:00:01.

You tired running each CPU seperatly, you can use the kraken to run fah on only 1 cpu at a time.
 
Flashed the bios/romholes did psmax 1, was able to do 1% then the system rebooted. :(
Ugh :(
Any errors in the post screen after a reboot?

On a unrelated note, I can't seen to use LAN1/2 or PMI_LAN to connect to the network, Ubuntu or Windows server 2012 does not detect them. My LAN1/2 macs also appear as 02:10:00:00:00:00/02:10:00:00:00:01.
Does lspci | grep Ethernet show the NICs?

IIRC there was a bug in some H8Q BIOSen -- can you try just loading optimal defaults
(F9 in the BIOS setup screen, then F10).
 
Last edited:
Ugh :(
Any errors in the post screen after a reboot?


Does lspci | grep Ethernet show the NICs?

IIRC there was a bug in some H8Q BIOSen -- did you try just loading optimal defaults
(F9 in the BIOS setup screen, then F10).

No, no errors in the post screen :( Fixed the mac address problem with a cmos reset but I'll try F9 if it pops up again.

Some other observations. I seem to have 2600 stable using method 2. Set voltage is 1075mV, sensors at ~1104mV/1096mV/1072mV/1072mV with CPU0 always higher and CPU3 always the lowest. If I try 2700 even with considerably higher set voltages 1000mV, 1100mV, 1150mv and 1175mV it would reboot after a few minutes.

On another note, how is TPC for windows? I tried with windows server 2012 and while it is able to set the voltage/frequency, the video would crash and windows is forced to recover to the login screen. The system doesn't crash and it's able to continue, however it would crash the video again after some time. At stock, it runs just fine.

I could try swapping ram now I guess or go single stick.
 
The issue seems to be related to cumulative [?] current draw of the board and/or HT (at least per
Spazturtle's data.

I don't think removing memory will solve this. It may hide the issue [less load == lower crash likelihood].

Can you explore BIOS options to see if you can lower the HT speed? Don't remember the exact option
but 1.1 BIOS did have something. Don't remember the 2.0.
 
TPC sure modifies the speed register; unfortunately it has no effect on reality [due to the way HT is initialized].
 
The issue seems to be related to cumulative [?] current draw of the board and/or HT (at least per
Spazturtle's data.

I don't think removing memory will solve this. It may hide the issue [less load == lower crash likelihood].

Can you explore BIOS options to see if you can lower the HT speed? Don't remember the exact option
but 1.1 BIOS did have something. Don't remember the 2.0.

I can't seem to find an option to change the HT using 2.0. There is an option for HT1/Auto but that seems to be it.

I changed the power supply to a brand new one but same model (AX1200) just to remove doubts that it's PSU power delivery at play (still reboots) .

To test the cumulative current draw or subsequent power draw ceiling theory, I backed the voltage to 1062.5mV and sped up the frequency to 2700Mhz and its been running stable for more than an hour now. Power on the wall being roughly the same. I say roughly because my wall watt meter choose this moment of all days for the button cell batteries to die. This just keeps getting more fun doesn't it? ;) Thanks.
 
Yes, HT1/Auto, that's the one :)
HT1 == uses HT protocol per spec version 1 [slower].

I'm still working on the TPC for you [so we have more knobs at our disposal] -- should be done in ~2h.
 
Here's my WIP TPC: http://darkswarm.org/tpc/testing/TurionPowerControl (x86_64 binary)

It's got revamped command line parsing so method 2 looks more like this with this version
(assuming you place the binary in your home directory):
Code:
FREQ=2600
VCORE=1.1750
sudo ~/TurionPowerControl -boostdisable
sudo ~/TurionPowerControl -fo 1
sudo ~/TurionPowerControl -ps 2 -vcore $VCORE -freq $FREQ
sudo ~/TurionPowerControl -ps 1 -vcore $VCORE -freq $FREQ
sudo ~/TurionPowerControl -ps 0 -vcore $VCORE -freq $FREQ
sleep 1
sudo ~/TurionPowerControl -fo 0

This version also allows adjusting NB parameters. Run-time frequency adjustment doesn't work very
well so I generally recommend against manipulating it :)

Voltage adjustment should work w/o issues, however -- here's how you do it.

Determine current NB voltages (per node) (note that this is NB P-state we're looking at here, not CPU P-state):
Code:
sudo ~/TurionPowerControl -spec | grep pstate.0

Then, determine target voltage.

Side note -- I do understand that (from your recent experiments) the lower CPU Vcore, the more
stable the machine is, but... I wonder if the reboot is related to poor NB Vdd regulation.
That is, CPU sucking so much current that it adversely affects NB operation.

I know it's pretty thin but perhaps bumping NB voltage will yield something... interesting?

Back to the subject --

Next, we manipulate NB P-state 1 and set desired parameters (here 2000 MHz / 1.175 V)
Code:
sudo ~/TurionPowerControl -nbps 1 -nben -nbfreq 2000 -nbv 1.1750

Double check the setting:
Code:
sudo ~/TurionPowerControl -spec | grep pstate.1

Make CPU P-states 0-2 use NB P-state 1 (the one we just configured):
Code:
sudo ~/TurionPowerControl -ps 0 -setnbps 1
sudo ~/TurionPowerControl -ps 1 -setnbps 1
sudo ~/TurionPowerControl -ps 2 -setnbps 1

Perform P-state transition to apply the changes:
Code:
sudo ~/TurionPowerControl -fo 1
sudo ~/TurionPowerControl -fo 0
 
Last edited:
Tried the new TPC tear, no apparent effect at the moment :( However, I only tried 1.175V, 1.185V and went back 1.15V just to cover most bases. How far can I push it? Is TPC modifying VDDHTTX? Thanks!
 
I probably wouldn't want to exceed 1.2V on the NB.

1.2 is several notches (one notch is 12.5mV) above stock so if that doesn't affect the
behavior, it's probably blind alley.

I don't believe that NB and HT voltages are related. HT spec says that 1.2V +/- 5%
is nominal interface voltage... go figure.

Have you had any success with HT1 speeds?

One more idea. Back when Spaz and I were looking at this, we would test one CPU at
a time. But... how about this: 4 clients (different machine IDs), each with -smp 16 and
bound to one CPU.

If you're interested -- you'd need to use Kraken's startcpu feature to facilitate binding
to a specific CPU. General idea is to:
1. Unwrap any FahCores
2. Wrap FahCores with add'l parameter: -c startcpu=X, with X of 0 (the default)
   for CPU1*, 16 for CPU2*, 32 for CPU3* and 48 for CPU4*
3. Start clients (probably one at a time)
4. Confirm that binding occurrs the way we want to -- with sth like: ps -Leopid=,tid=,pcpu=,psr=,comm= | awk '/[F]ahCo/ { if ($3 > 10) print }'

*) subject to Node/Core<->Socket mapping which may not be natural but it doesn't affect
&#8194;&#8194;&#8197;the test

My 6200 ES (GG44 / B0) are currently in Tyan board (had perhaps 5-7 spontaneous
reboots due to NB watchdog timer timeouts over ~two years).
It will be a while before I can load them in SM board...
 
I set the speed to HT1 but it didn't seem to help. However, I finally got an error at post after a reboot @2800Mhz/1050mV, "CPU0X/Node0X:HT Link SYNC Error".

error01.png
 
Interesting... Was that with HT1 or HT3 speeds?
 
Got it.

Open question -- why didn't we see any errors in HT3/Auto config? Ugh...

If we assume that the issue is HT-related... then not sure what else can be done... hmm....
Then again, I can't readily see a correlation between "vcore behavior" and HT...

The 4-client-test (with HT3/Auto) would add some weight to the HT-being-the-culprit theory, I s'pose.

Another thing to consider is cleaning CPU pads with alcohol and (possibly -- another long shot)
rotating CPUs.

Per SM 4P link map (http://hardforum.com/showpost.php?p=1038544776&postcount=240),
every CPU uses same set of links for inter-CPU communications. That actually calls against
rotation... but what if... what if ... what if the issue is related to CPU<->IO-H link(s) ?

As you can tell, my confidence is reaching new lows :eek:

Side question, in HT3/Auto configuration what HT frequency does TurionPowerControl -htstatus
report?

The reason I'm asking is that SM 1.x BIOS sets HT at 3.0 GHz (even though CPUs
support 3.2) -- I'm wondering how 2.0 [?] BIOS sets IL chips up...
 
Got it.

Open question -- why didn't we see any errors in HT3/Auto config? Ugh...

Cosmic rays? :p Honestly, it's possible its an entirely different issue altogether.

If we assume that the issue is HT-related... then not sure what else can be done... hmm....
Then again, I can't readily see a correlation between "vcore behavior" and HT...

The 4-client-test (with HT3/Auto) would add some weight to the HT-being-the-culprit theory, I s'pose.

I'll get back with you on that after I finish this WU. Hopefully this will provide more insight.

Another thing to consider is cleaning CPU pads with alcohol and (possibly -- another long shot)
rotating CPUs.

Per SM 4P link map (http://hardforum.com/showpost.php?p=1038544776&postcount=240),
every CPU uses same set of links for inter-CPU communications. That actually calls against
rotation... but what if... what if ... what if the issue is related to CPU<->IO-H link(s) ?

As you can tell, my confidence is reaching new lows :eek:

Will do, was planning to completely change the fan layout anyhow which (because of the layout) means I have to disassemble everything.

Side question, in HT3/Auto configuration what HT frequency does TurionPowerControl -htstatus
report?

The reason I'm asking is that SM 1.x BIOS sets HT at 3.0 GHz (even though CPUs
support 3.2) -- I'm wondering how 2.0 [?] BIOS sets IL chips up...

HT3 (using new tpc, original says SpeedReg=3 (0MHz)
Code:
Hypertransport Status:
Node 0 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 0 Link 1 Sublink 0 Bits=16 Coh=0 SpeedReg=14 (2600MHz)
Node 0 Link 2 Sublink 0 Bits=16 Coh=1 SpeedReg=19 (3200MHz)
Node 0 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 0 Link 3 Sublink 1 Bits=8 Coh=1 SpeedReg=19 (3200MHz)

Node 1 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 1 Link 0 Sublink 1 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 1 Link 1 Sublink 0 Bits=16 Coh=1 SpeedReg=19 (3200MHz)
Node 1 Link 2 Sublink 0 not connected
Node 1 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)

Node 2 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 2 Link 1 Sublink 0 not connected
Node 2 Link 2 Sublink 0 Bits=16 Coh=1 SpeedReg=19 (3200MHz)
Node 2 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 2 Link 3 Sublink 1 Bits=8 Coh=1 SpeedReg=19 (3200MHz)

Node 3 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 3 Link 0 Sublink 1 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 3 Link 1 Sublink 0 Bits=16 Coh=1 SpeedReg=19 (3200MHz)
Node 3 Link 2 Sublink 0 not connected
Node 3 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)

Node 4 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 4 Link 1 Sublink 0 not connected
Node 4 Link 2 Sublink 0 Bits=16 Coh=1 SpeedReg=19 (3200MHz)
Node 4 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 4 Link 3 Sublink 1 Bits=8 Coh=1 SpeedReg=19 (3200MHz)

Node 5 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 5 Link 0 Sublink 1 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 5 Link 1 Sublink 0 Bits=16 Coh=1 SpeedReg=19 (3200MHz)
Node 5 Link 2 Sublink 0 not connected
Node 5 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)

Node 6 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 6 Link 1 Sublink 0 not connected
Node 6 Link 2 Sublink 0 Bits=16 Coh=1 SpeedReg=19 (3200MHz)
Node 6 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 6 Link 3 Sublink 1 Bits=8 Coh=1 SpeedReg=19 (3200MHz)

Node 7 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 7 Link 0 Sublink 1 Bits=8 Coh=1 SpeedReg=19 (3200MHz)
Node 7 Link 1 Sublink 0 Bits=16 Coh=1 SpeedReg=19 (3200MHz)
Node 7 Link 2 Sublink 0 not connected
Node 7 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=19 (3200MHz)

For reference, HT1 (using original tpc):
Code:
Hypertransport Status:
Node 0 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 0 Link 1 Sublink 0 Bits=16 Coh=0 SpeedReg=7 (1200MHz)
Node 0 Link 2 Sublink 0 Bits=16 Coh=1 SpeedReg=7 (1200MHz)
Node 0 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 0 Link 3 Sublink 1 Bits=8 Coh=1 SpeedReg=7 (1200MHz)

Node 1 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 1 Link 0 Sublink 1 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 1 Link 1 Sublink 0 Bits=16 Coh=1 SpeedReg=7 (1200MHz)
Node 1 Link 2 Sublink 0 not connected
Node 1 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)

Node 2 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 2 Link 1 Sublink 0 not connected
Node 2 Link 2 Sublink 0 Bits=16 Coh=1 SpeedReg=7 (1200MHz)
Node 2 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 2 Link 3 Sublink 1 Bits=8 Coh=1 SpeedReg=7 (1200MHz)

Node 3 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 3 Link 0 Sublink 1 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 3 Link 1 Sublink 0 Bits=16 Coh=1 SpeedReg=7 (1200MHz)
Node 3 Link 2 Sublink 0 not connected
Node 3 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)

Node 4 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 4 Link 1 Sublink 0 not connected
Node 4 Link 2 Sublink 0 Bits=16 Coh=1 SpeedReg=7 (1200MHz)
Node 4 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 4 Link 3 Sublink 1 Bits=8 Coh=1 SpeedReg=7 (1200MHz)

Node 5 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 5 Link 0 Sublink 1 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 5 Link 1 Sublink 0 Bits=16 Coh=1 SpeedReg=7 (1200MHz)
Node 5 Link 2 Sublink 0 not connected
Node 5 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)

Node 6 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 6 Link 1 Sublink 0 not connected
Node 6 Link 2 Sublink 0 Bits=16 Coh=1 SpeedReg=7 (1200MHz)
Node 6 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 6 Link 3 Sublink 1 Bits=8 Coh=1 SpeedReg=7 (1200MHz)

Node 7 Link 0 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 7 Link 0 Sublink 1 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
Node 7 Link 1 Sublink 0 Bits=16 Coh=1 SpeedReg=7 (1200MHz)
Node 7 Link 2 Sublink 0 not connected
Node 7 Link 3 Sublink 0 Bits=8 Coh=1 SpeedReg=7 (1200MHz)
 
Last edited:
Just to let you know, you asked me last week to try cpu sockets 1+4 and see if that is any different from 1+2. Well it isn't same issue.
 
Back
Top