[Sammelthread] -= OC Prozessoren Intel Sockel 1155 (Sandy Bridge) Laberthread =- (7)

[nfszocker]

Sooo....für den Anfang nicht schlecht...

Hast Du jetzt doch 1:8 zum Laufen gebracht?

 

[Dancop]

yes

 

[mcpaschetnik]

Habe mal die gekaufte von webmile getestet,
nachdem ich die 4.5 mit 1.224 Vcore erreicht hatte ,war ich ein bisschen enttäuscht und
dachte das liegt am Gigabyte.Dachte mir die brauchen so oder so ein bisschen mehr Vcore.
Habe noch ein bisschen getestet und siehe da es geht doch,trotz Gigabyte...

kannst du mir mal bitte die wichtigsten bios-einstellungen durchgeben?

gruß

..::mcpaschetnik::..

 

[Hotzi1]

Habe llc auf level 5 stehen
Vcore und VTT fest eingestellt
sonst alles auf Auto

 

[mcpaschetnik]

also kein offset?

gruß

..::mcpaschetnik::..

 

[nfszocker]

yes

Woran lag's?

 

[Dancop]

Speicher...mein jetziger macht die o.g. Einstellungen sogar mit nur 1,59V!!!

 

[Hotzi1]

also kein offset?

gruß

..::mcpaschetnik::..

nein

 

[Gamer68]

Jep. Die einzigen Boards die signifikant besser laufen (aber scheinbar auch nicht alle) als andere Boards sind wohl das Asus P67 Maximus Extreme (nicht das Z68!) und das ASRock Z68 Extreme7.

Warum wissen die Götter ^^

Ich habe mal gelesen ,das unterschiedlicher vcore zustande kommt ,durch unterschiedliche Messpunkte ,ist für mich logisch ,die frage ist halt ,wieviel Einfluss nimmt es

 

[ralle_h]

Alter... ich komm grad gar nicht klar was hier gerade für ne Action abging...

Nachdem ich für etwas Platz gesorgt habe...



-> Lüfter oben nach außen, damit mehr Platz ist:



.... wollte ich nochmal für perlibu und co, die das mit den Temps genau wissen wollten, die NT-H1 gegen die MX-4 testen... und beim letzten Abbau des Kühlers verschwindet mir einer der scheiss Sicherungsringe bzw. Sprengringe des NH-D14:



Also aus Angst vor nem Kurzschluss (und ohne ihn konnte ich den NH-D14 ja schlecht wieder montieren, zumindest nicht perfekt) das Gehäuse kräftig durchgeschüttelt... aber keine Chance.

Also das MB ausgebaut... auf dem Tisch in alle Richtungen gedreht und gewendet... nichts. Das Gehäuse abgesucht... nichts.

Wollte das MB schon (total angepisst) wieder einbauen, da taucht der Schlawiner plötztlich doch auf und ist sogar noch ganz (wenn auch etwas ausgeleiert).

Auch mal ne Möglichkeit 2 Stunden Zeit zu verschwenden....

 

[Wernersen]

So kann es einem ergehen, aber besser als ein Kurzschluss.

 

[ralle_h]

Das stimmt allerdings.

Also hier der WLP Vergleich (~1°C Unterschied), die NT-H1 ist allerdings auch ne gute Paste, so isses ja nicht:

NT-H1:



MX-4:

 

[AndyX]

So, einige Seiten zuvor (bzw. vor ca. einer Woche) hatte ich geschrieben, dass ich mein UD4 gegen das Extreme4 Gen3 antreten lasse.

Jetzt ist es so weit!

Erste Erfahrungen:

1.) Die erste CPU braucht um ca. 0,05V weniger als zuvor (auf dem UD4 brauchte sie mind. 1,32V für 4,5GHZ)
2.) Eigenartigerweise verbraucht die CPU nicht weniger als zuvor (CoreTemp 1.0) und wird auch recht warm. (Tt SonicTower @ 3 Lüfter 1000rpm)
3.) Das Austauschen der Speicher von G.Skill Rippjaws-X 1333 CL7 8GB auf CORSAIR XMS3 1333 CL9 8GB brachte bisher keinen Erfolg in Bezug auf Vcorereduzierung!
4.) relativ hohe Vcore-Schwankungen (zB.: von 1,256 rauf auf 1,270, dann wieder 1,264)
kann man da was machen? Level 2-5 getestet...ausser höherer Vcore kaum ein Unterschied)

