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

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ist doch logisch- es ist einfacher eine CPU die man hat durch ein besseres Board zu optimieren als ewig zu suchen- ich zum beispiel wurde eher das Board wechseln bevor ich meine CPU wechsel, die macht 5GHz mit 1,35V auf einem M4Gene, dann sollte wenns wie bei dir laeuft auch auf einem 7 weniger gehen. War fuer Microborg gedacht ;)
 
Schon wieder ein BSOD. :( Obwohl ich VCORE um -10 angehoben hatte. Schon wieder im Idle (diesmal vielleicht nicht 100% idle). Kurz davor ahtte ich ohne Probs 90 Minuten BF3 laufen... :stupid:

Hier der Error Code. Immer noch zu wenig VCORE?



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


Loading Dump File [C:\Windows\Minidump\112211-15615-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
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** 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`0325a000 PsLoadedModuleList = 0xfffff800`0349f670
Debug session time: Tue Nov 22 01:06:02.792 2011 (UTC + 1:00)
System Uptime: 0 days 2:01:40.010
*********************************************************************
* 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
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** 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 7A, {fffff6fc40006eb8, ffffffffc0000185, 1e6289860, fffff88000dd793c}

*** WARNING: Unable to verify timestamp for mssmbios.sys
*** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys
Unable to load image \SystemRoot\system32\drivers\ataport.SYS, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ataport.SYS
*** ERROR: Module load completed but symbols could not be loaded for ataport.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 : ataport.SYS ( ataport+1e93c )

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

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

KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.
Arguments:
Arg1: fffff6fc40006eb8, lock type that was held (value 1,2,3, or PTE address)
Arg2: ffffffffc0000185, error status (normally i/o status code)
Arg3: 00000001e6289860, current process (virtual address for lock type 3, or PTE)
Arg4: fffff88000dd793c, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)

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: ataport

FAULTING_MODULE: fffff8000325a000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce79293

ERROR_CODE: (NTSTATUS) 0xc0000185 - Das E/A-Ger t hat einen E/A-Fehler gemeldet.

DISK_HARDWARE_ERROR: There was error with disk hardware

BUGCHECK_STR: 0x7a_c0000185

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80003347b52 to fffff800032d6c40

STACK_TEXT:
fffff880`031c41c8 fffff800`03347b52 : 00000000`0000007a fffff6fc`40006eb8 ffffffff`c0000185 00000001`e6289860 : nt+0x7cc40
fffff880`031c41d0 00000000`0000007a : fffff6fc`40006eb8 ffffffff`c0000185 00000001`e6289860 fffff880`00dd793c : nt+0xedb52
fffff880`031c41d8 fffff6fc`40006eb8 : ffffffff`c0000185 00000001`e6289860 fffff880`00dd793c ffffffff`ffffffff : 0x7a
fffff880`031c41e0 ffffffff`c0000185 : 00000001`e6289860 fffff880`00dd793c ffffffff`ffffffff 00000000`c0000185 : 0xfffff6fc`40006eb8
fffff880`031c41e8 00000001`e6289860 : fffff880`00dd793c ffffffff`ffffffff 00000000`c0000185 fffffa80`00000000 : 0xffffffff`c0000185
fffff880`031c41f0 fffff880`00dd793c : ffffffff`ffffffff 00000000`c0000185 fffffa80`00000000 fffff880`00dd793c : 0x1`e6289860
fffff880`031c41f8 ffffffff`ffffffff : 00000000`c0000185 fffffa80`00000000 fffff880`00dd793c fffff800`032febc5 : ataport+0x1e93c
fffff880`031c4200 00000000`c0000185 : fffffa80`00000000 fffff880`00dd793c fffff800`032febc5 fffffa80`079fcbc0 : 0xffffffff`ffffffff
fffff880`031c4208 fffffa80`00000000 : fffff880`00dd793c fffff800`032febc5 fffffa80`079fcbc0 fffffa80`079fcbc0 : 0xc0000185
fffff880`031c4210 fffff880`00dd793c : fffff800`032febc5 fffffa80`079fcbc0 fffffa80`079fcbc0 fffffa80`06d37b60 : 0xfffffa80`00000000
fffff880`031c4218 fffff800`032febc5 : fffffa80`079fcbc0 fffffa80`079fcbc0 fffffa80`06d37b60 fffffa80`05b279b0 : ataport+0x1e93c
fffff880`031c4220 fffffa80`079fcbc0 : fffffa80`079fcbc0 fffffa80`06d37b60 fffffa80`05b279b0 00000000`00002000 : nt+0xa4bc5
fffff880`031c4228 fffffa80`079fcbc0 : fffffa80`06d37b60 fffffa80`05b279b0 00000000`00002000 fffff6fc`40006eb8 : 0xfffffa80`079fcbc0
fffff880`031c4230 fffffa80`06d37b60 : fffffa80`05b279b0 00000000`00002000 fffff6fc`40006eb8 ffffffff`ffffffff : 0xfffffa80`079fcbc0
fffff880`031c4238 fffffa80`05b279b0 : 00000000`00002000 fffff6fc`40006eb8 ffffffff`ffffffff 00000000`00000000 : 0xfffffa80`06d37b60
fffff880`031c4240 00000000`00002000 : fffff6fc`40006eb8 ffffffff`ffffffff 00000000`00000000 00000000`00000000 : 0xfffffa80`05b279b0
fffff880`031c4248 fffff6fc`40006eb8 : ffffffff`ffffffff 00000000`00000000 00000000`00000000 fffffa80`07f3eca0 : 0x2000
fffff880`031c4250 ffffffff`ffffffff : 00000000`00000000 00000000`00000000 fffffa80`07f3eca0 fffff800`0350c500 : 0xfffff6fc`40006eb8
fffff880`031c4258 00000000`00000000 : 00000000`00000000 fffffa80`07f3eca0 fffff800`0350c500 fffffa80`05b279b0 : 0xffffffff`ffffffff


STACK_COMMAND: kb

FOLLOWUP_IP:
ataport+1e93c
fffff880`00dd793c fc cld

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: ataport+1e93c

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ataport.SYS

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------
 
websmile schrieb:
Ist doch logisch- es ist einfacher eine CPU die man hat durch ein besseres Board zu optimieren als ewig zu suchen- ich zum beispiel wurde eher das Board wechseln bevor ich meine CPU wechsel, die macht 5GHz mit 1,35V auf einem M4Gene, dann sollte wenns wie bei dir laeuft auch auf einem 7 weniger gehen. War fuer Microborg gedacht ;)
Zum Vergrößern anklicken....

