[Sammelthread] Gigabyte GA-EX58-UD5 / Extreme (Intel X58) [4]

Status
Für weitere Antworten geschlossen.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
...habe die DVID im OC verbessern lassen... kunden können die vorab bei mir zum testen downloaden...
 
wie kann man sich die verbesserungen vorstellen und wann gehts denn an alle nicht-kunden raus? (ich könnt ja schliesslich auch mal kunde werden ;))

wenn du schon im kontakt mit den mädelz bist...ein auf hdd abspeicherbares bios-profil wäre ein traum (hab das ud5, weiss net, obs beim extreme etc schon geht...) :drool:

:wink:

btw is extreme ruhig geworden hier im fred, die clockergemeinde ist wohl schon wieder aufs nächste mobo umgezogen?

btw2 ach, erwähnte ich regelbare non-pwm lüfterausgänge per speedfan? ;)
 
Zuletzt bearbeitet:
Hallo Zusammen

Ich wollte euch bezüglich Mod Bios (Raid Treiber Mod) fürs GA EX58 Extreme was fragen.

Kann man so ein Raid/AHCI (zb. 9.6.0.1014) Mod Bios bei bestehendem Raid eigentlich flashen ohne das es dass komplette Raid zerschiesst?

Danke schon mal ;)

Gruss Bensdale
 
Hab vorhin erst das GA-EX58-EXTRME 13C Mod BIOS (Intel RaidAhci version 9.6.0.1014 - Realtek Lan Controller Series v2.34) aufgespielt. Habe RAID 0 (2x SSD 64GB).
Neuer IntelTreiber wir im BIOS Post angezeigt... normaler Boot....usw.

Natürlich VOR dem ersten Hochfahren gleich ins BIOS und RAID wieder anstellen (und alles wieder herrichten)!
Aber das versteht sich denke ich von selbst....

Alles ohne Probleme!
 
Zuletzt bearbeitet:
...es wird die tage nochmal ne neue version geben, weil @Horsi mich auf ein problem mit der neuen version aufmerksam gemacht hatte...

seit monaten war ich dran, ein bug aus dem bios zu bekommen... stellte sich als schwierig raus, da taiwan das problem nie nachvollziehen konnte... bis ich feststellte, dass das nur mit bestimmten VIDs mit den D0 CPUen auftrat... also nicht bei allen Typen...

bug: bei oc 200x20 und der verwendung von der DVID, gab es neustart/s3 probleme...

in taiwan war keine der CPUen zu beziehen, der diesen blöden bug zeigte... habe dann eine cpu nach taiwan geschickt und dann erst konnte man das problem dort sehen...

daraufhin gab es beim UD7 ein bios update, das ich positv getestet hatte... alles hatte ich geprüft, nur nicht den minusDVID bereich :-/

durch meine rückmeldung hatte man für alle X58 biose gemacht...

reklamation läuft und ist in arbeit...
 
Zuletzt bearbeitet:
ist es der DVID BUG, wo der rechner @ 20 x 200 + DVID aus heiterem himmel einen BSOD auslöst ??

mir ist das nämlich auch schon ein paar mal passiert, das der rechner einfach mal abgeschmiert ist, und das obwohl sonst alles bei mir stabil ist, sprich LINX läuft ewig ohne einen absturz durch, und MEMTEST zeigt auch keine fehler an !!

mal ist der rechner eine ganze woche ohne einen einzigen absturz durchgelaufen, und dann waren es an einem tag gleich mehrere BSOD !!

liegt das also an DVID + S3...
 
...ansich nein

dann wirst du zu wenig DVID gegeben haben, so dass im idle/load die CPU zu wenig spannung bekommt... also einfach ein taken höher, damit der idle auch stabil bleibt... ist aber immer von der CPU abhängig der jeweiligen VID selbst...

nachtrag:

der bug zeigt sich so, dass beim win neustart das netzteil ganz ausgeht und wieder dreimal inialisiert oder aus dem S3 nicht mehr raus kommt oder beim win neustart bei C1 hängen bleibt...

aber wie schon erwähnt, es machen nicht alle CPUen, sondern nur einige :-/

nachtrag2:

kommt auch auf die loadline calibrations einstellung an... disabled (nach intel(r) standard) braucht immer mehr +DVID, da der vdroop mit berechnet werden muss...
 
Zuletzt bearbeitet:
das dumme ist nur, das wenn ich das DVID etwas höher einstelle, dann auch die maximale spannung @ last höher als benötigt bei mir anliegt !! :(

eigentlich sollte das DVID einstellbar sein, so das man die unterste & oberste spannungsgrenze selbst bestimmen kann!!

wenn denen in TW mal langweilig sein sollte, können die ja mal so ein "sinnvolles" feature in die BIOSe reinprogramieren !!
 
...das ist leider nicht möglich... das offset bezieht sich auf die VID und das ist je CPU anders... dann musst du das mit der loadline calibration ausgleichen... also am besten auf standard bzw. disabled setzen... dann bekommst du auch im idle bereich mehr vcore... aber berechne für dvid den vdroop mit ;-)