Ich werde jetzt noch meinen 2. 2600K testen und danach werde ich alles detailierter und mit Bildern posten. (vermutlich erst morgen Abend)

 

[RoE187]

Hey Leute,
wenn ihr schreibt oder es in eurer Signatur steht: "i7 2600k @4,5ghz-1,32V"
Meint ihr damit die Spannung,die unter Last anliegt oder die im Bios eingestellt wurde?

Meiner hat 1,26V im Bios und unter last 1,88v-1,22v@4,2ghz
Finde den Vdroop nur ein wenig Heftig.

mfg RoE187

 

[Gamer68]

0.08V ist normal ,wenn weniger umso besser

 

[ralle_h]

Hey Leute,
wenn ihr schreibt oder es in eurer Signatur steht: "i7 2600k @4,5ghz-1,32V"
Meint ihr damit die Spannung,die unter Last anliegt oder die im Bios eingestellt wurde?

Meiner hat 1,26V im Bios und unter last 1,88v-1,22v@4,2ghz
Finde den Vdroop nur ein wenig Heftig.

mfg RoE187

Zitat sieh Sig:

Merke: Sprechen Übertakter von ihrer Vcore (z.B. "meine CPU macht die 5 Ghz mit 1,36V"), meinen sie immer die Vcore, die im Windows unter Last anliegt (also nach dem Vdrop + Vdroop).

-

Hab mich nach der ganzen sinnlosen Bastelei mal wieder an die 5 Ghz gemacht.

Fenstermod in the house:

 

[Seph]

Hallo,

ich hatte jetzt zweimal einen Bluescreen mit Offset -120/130 über zwei Tage verteilt, beidesmale im Idle ohne Last. Unter Prime lief alles stable. Kann es dann trotzdem an der Übertaktung liegen? Ich kopiere mal die Fehlermeldung des BSOD hier rein...