Ja, nur muss man das vorher wissen :d

Vor allem ist das GB UD-4 B3 ja nicht schlecht... hatte das Z68X-UD4 da, das war nochmal nen paar Stufen schlechter. Von MSI brauchen wir gar nicht erst zu reden ^^

-

Seph: Du weigerst dich aber auch vehement zu lesen was schon geposted wurde, oder?

Dein ganzer Paste ist unnötig... es reicht eine Zeile davon: Der Fehlercode (den ich jetzt, um auch mal faul zu sein, nicht suchen werde). Oder du guckst auf die letzte Seite, da hats Wernersen eh schon gepostet: http://www.hardwareluxx.de/community/17934413-post15413.html (oder in das Tutorial in meiner Sig).
 
Zuletzt bearbeitet:
@Seph

das sieht nicht gut aus,da müssen wir einen neuen Pc zusammen stellen.
Da liegt ein schwerer Hardware Fehler vor,der nur durch anheben der Vcore behoben werden kann.

:heul:
 
Moin!:wink:

Dancop schrieb:
Speicher...mein jetziger macht die o.g. Einstellungen sogar mit nur 1,59V!!!
Zum Vergrößern anklicken....

Welchen Speicher hast Du jetzt?

@Seph

Mach folgendes:
Start\Systemsteuerung\System und Sicherheit\System\Erweiterte Systemeinstellungen\Starten und Wiederherstellen\Einstellungen\ bei Systemfehler den Hacken bei: Automatisch Neustart durchführen, rausnehmen!
Dann bleibt Dein Bluescreen stehen und Du kannst in aller Ruhe nachschauen, wie die Endung von dem Bluescreen ist, z.B 101/124/03B/09C/01A usw, das kannst Du dann hier posten und vor allem, brauchst Du keine 2 DIN-A4 Seiten mehr für!;)
 
Microborg schrieb:
@Seph