nachtrag:

aber nochmal, normalerweise reicht nur 1 schritt höher und da wirst du wohl bei last nicht übermäßig mehr vcore haben ;-)
 
Zuletzt bearbeitet:
...wäre es wenigstens möglich die schritte etwas kleiner zu machen ???

z.b. statt in 0.00625V nur noch in 0.00250V schritten ???
 
Druss schrieb:
Nochmal: was meinst du denn bitte, was auf dem Mainboard entscheidend dafür ist, dass du einen hohen Uncore fahren kannst? Das Mainboard ist da so ziehmlich unwichtig...
Zum Vergrößern anklicken....

Dachte immer das Board sie auch entscheidend. Leider brauch ich höhere VCore Werte bei ner höheren Uncore...deswegen lohnt es sich meiner Meinung nach nicht, fie UNCore höher als den RAM (x2) laufen zu lassen.
 
sanic schrieb:
Hi all

bewirken die Einstellungen im bios bei CPU Clock Skew irgendwas ?
Zum Vergrößern anklicken....
Ist eine Frage,die ich mir auch immer wieder gestellt habe. Heute hab ich 2 Tests gefahren, wo es einen Unterschied gemacht hat,jedoch ich nicht 100% sagen kann, ob die Skews den Ausschlag gegeben haben.

Hab einen 920-er bei 19x200 mit HT mit boxed-Kühler getestet im VCore-Grenzbereich mit Prime-Small getestet. Beide male bei gleicher VCore und gleichen Temps von konstanten 75Grad. Beim ersten Run verwendete ich die Skews 800 und 900, wie man sie untereinander einstelln kann. Im 8K-Test flog ein Kern nach 12min raus.

Nun wechselte ich wieder zu den Standardwerten von 700 und 700. Dabei beobachtete ich die Temps genau.Wieder 75Grad und wartete bis einer der Kerne wieder versagt. Doch diesmal ging die Sache durch. Ob das nun Zufall oder nicht war,kann ich nicht sagen. Wiederholte den Test aus Zeitgründen, da ich wegging nicht nochmal. Wenn ich die Zeit finde,werd ichs nochmal testen, da ich selbst neugierig bin,wo man immernoch ein bischen mehr was reissen kann.

MAX-BCLK
Wollte noch kurz die Frage stellen, wie weit inzwischen das UD5 mit Max-Bclk geht ohne Anhebung des PCI-E-Taktes.Hatte mal irgendwo gelesen, dass bei den ersten Boards immer irgendwie bei 210 SChluss war, unabhängig von der VTT/QPI-Spannung und Uncore/Speichertakt. Gibt es dazu irgendwelche neuen Infos? Haben Bios-Updates da was zwischenzeitlich gebracht oder hängt das nur von jeweiligen Board-Exemplar und der verwendeten CPU ab? Was habt ihr für Max-Bclk erreicht auf dem Board`? Ich fahre aktuell 210 mit niedrigen Spannungen.
 
Zuletzt bearbeitet:
k das macht tatsächlich Sinn.
Da ich sowas noch nie verbaut habe / nie verbauen werde hab ich son Teil noch nie gesehn lol^^

Thx für die Info
 
@Last Hero, ich mach gerade nen MAX.BCLK Test.

Und mit 1,75VCore (1,12V unter Windows) ohne Anhebenung der IOH oder VTT komme ich schon locker auf 220 (12er Multi). Werde gleich 230 versuchen...mal schauen ob das dann immer noch so ohne weiteres klappt.

Sooo nach ausgibegem Testen:

221 geht noch mit PCIE Takt 100,
Ab BLCK 222 brauch ich 101. Wie weit er wirklich geht, werde ich nicht austesten, da ich 221 in Ordnung finde und ich ne HD5870 ohne Garantie in meinem Rechner hab.
 
Zuletzt bearbeitet:
das virtuelle jz-bios fängt bei der vcore bei 1,23v an, bei mir aufm rechner bei 1,26. ist das vid-abhängig?
 
Status
Für weitere Antworten geschlossen.

Ähnliche Themen

Scoty
  • Artikel
[Sammelthread] ASRock Phantom Gaming X870E Nova WiFi (AM5)
5 6 7
Antworten
188
Aufrufe
9K
ApolloX
ApolloX
Beinfreiheit
[User-Review] Lesertest mit ADATA/XPG und ASUS
Antworten
4
Aufrufe
308
FirstAid
FirstAid
S
alten Rechner Aufrüsten für die nächsten Jahre (CPU, MB, RAM neu)
Antworten
20
Aufrufe
1K
Sixtus
S
emissary42
[Sammelthread] Intel LGA1851 Mainboard Laberthread (Z890 / W880 / Q870 / B860 / H810)
36 37 38
Antworten
1K
Aufrufe
50K
TheLastC64User
T
mantiz
[Sammelthread] Intel Core Ultra (Arrow-Lake-S) S.1851 OC- und Laberthread
13 14 15
Antworten
441
Aufrufe
21K
einfachnurso
E
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