Hi guys.

Well, first of all, sorry for my poor english.

I choosen to create this topic here, because a guy here on Brazil tried exactly that: to sistematically hunt down the TLB bug. He had some success on it, but, unfortunatelly, got robbed during the holidays.

The, I've choosen to translate to here his findings, since there is a lot of people here who have phenom processors, ability to oc them and many differente MBs, chipsets and bios versions available.

The original topic (in portuguese) is this: http://www.forumpcs.com.br/viewtopic.php?t=227912

The last update to his findings, translated down here:

Quote Originally Posted by Schakal
Locking a Phenom? Tests Results:

Hi!

Firstly I would like to acknowledge for all suggestions and say that this testing even surprised me, due to two unnexpected events.

Another observation:
In all tests, I've used the configuration below (unavailable anymore), but with differente video card and ammounts of RAM. The video card used was my old X 1950XTX and the system memory was 4Gb (4x1Gb) made of Corsair CM2X1024-6400. In all possible configurations tested, I've didn't used oc to not missinterpretate them as oc issues.

NelsonK wrote:
From what I could understand, the error (system lock) happens in specific condition of L3 cache memory usage, and seems to happens with increase frequency when one uses some kind of virtualization program.

That's right. I won't specify more here, in order to create some "suspense", but indeed, I could not find a "less frequent" bug occurency, what means, I could only find it when using VMs.

Well friends, let's go to the testing!

Test 1 - Super PI, Shrink and WinRAR

In order to flood the CPU totally without having less than 100% usage moments, each core had to executde a 32M superpi calculation Moreover, winrar archiving processes, and dvd shrink video conversions were performed at the same time.

Result: 100% of cores usage and no bug.

Test 2 - Test 1 + Cache Benchmark:

Simulating the previous test with pc wizard, an extra cache bench was performed.

Result: 100% of cores usage and no bug.

Test 4 - Prime95

4 instances of Prime95, one in each core simultaneously.

Result: 100% of cores usage and no bug.

Teste 5 - VM 1

With VMWare, I created and emulated a common VM with Windows Vista HP 64bits. In this VM I've made all previous tests, except fourth.

Result: 100% of cores usage and no bug.

Test 6 - VM 2

With VMWare, I created and emulated a common VM with Windows Vista HP 64bits. In this VM I've made all previous tests, except fourth. A curious event happened: The computer restarted AND one of the VM corrupted. Accordingly with windows events log, something happened with "svchost.exe", what weemed curious cause nothing have ever hppened there.

Result: No 100% of usage on the 4cores, bug didn't happened and something new appeared: the only single 32bits VM that I can't emulate over 64bits is Vista HP. Already tested installation disk, hadware, etc, and nothing
Off-Test=Any clue on this one?

Teste 7 - VM 3

With VMWare, I created and emulated two common VMs with Windows Vista Ultimate de 64bits. In these VMs emulated all tests up to test 3, but I've defined two cores/VM.

Result: 100% of cores usage and no bug.

Teste 8 - VM 4

With VM Ware, I created and emulated four common VMs with Windows Vista Ultimate 64bits. In these VMs emulated all tests up to test 3, but I've defined one core/VM.

Result: Is that you, BUG?

In test 8, the CPU reinitialized sponteously when, according with the system manager, the cores 1 and 4 reached 100% of usage, core 2 50 % and core 3 a bit more than 80%. I've started to emulate the tests on the VM #3.

Looking for information on the four logs availabel, absolutelly no information on this subject was found.

For a happy coincidence, I've turned off Cool'n' Quiet and did test9:

Teste 9 - VM 4 WITHOUT Cool'n'Quiet

Exactly as in test 8, but with Cool'n'Quiet turned off all time.

Result: 100% of cores usage and no bug.

It may seem really odd, but without Cool'n'Quiet the CPU executed all tasks normally.

Gone sleep.

In the morning, a few extra tests like 9 using prime95 and all other programs with the 4 VMs. No bug at all. And 100% all 4 cores, as would be expected because emulating 4 VMs is a big job.

Conclusion:

4 VMs + Cool'n'Quiet = BUG

...
What do you guys think about trying to systematically try to find the TLB error? I admit, that's an odd thing to try, but now we have an initial "systematic way" of trying to do it.

Does it worth the effort? I would think so. But, of course, it's up to you all here.