das sieht nicht gut aus,da müssen wir einen neuen Pc zusammen stellen.
Da liegt ein schwerer Hardware Fehler vor,der nur durch anheben der Vcore behoben werden kann.

:heul:
Zum Vergrößern anklicken....

you made my day :lol:

Glaubt es oder nicht... seit ich nicht mehr OCe(n kann) lebe ich viel ruhiger, Power ist auch so ohne ende vorhanden... so langsam bin ich richtig froh so eine "Krücke" erwischt zu haben - der ist so genial kühl trotz kozuti... bin happy :banana:
 
Maneus Calgar schrieb:
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
Zum Vergrößern anklicken....

Hängt damit zusammen, dass Spannungen und Frequenzen beim OC von CPU und Speicher unabhängig voneinander gesetzt werden und es deswegen zu diesem kleinen restart kommt. Beim X58-UD7 von GB ist das auch so.
 
Moin Leute

Wollte mal nachfragen ob sich mein frisches System als 24/7 stable bezeichnen lässt.

CPU:
I5 2500K @ 4.0 Ghz
CPU Kern Load: 1.094V - 1.104V
CPU Kern Idle: 0.85V
CPU PLL: 1.6V
LLC OFF

Test:
5H Linx ohne Fehler
2H Prime Custom ohne Fehler
F1 2011 und Battlefield 3 ohne abstürze


(Beim Screenshot war Prime noch nicht durch, jetzt sind es schon 3h)

Gekühlt wird das ganze mit einer Corsair H60 Push/Pull mit zwei Slipstreams @ 750RPM. Denke Temps sind ok oder?

Wie ich ihm Thread gelesen habe, scheint der CPU nicht der schlechteste zu sein. 4Ghz bei 1.1V hätte ich dem kleinen nicht zugetraut. Mein Standard Setting ist normalerweise Stock+Turbo @ 1.024V, macht auch 5h Linx ohne Probleme.

Soll ich noch was testen, oder kann ich es so belassen?

Grüsse
 
Zuletzt bearbeitet:
ralle_h schrieb:
Ja, nur muss man das vorher wissen :d

Vor allem ist das GB UD-4 B3 ja nicht schlecht... hatte das Z68X-UD4 da, das war nochmal nen paar Stufen schlechter. Von MSI brauchen wir gar nicht erst zu reden ^^

-

Seph: Du weigerst dich aber auch vehement zu lesen was schon geposted wurde, oder?

Dein ganzer Paste ist unnötig... es reicht eine Zeile davon: Der Fehlercode (den ich jetzt, um auch mal faul zu sein, nicht suchen werde). Oder du guckst auf die letzte Seite, da hats Wernersen eh schon gepostet: http://www.hardwareluxx.de/community/17934413-post15413.html (oder in das Tutorial in meiner Sig).
Zum Vergrößern anklicken....

Ja, aber 185 steht nicht drin...
 
Die richtige Prime-Version 26.6 für x64 OS 2-4h Custom-stable und gut ist es, denn Rest zeigt der Alltag. Bei Linx braucht man wohl auch das neue Linpack sonst taugt es nicht.
 
Zum Glück gibt es unterschiedliche Meinungen... kein Blend-Test mit RAM inklusive? Ist für mich nicht stable... dann 1h? niemals...

aber wie gesagt... jedem das seine. Ich weiß lieber das mein System in jeder Lebenslage stable ist als das ich irgendwo dann nen Ausfall des Systems oder einen Speicherfehler habe wo ich hin am wenigsten gebrauchen kann. :wink:
 
Zuletzt bearbeitet:
Ok, hab mir gerade mal Intel Linpack x64 gezogen.
Mach mal nen run mit den Daten:

Sample Intel(R) LINPACK data file (lininput_xeon64)
Intel(R) LINPACK data
1 # number of tests
30000 # problem sizes
30000 # leading dimensions
200 #times to run a test
4 # alignment values (in KBytes)

Mir ist es schon wichtig, dass ein 24/7 Setting auch wirklich stabil ist.
Wenn ich schon mehrere Stunden brauche um Vcore etc. zu ermitteln, kommt es auf die paar stunden testing auch nicht mehr an. :-)

Edit: Linpack scheint gut zu arbeiten, heissester Core ist jetzt 60 Grad, 3 Grad wärmer als unter Linx und Prime.
 