Loading Dump File [C:\Windows\Minidump\112111-11840-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Unable to load image \SystemRoot\system32\ntoskrnl.exe, Win32 error 0n2
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`0320b000 PsLoadedModuleList = 0xfffff800`03450670
Debug session time: Mon Nov 21 23:03:11.747 2011 (UTC + 1:00)
System Uptime: 0 days 2:31:58.591
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Unable to load image \SystemRoot\system32\ntoskrnl.exe, Win32 error 0n2
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Loading Kernel Symbols
...............................................................
................................................................
.....................
Loading User Symbols
Loading unloaded module list
........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 3B, {c0000005, fffff8000328d050, fffff8800c231f60, 0}

*** WARNING: Unable to verify timestamp for mssmbios.sys
*** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
Probably caused by : ntoskrnl.exe ( nt+82050 )

Followup: MachineOwner
---------

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff8000328d050, Address of the instruction which caused the bugcheck
Arg3: fffff8800c231f60, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:
------------------

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: nt

FAULTING_MODULE: fffff8000320b000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

FAULTING_IP:
nt+82050
fffff800`0328d050 f04c2123 lock and qword ptr [rbx],r12

CONTEXT: fffff8800c231f60 -- (.cxr 0xfffff8800c231f60)
rax=fffffa800963a080 rbx=ffbdf88002f68280 rcx=fffff88002f68288
rdx=0000000000000000 rsi=fffffa8007e6ec20 rdi=0000000000000100
rip=fffff8000328d050 rsp=fffff8800c232940 rbp=0000000000000001
r8=fffff8000320b000 r9=0000000000000000 r10=fffffffffffffffb
r11=fffff88002f65100 r12=0000000000000000 r13=0000000000000000
r14=fffff88002f67380 r15=0000000000000068
iopl=0 nv up ei pl nz ac pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010212
nt+0x82050:
fffff800`0328d050 f04c2123 lock and qword ptr [rbx],r12 ds:002b:ffbdf880`02f68280=????????????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff8000328d050

STACK_TEXT:
fffff880`0c232940 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt+0x82050


FOLLOWUP_IP:
nt+82050
fffff800`0328d050 f04c2123 lock and qword ptr [rbx],r12

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt+82050

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntoskrnl.exe

STACK_COMMAND: .cxr 0xfffff8800c231f60 ; kb

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner


BSOD ZWEI:



Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\111911-11107-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\Windows\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: C:\Windows\System32
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`0325f000 PsLoadedModuleList = 0xfffff800`034a4670
Debug session time: Sat Nov 19 23:04:03.990 2011 (UTC + 1:00)
System Uptime: 0 days 4:12:46.208
Loading Kernel Symbols
...............................................................
................................................................
...................
Loading User Symbols
Loading unloaded module list
............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1E, {0, 0, 0, 0}

Probably caused by : ntkrnlmp.exe ( nt!KiKernelCalloutExceptionHandler+e )

Followup: MachineOwner
---------

3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: 0000000000000000, The exception code that was not handled
Arg2: 0000000000000000, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 0000000000000000, Parameter 1 of the exception

Debugging Details:
------------------


EXCEPTION_CODE: (Win32) 0 (0) - Der Vorgang wurde erfolgreich beendet.

FAULTING_IP:
+6262613530613233
00000000`00000000 ?? ???

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000000

ERROR_CODE: (NTSTATUS) 0 - STATUS_WAIT_0

BUGCHECK_STR: 0x1E_0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 2

EXCEPTION_RECORD: fffff88002fff268 -- (.exr 0xfffff88002fff268)
ExceptionAddress: fffff800032e741a (nt!KiProcessExpiredTimerList+0x000000000000004a)
ExceptionCode: c000001d (Illegal instruction)
ExceptionFlags: 00000000
NumberParameters: 0

TRAP_FRAME: fffff88002fff310 -- (.trap 0xfffff88002fff310)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000002 rbx=0000000000000000 rcx=fffffa8006f8e700
rdx=0000000000000102 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800032e741a rsp=fffff88002fff4a0 rbp=00000000000ed59a
r8=fffff88002fd9301 r9=0000000000000005 r10=000000000000009a
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
nt!KiProcessExpiredTimerList+0x4a:
fffff800`032e741a f00fba2b07 lock bts dword ptr [rbx],7 ds:f400:00000000`00000000=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800032d35fe to fffff800032dbc10

STACK_TEXT:
fffff880`02ffe348 fffff800`032d35fe : 00000000`00000000 fffff880`0f069002 fffff880`02ffeac0 fffff800`03307830 : nt!KeBugCheck
fffff880`02ffe350 fffff800`033074fd : fffff800`034e571c fffff800`03422c30 fffff800`0325f000 fffff880`02fff268 : nt!KiKernelCalloutExceptionHandler+0xe
fffff880`02ffe380 fffff800`033062d5 : fffff800`034260fc fffff880`02ffe3f8 fffff880`02fff268 fffff800`0325f000 : nt!RtlpExecuteHandlerForException+0xd
fffff880`02ffe3b0 fffff800`03317361 : fffff880`02fff268 fffff880`02ffeac0 fffff880`00000000 fffff880`02fff4c8 : nt!RtlDispatchException+0x415
fffff880`02ffea90 fffff800`032db2c2 : fffff880`02fff268 fffffa80`070c4c20 fffff880`02fff310 00000000`00000003 : nt!KiDispatchException+0x135
fffff880`02fff130 fffff800`032d941f : fffff880`02fff310 00000000`00172502 00000000`00000000 fffff880`00000000 : nt!KiExceptionDispatch+0xc2
fffff880`02fff310 fffff800`032e741a : fffffa80`06f8e720 fffffa80`070c4c68 fffffa80`070c4c68 00000000`00000102 : nt!KiInvalidOpcodeFault+0x11f
fffff880`02fff4a0 fffff800`032e737e : 00000023`4fc3bc9f fffff880`02fffb18 00000000`000ed59a fffff880`02fda8c8 : nt!KiProcessExpiredTimerList+0x4a
fffff880`02fffaf0 fffff800`032e7167 : 0000000b`5ab203c4 0000000b`000ed59a 0000000b`5ab2039d 00000000`0000009a : nt!KiTimerExpiration+0x1be
fffff880`02fffb90 fffff800`032d396a : fffff880`02fd7180 fffff880`02fe1fc0 00000000`00000001 fffff800`00000000 : nt!KiRetireDpcList+0x277
fffff880`02fffc40 00000000`00000000 : fffff880`03000000 fffff880`02ffa000 fffff880`02fffc00 00000000`00000000 : nt!KiIdleLoop+0x5a


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiKernelCalloutExceptionHandler+e
fffff800`032d35fe 90 nop

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!KiKernelCalloutExceptionHandler+e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3

FAILURE_BUCKET_ID: X64_0x1E_0_nt!KiKernelCalloutExceptionHandler+e

BUCKET_ID: X64_0x1E_0_nt!KiKernelCalloutExceptionHandler+e

Followup: MachineOwner

 

[Wernersen]

was geht ?

 

[Hums]

ralle ralle ralle ...langsam müsstest du doch durch sein mit testen oder ...Das gleiche hab ich auch gerade gedacht Wernersen...

 

[ralle_h]

Bin Perfektionist Leute... und geb mich nicht geschlagen, bevor die 1,296V stehen

@Seph: Nimm doch Bluescreenview und poste nen Screen davon

 

[Wernersen]

Einfach die Endung des Fehlercode merken!

3. Fehlersuche - Bluescreens und ihre Bedeutungen:

0x101 = VCore 0x124 = VCore oder QPI/VTT Voltage (Meist Vcore)
0x50 = RAM Timings/Frequency, VDimm oder für Feintuning QPI/VTT Voltage
0x1E = VCore 0x3B = VCore
0xD1 = QPI/VTT Voltage
0x9C = Meist QPI/VTT Voltage, manchmal auch VCore.
0X109 = VDimm
0x0A = QPI/VTT voltage

 

[Maneus Calgar]

so mal wieder auf 4,5 mit dem 2500K
Ram ist auf 1333 festgesetzt
Load-line Calibration auf Ultrs High
Duty Control auf T. Probe
CPU Voltage auf Offset
so läuft er 8h und mehr im prime, zocken geht alles super
nur beim hochfahren hängt er immer 1-2 mal im booten
stock bootet er normal
was ist der grund ? bin da leider nicht so bewandert

 

[Wernersen]

@ seph

dein Bug-Check 0x3B = VCore

---------- Beitrag hinzugefügt um 23:54 ---------- Vorheriger Beitrag war um 23:51 ----------

so mal wieder auf 4,5 mit dem 2500K
Ram ist auf 1333 festgesetzt
Load-line Calibration auf Ultrs High
Duty Control auf T. Probe
CPU Voltage auf Offset
so läuft er 8h und mehr im prime, zocken geht alles super
nur beim hochfahren hängt er immer 1-2 mal im booten
stock bootet er normal
was ist der grund ? bin da leider nicht so bewandert

Hatte mal jemand gepostet, dass es eine Einstellung bei den Asus gibt die das Problem behebt. Leider weiß ich nicht mehr was das war.

 

[Seph]

Danke. Habe VCORE etwas angehoben. Hoffentlich hilft es.

 

[ralle_h]

Fenstermod kann alles



1,304 ist damit durch

 

[Gelöschtes Mitglied 22910]

So was suche ich schon lange beim 2600k....geile Cpu.

 

[ralle_h]

Danke

Für 1,296V muss ich aber alle Register ziehen wenn das überhaupt läuft, VTT und VDIMM ist schon perfekt ausgelotet, wenn mit PLL nix geht siehts schlecht aus

Aber das test ich morgen weiter, bzw. auch erstmal die neue CPU die morgen ankommt, ob die auch so gut geht auf dem Extreme 7

 

[Gelöschtes Mitglied 22910]

was hat sie auf dem Gigabyte benötigt.?

 

[ralle_h]

1,368V für die 5,0 und ~72°C (auch mit Fenstermod, aber da wars paar Gräder wärmer noch draußen)

 

[websmile]

Waere eigentlich logischer du kaufst dir das Board - ist einfacher, wenn die CPU vorher auf einem anderen Board 1,368V gebraucht hat hast du da bessere Aussichten^^