I had the same error while trying to execute the file while it was still packed in the rar file. If you extract it to the same dir as crystal cpu, then right click, run as admin, everything should work perfectly.Quote:
Originally Posted by LIKMARK
Printable View
I had the same error while trying to execute the file while it was still packed in the rar file. If you extract it to the same dir as crystal cpu, then right click, run as admin, everything should work perfectly.Quote:
Originally Posted by LIKMARK
you were to run while it was still packed?! :confused: :shocked: :eek:Quote:
Originally Posted by Raiderman
LOL I know I was in a hurry ;)
Is there a way to disable the dialogue box from popping up on startup. It would be cool to have the command window open at startup, apply the fix and then disapear.
@sam, thanks for your hard work, its much appreciated!
@KTE. thanks also ;)
lolz! excited you mean...how was your OC?Quote:
Originally Posted by Raiderman
That's the message yes. You mean the sysinfox64.dll I presume? Yes I can find it, but I can't find a sysinfo.dll. NoQuote:
Originally Posted by sam2008
No, I mean sysinfo.dll. Try redownload the CrystalCPUID, make sure sysinfo.dll is in there. Then you should be fine.Quote:
Originally Posted by LIKMARK
ok, had to download the x86 version. not the x64 version. Then it worked. Gonna restart now and see :)
Tested winrar right away and got 1200kb/s against 240 with tlb patch enabled. Thanks
sam2008: Is there any way to control which cores the MSR is applied to in your app through the ini?
It's because I (and many) oc at bootup settings where 1 core will fail but the rest of 3 won't, to then change the MSR for that weak core to drop multiplier one notch and let it run at lower MHz while the other 3 run at bootup MHz. This isn't the hardest bit, but the bit I need is, when CnQ is enabled I used your app to drop to 0.850VID 800MHz on all cores, but with load, they all need to get back up to the multi's I set initially and not all the same multi (which is what they do unless I change MSR for each core separately).
So say I use 13x on first 3 cores and 12.5x multi on the last core, even with CnQ enabled, I'd want it to remain max 12.5x under load (or it'd crash).
Is there any way yet? This'll come in handy for you, test your Phenom, it will very likely have one core very weak compared to the rest. :yepp:
KTE: You word is my command. One way to do it is to add a core mask option in the ini file. I.E. 0b1011 stands for enabling writing to core 1, 2, and 4, but not core 3. How does that sound to you?
Sounds perfect, eager to test. :)
We use "-coremask=x" to disable a core using CPU-Z to avoid the weak core and we also tried disabling a specific core using Bus:0h Dev:24h Fct:3h Offset:BEh 0000000000000000b [core 3,2,1,0], both of them never worked as we wanted so I suppose it is similar to both methods in a way but to get something better done. A DIY replacement for BIOS multi. :up:
KTE: I have uploaded the ver1.02 at POST #90. Try to keep all the updates in one post so that it won't be scatter all around. You can download from there. Basically added support for core masking in the INI file. Let me know how it worked out for you :).
Now you can use the COREMASK to specify which core you want the MSR value to be written. It is 4-bit binary value. The lowest bit is core 1, second bit is core 2, third bit is core 3, and fourth bit is core 4. When a bit is set to 1, MSR for that core will be written. If a bit is set to zero, the program will skip the MSR for that core. For example, 0b1011 means core 1, 2, and 4 will be written, and core 3 will be skipped. If COREMASK is set to 0b1111, then the selected MSR for all four cores will be written. If COREMASK is set to 0b0000, then selected MSR won't be written to any of the cores. Changing the COREMASK value accordingly. It is set at 0b1111 by default (all 4 core enabled).
I usually like something to indicate that all things are working fine. Otherwise, the console window will just flash and disappear not really know what's going on. That's why I deliberately added the message box. But as you wish, I updated the program, now you can choose to disable the popup message box by adding the -nopop argument at the end of the program. If no argument is provided, the box will popup by default. Go to RebelsHeavenForum to download the TLB ver1.03. In Vista, you have to add the argument -nopop thru the taskscheduler. Hope it works for you.
Quote:
Originally Posted by Raiderman
Sam2008: thank you! :up:
Works perfect. However quick qs: does coremask value override the mask_high/mask_low parameter?
What I mean is if I set:
index=0xc0010070
high=0x00000000
low=0x5000340A
mask_low=0xFFFFFFFF
mask_high=0xFFFFFFFF
coremask=0b0111
Will it write 0x5000340A to core4 or skip it reading the mask_low=0xF?
Could you not use mask_low/mask_high values 0/1/2/3/4/5/6/7/8/9/A/B/C/D/E/F to do the same?
i.e. using the above, me wanting to write to core 3 (340A) only=>
index=0xc0010070
high=0x00000000
low=0x5000340A
mask_low=0xFFFFF777 (mask 0111b)
mask_high=0xFFFFFFFF
Would this work?
TBH only now has Phenom really become insanely tweakable and fun to play with.
I updated my RW-Everything batch file and now it's using AND to clear only the needed bits and not changing the rest of the msr register.
I used the new version 0.29 of RW-Everything.
Code:>cpu 1
read register to LocalD:LocalA
>rdmsr 0xc0010015
set bit#4 to zero
>LocalA = AND LocalA 0xfffffff7
write back
>wrmsr 0xc0010015 LocalD LocalA
read register to LocalD:LocalA
>rdmsr 0xc0011023
set bit#2 to zero
>LocalA = AND LocalA 0xfffffffd
write back
>wrmsr 0xc0011023 LocalD LocalA
>cpu 2
read register to LocalD:LocalA
>rdmsr 0xc0010015
set bit#4 to zero
>LocalA = AND LocalA 0xfffffff7
write back
>wrmsr 0xc0010015 LocalD LocalA
read register to LocalD:LocalA
>rdmsr 0xc0011023
set bit#2 to zero
>LocalA = AND LocalA 0xfffffffd
write back
>wrmsr 0xc0011023 LocalD LocalA
>cpu 3
read register to LocalD:LocalA
>rdmsr 0xc0010015
set bit#4 to zero
>LocalA = AND LocalA 0xfffffff7
write back
>wrmsr 0xc0010015 LocalD LocalA
read register to LocalD:LocalA
>rdmsr 0xc0011023
set bit#2 to zero
>LocalA = AND LocalA 0xfffffffd
write back
>wrmsr 0xc0011023 LocalD LocalA
>cpu 4
read register to LocalD:LocalA
>rdmsr 0xc0010015
set bit#4 to zero
>LocalA = AND LocalA 0xfffffff7
write back
>wrmsr 0xc0010015 LocalD LocalA
read register to LocalD:LocalA
>rdmsr 0xc0011023
set bit#2 to zero
>LocalA = AND LocalA 0xfffffffd
write back
>wrmsr 0xc0011023 LocalD LocalA
>rwexit
Coremask determines which core's MSR you want to write. Mask_low, and Mask_high determines which bit in the MSR you want to write. Coremask has a higher priority. If you set coremaks=binary 0111, then it will skip any writing operation to core 4.
If you set
index=0xc0010070
high=0x00000000
low=0x5000340A
mask_low=0xFFFFFFFF
mask_high=0xFFFFFFFF
coremask=0b0111
You will skip core 4. Nothing will done to core 4. Also since you set the mask_low and mask_high=0xffffffff, so you mask all bits in that MSRs in the other 3 cores. So no change will be made to the MSRs in core 1,2,3 (or actually, it will read the original values in the MSRs in core 1,2,3, and write the original value back in). If you set mask_low and mask_high=0x00000000, then MSRs in core 1,2,3 will be written with 0x5000340A. Still nothing will be done to core 4 because of coremask=0111(b) told the program to skip it.
The mask_high and mask_low are only useful if you want certain bits in the MSR not to be change. If you want to directly write the specified value into the MSRs, you should set them to 0x00000000.
For example, if the original low value of a MSR is 0x10000203, and you want change the its 1-4 bits to 9, and 60-64 bits to 4, but do not want to touch the bits 5-59 and want to keep them the way they are originally. Then you can use the mask_low=0x0FFFFFF0, and write the low=0x4BBBBBB9 (B represents a non-care value since it will be masked off) into that MSR. The final value of MSR after the operation will be 0x40000209.
If you just want to write a specified value directly into MSRs, then set the Mask_high, mask_low=0x0.
Quote:
Originally Posted by KTE
Yeh, RW-Everything is good tool. But it uses a unsigned driver. So in Vista, it will cause my Vista go into a so called "TEST MODE" (driver signing forced to disable) with watermarks over the desktop.
Quote:
Originally Posted by mibo
Quote:
Originally Posted by sam2008
WOW! You Rock! Usually I only get it my way at Burger King ;)
Yeah I understand that much and have been doing it but was thinking if Fh = 1111b, so you chose to mask the bit, but 0h = 0000b so you chose to not mask those, then maybe (I was hoping) we could use.. never mind :D
It won't work, since bits don't stand for each core.
@KTE, I know it is a bit confusing, using 1 stand for disabling the MSR bit, but also use 1 for enabling cores. That's all because MSR masking was originally based on the convention set by justapost ;).
So does it work out the way you wanted now? Crank up the multiplier for 1,2 and 4 and lower the multi for defective core 3? Just wondering can't you adjust that in AOD? I guess AOD probably won't let you save the settings.
Quote:
Originally Posted by justapost
I understand the question like that:
If you apply an value to an MSR on multiple cores, do you perform the masking for each core or do you use the result from the first core for the other cores?
BTW I like the result a lot better than my proposal. I guess coremask might also work on multi socket machines.
Masking is performed separately for each core's MSR's original value since I realized in certain circumstances the bit values for MSR for different cores might be different.
Quote:
Originally Posted by justapost
@KTE, any exciting results on separately adjusted multipliers for each core:) ?
Sorry, Phenom=no boot for many hours yet. It happens randomly when I reset BIOS on my Phenom as it did on my 1st one. :(
So I've not checked. I know 2700x3/2600x1 is fully stable though, not tried more yet. 2665 will also be stable on core3 and 2754 is max I know is stable with core 0,1,2 so I'll give it a try for more 100% stability. Around 222x12.5 3 cores and 222x12 on last core next stop.
Thank U sam2008, great job! :up:
Added sam2008's tool to the description in the first post. Also added a crosslink to sam's thread.
EDIT: Added wibo's updated script to the first post.
ok question because i could not find a clear answer anywere and not at home to check it out.
i know with 9850x4 the tlb patch on/off does not show in bios.
has anyone checked to see even with a 9850x4 if vista sp1 is still activating this tlb patch ????
Edit 4/24: ok well something is still going on the cpu tweak in bios 1002 of the asus m3a32.
aparantly effects the red circle in overdrive. wich has to do with turning on and off the b2 tlb bug patch.
no if i have cpu tweak enabled in bios. it makes the red circle. if in bios cpu tweak is off i get an amber circle. well anyway thats what i have found so far. i think its weird.
has anyone checked vista with sp1 with a 9850 installed? i would but im trying to install as little as possible right now while im tweakin my new set up. so those of you who have your system stable allready please check with the crystal program if the patch is still active in vista/sp1 with a 9850.
well i found out for myself with crystal cpuid lol the patch is off with a 9850 for sure or not please tell me what these numbers mean.
http://i278.photobucket.com/albums/k...g?t=1209800909
EDIT: http://valid.x86-secret.com/cache/banner/355583.png
hi guys i am new to the forum, but recognise a few faces from other places.
well i have been following this thread for a while, and also have a 9850BE, i have it at the moment in my Abit AX78. well the whole isnt it, is ithe Tlb lack of disablement affecting me.
so i decided to have a look at it and compiled the following results, all brand new instals with only needed hotfixes applied to Vista and XP (pre-sevice packs)
well have a look and see what you think.
http://img511.imageshack.us/img511/2...parisoneb4.jpg
this might be of use to someone here, so i decided to post it in this thread, i dont even know if its a dead thread, so my apoligies if this seems like thread digging :)
Should I be applying this if I have a Phenom II? I've had a go and it patched it, but I'm not entirely sure if it's needed since it's not the old K10 model.
if you have a B3 phenom or a phenom II it won't turn on the tlb patch. its only the affected B2 phenoms.
Alos, if you apply it, it will actually slow down the New Phenom II's...I tested this in RAR, and it took a 400KB/s hit.Quote:
Originally Posted by Halk
Awesome thread,
this just saved the performance of my Quad Opteron 8347HE ;)
Details here :)
Now if someone could tell me how I can run the *.rw file directly via shortcut without having to open the program and load the batch file, that would be awesome :)
The described method somehow doesn't work for me (when I click the shortcut nothing happens). And yeah I altered the path (it's "Programme (x86)" for me)