Zuletzt bearbeitet:
@Lextra: welchen Wert hast du im Offset Mode eingestellt?
 
Neuer 2500k ist da: #313A836

Gewissenskonflikt:

[ ] Einbauen und riskieren wieder 2 Stunden den scheiss Sprengring suchen zu müssen (http://www.hardwareluxx.de/community/17933681-post15402.html)
[ ] Füße still halten bis die Ersatzteile von Noctua da sind (wurden heut schon los geschickt, Noctua Support beste <3)
 
Ja, Noctua ist echt spitze, hatte auch mal Probleme mit den Lüfterklemmen und Kabeln, und die haben nen kompletten Kit geschickt. Nur der Kühler und die Lüfter haben noch gefehlt, dann wäre es Komplett gewesen ;)


Musst bei Ausbau halt nur rechtzeitig zugreifen dann hopst er nicht rum.
 
@eyedexe

Bin jetzt bei der Arbeit, darum weiss ich es nicht genau. Aber wenn ich mich nicht täusche sind es - 0.145V. Habe auf dem Asus Board sonst alle "Overvolting, ich bin ein pseudo OC Board Features" abgeschaltet.
Werde aber heute Abend nochmals nachschauen und berichten. CPU PLL ist auch auf 1.6V (default 1.8V)
 
mit der PLL vorsichtig sein, auch ein falscher Wert kann zu instabilität führen ;)

immer erst mal mit PLL 1,8 V die VCore ausloten und wenn die feststeht, dann kann man versuchen über die PLL-Senkung die VCore noch zu drücken.

Nicht an 5 Schrauben drehen und dann nicht wissen woran es liegt wenn ein Fehler kommt

101 und 124 sind nicht immer VCore :wink:
 
@kaspar33333

Ist die Cpu angekommen,wenn ja einbauen und mir direkt bescheid geben was mit der Perle los ist.
 
ist da aber ich bin noch auf der Arbeit und heute ist noch essen mit der Schwiegermutter, aber ich bau sie heute noch ein und gleich mal die 5900 testen

ähmm meine die 4500 ;)
 
So jetzt kann man es wohl sagen, dass die kleine i5 stabil zu sein scheint! =)
Jetzt wird der kleine nicht mehr gequält.. =)

2 Stunden Prime
5 Stunden Linx
2 Stunden Linpack
Und mehrer Stunden CPU Lastige Games ohne Abstürze oder BSOD.

4.0 Ghz bei 1.1V im Offset, bin erstmals zufrieden. Test gegen die 5 Ghz werden noch folgen, werde aber sehr warscheinlich schnellere Lüfter für die H60 brauchen.

Bei Aida64 wird ja ein Wert ausgelsen in Watt, die ja den Stromverbrauch der CPU messen sollte. Wie verlässlich ist dieser Wert?
Prime und Linx = 59 Watt @ Vollast bei Stock@ 1.024V
Prime und Linx = 78 Watt @ Vollast bei 4.0 bei 1.1V
Linpack = 108 Watt @ Vollast bei 4.0 bei 1.1V

Kann es sein, dass es ein so grosser Unterschied gibt zwischen Linx/Prime und Linpack?
Die CPU wird bei Linpack um einges wärmer als bei Linx/Prime, aber gleich 30 Watt mehr?
Kann das sein?

Grüsse
 
kaspar33333 schrieb:
ist da aber ich bin noch auf der Arbeit und heute ist noch essen mit der Schwiegermutter, aber ich bau sie heute noch ein und gleich mal die 5900 testen

ähmm meine die 4500 ;)
Zum Vergrößern anklicken....

:fresse::wall::fresse:

Nur nicht schreiben das sie bootet mit 59,dann bin ich selbstmord gefärdet:d
 
Kann schon sein, dass dieses Intel Linpack ordentlich bruzzelt.
Ich meinte das LinX AVX Linpack
Am besten ist immer noch Prime 26.6. selbst wenn LinX durchläuft gibt es mit Prime Fehler.
Wenn das System beim Spielen läuft, scheint es ja schon stabil zu sein.
Video's Encodieren mit AVS-Converter ist auch noch ein guter Test.
 
Ja die version hatte ich auch laufen.
Die bruzzelt ganze 5° mehr als Prime 64 26.6
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh