Hirdetés
- Örömkönnyek és üres kezek a TriFold startjánál
- iPhone topik
- Töltő már van a Galaxy S26 Ultrához
- Apple iPhone 17 Pro Max – fennsík
- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- Apple iPhone 16 - ígéretek földje
- iOS alkalmazások
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Google Pixel 9a - a lapos munka
- Xiaomi 14T Pro - teljes a család?
Új hozzászólás Aktív témák
-
Fiery
veterán
válasz
Oliverda
#3238
üzenetére
Az Unknown arra utal, hogy valami miatt a BIOS tartalma nem erheto el. UEFI modban indulva nem mindegyik alaplap emulalja be a klasszikus video- es rendszer BIOS szegmenseket (C000 es F000), sajnos, es ilyenkor nehezkesse valik a BIOS datumok es BIOS tipusok felismerese. A GPU oldalon mas modszerrel, kozvetlenul a video BIOS flash chipbol (csak dGPU eseten) tortenik a BIOS tartalom kiolvasasa, es olyankor nem jelent akadalyt a klasszikus BIOS emulacio nelkuli mukodes sem.
A PSCheckhez hasonlo kimenetet valoban tervezunk, es amint lathatod a CPUID & MSR Dump-ban, mar megtettuk az elso lepeseket
Sok dolognak kell azonban egybe allnia, tobb reszet is kell az AIDA64-nek ahhoz modositani, hogy megbizhato, normalis kimenetet tudjunk adni minden core-rol, minden PState allapotrol, minden orajelrol, stb. Raadasul -- jelenlegi ismereteink szerint --, ez leginkabb csak AMD processzorokon mukodhet olyan szepen, olyan vilagosan reprezentalhato modon, mint a PSCheckben, de me'g kutatunk, hatha Intel procikon is tudnank hasonlot produkalni. Jelenleg azonban teljes gozzel a GPGPU benchmarkokon dolgozunk, hamarosan megjelenik stabil kiadasban is, viszont utana meg a HSA-val es ujabb GPGPU benchmarkokon kezdunk dolgozni, ugyhogy nem tudom most megigerni, hogy a PState- es orajel monitorozo modul mikorra fog tudni elkeszulni
Sajnos az ilyen specifikus, nagyon szuk kör szamara hasznos modulokat kenytelenek vagyunk hatrebb sorolni a fejlesztesnel, amikor olyan nepszeru feature-okon kell dolgoznunk, mint a GPU benchmarkolas 
-
Fiery
veterán
válasz
Oliverda
#3232
üzenetére
Jelenleg nincs erre lehetoseg, de tervezzuk, hogy a BCDEDIT /ENUM parancssorhoz hasonlo kimenetet mi is produkalunk egy uj AIDA64 oldalon, aminek resze lesz a Windows Boot Loader leirasa. Annal pedig latszodik elvileg, hogy .EXE (BIOS boot) vagy .EFI (UEFI boot) fajlt hasznalt-e a Windows a boothoz.
Videokartya BIOS-anak UEFI kepessegeirol nincs semmilyen informacionk, ennek utana kell neznunk. Ez is jo tipp

-
Fiery
veterán
válasz
Oliverda
#2976
üzenetére
Az alapjan, hogy most mekkorara van allitva a max. log meret, es hogy idoben meddig lat "vissza" az AIDA64, ki tudod szamolni, hogy havonta mennyivel no a log merete. De nem hiszem ,hogy a System Log ilyen nagyra tudna noni, hacsak nem hagyod 100 evig futni a Windowst

-
-
Fiery
veterán
válasz
Oliverda
#2970
üzenetére
Oda van irva a lap aljara
Azt persze tudni kell hozza, hogy az Esemenynaploknak van egy elore konfiguralt maximalis meretuk, es ha azt atlepik, akkor a Windows elkezdi a legregebbi esemenyeket kihajigalni belole. Tehat ha az elso boot ideje nem tunik realisnak, akkor meg kell novelni (mondjuk tizszeresere legalabb) a System Event Log meretet, es ugy tovabb lesz relevans az UpTime statisztika. -
Fiery
veterán
válasz
Oliverda
#2402
üzenetére
Sejtem, hogy mi okozhatja. Beraktunk nehany specialis feszultseget (vDIMM, vHT, vNB), es valoszinuleg az akad ossze vagy a BIOS-szal, vagy az F-Stream-mel. Privatban kuldok majd egy teszt buildre linket, hogy ki tudd probalni, lefagy-e ugy is, hogy kivesszuk ezeket a speci feszultsegeket.
-
Fiery
veterán
válasz
Oliverda
#2399
üzenetére
Megjott
Sajnos az AGESA-nak nem latom nyomat a BIOS dump-okban
A nem-EFI BIOS-oknal "AMD!GESA"-ra kellett rakeresni a BIOS-ban, es ott volt mellette a verzioszam. Ha az ASRockkal dumalsz, esetleg probald meg megtudni toluk, hogy EFI BIOS-nal hogyan lehet lekerdezni az AGESA verzioszamat. Gondolom az AMD Overdrive tudja ezt, ugyhogy velhetoen megoldhato Windows alatt is valahogyan. -
Fiery
veterán
válasz
Oliverda
#2395
üzenetére
BIOS bug: a deli hidhoz tartozo PCI Express Root Port device-oknal (43A0, 43A1, 43A2, 43A3) nincs kitoltve precizen a port sorszama es az aktiv uzemmod.
A hiba furcsa. Eddig nem tapasztaltal ilyet? Win7 64-bit az oprendszer? Tudnal kuldeni screen shot-ot a problemas oldalrol? (Storage / Logical Drives).
Koszi

-
Fiery
veterán
válasz
Oliverda
#2393
üzenetére
A kovetkezo betaban javitjuk a ventilatorokat, azonban a "CPU Fan2"-t sajnos nem tudjuk mérni, ugyanis az ASRock egy eleg bena mux-os megoldast alkalmaz, amit csak a sajat programjaik (F-Stream / OC Tuner / XTU) tudjak hellyel-kozzel rendesen kezelni.
Az SB950 eseteben csak a 4 "valodi" PCI-E portot listazzuk. Ahogy lathatod is, a port magarol azt allitja, hogy x1 savos, de az aktiv szelesseg viszont x16, es a port sorszama is bizarr
Ez, valamint az a problema, hogy hasznalatban levonek mutatja magat (mikozben nem latszik semmilyen csatlakoztatott PCI-E eszkoz) egy BIOS bugnak koszonheto. Nem kritikus hiba, hiszen csak a diagnosztikai progikat kavarja meg.Az EFI/AGESA temanak utana tudunk nezni, de sokat segitene, ha tudnal submittolni egy riportot nekunk (AIDA64 / fomenu / Report / Submit Report To FinalWire), meghozza a legujabb AIDA64 betaval --> [link]
Koszi a segitseget!
-
Fiery
veterán
válasz
Oliverda
#2251
üzenetére
Koszi a visszajelzest! A VRM ez esetben arra utal, hogy a VRM altal szolgaltatott feszultsegrol van szo, azaz a VRM kimeno feszultsege ez.
RAID: egyelore nem tudtunk rajonni, hogy mikepp lehetne javitani az AHCI mod kezelesen
Korbekerdeztunk, de masok sem tudjak a megoldast a "barati" fejlesztok kozul 
-
Fiery
veterán
válasz
Oliverda
#2150
üzenetére
A legujabb AIDA64 betaban mar megtalalhato a VT1556 chip tamogatasa. Azonban, ez az uj chip sokkal kevesebbre kepes, mint az elodei (pl. VT1165). Csak a VRM feszultseget es a VRM homersekletet méri.
A kozeljovoben a kulonfele HD 69xx chipes kartyakon talalhato mas VRM chipek (pl. uPI es CHiL) tamogatasat is beepitjuk.
-
Fiery
veterán
válasz
Oliverda
#2230
üzenetére
Leteszteltunk egy ugyanilyen konfigot, de nekunk a HD Tune Pro legujabb verzioja (4.60) nem latja egyik vinyon sem a SMART infot. Mint ahogy az AIDA64 sem, es a HD Sentinel Pro legujabb verzioja (3.50) sem.
A mi konfiguracionk:
- Gigabyte GA-890GPA-UD3H alaplap, SB850 deli hid, RAID modba kapcsolva a BIOS Setup-ban
- 2 db Seagate 500 GB SATA2 vinyo, a port0 es port1 nevezetu SATA portokra kotve, RAID0 modba konfiguralva
- 1 db Seagate 1 TB SATA2 vinyo, port2-re kotve, standalone vinyokentAz oprendszer Win7 32-bit SP0. Az AMD RAID driver verzioja 3.2.1540.75, 2010.jun.22-ei datummal.
Ird meg kerlek, hogy a Te konfiguraciod pontosan hogyan is nez ki, kulonos tekintettel az AMD RAID driver verziora, es a SATA port kiosztasra.
Koszi a turelmedet!
-
Fiery
veterán
válasz
Oliverda
#2128
üzenetére
Nem hiszem, hogy rosszul csinaltal volna barmit is. Igyekszunk me'g tesztelni a RAID-del es AHCI-vel kapcsolatos modulokat, csak sajnos ez rettento idoigenyes, hiszen tobbfele Windows-t kell telepiteni hozza, tobbfele drivert kiprobalni, RAID, AHCI es IDE modban is, stb. stb. stb. Jovore kicsit tobb idonk es energiank lesz ezekkel a franya RAID/AHCI vezerlokkel molyolni

-
pe de
csendes tag
válasz
Oliverda
#1986
üzenetére
Naja, mindjárt. Fekete zöld rövidrezár, aztán hadd szóljon...
Még az is furcsa, mióta megvolt a modding, a proci (E6500) órajele nem csak két érték között ugrál, hanem több érteket is használ... Lehet hogy csak paranoiás lettem, mióta vérző szívvel elvágtam a tápom kábeleit... Mennyi a normál Vcore fesz? Az órajel változásával egyenes arányban ez is változik? -
Fiery
veterán
válasz
Oliverda
#1961
üzenetére
Sajnos azota sem tudtuk reprodukalni a hibat a sajat AMD-s tesztgepeinken
Sejtesem szerint az AMD chipsettel lehet kapcsolatos ez a bug, az OverDrive funkcio kornyeken buzlik valami, csak azt nem tudom, miert pont a GPU-s reszhez erve fagy le...Hamarosan (amikor megjon a Phenom II X6) ujabb tesztgepeket fogunk "csatasorba allitani", azoknal remelhetoleg mar tobb szerencsenk lesz ezzel a buggal kapcsolatban.
-
Fiery
veterán
válasz
Oliverda
#1951
üzenetére
Ha megoldhato, ellenorizd kerlek, hogy a jelenlegi rendszerbeallitasok mellett az utolso stabil verzio valoban jol mukodik-e, es valoban csak a legujabb betara all-e, amit irsz. Mi ugyanis nem valtoztattunk semmit az Overclock oldalon, ezert nem is tartom valoszinunek, hogy az tehet a fagyasrol. A legtobb esetben az ilyen problemak a gep instabilitasara vezethetoek vissza.
-
Fiery
veterán
válasz
Oliverda
#1848
üzenetére
Ez mar kezd kisse off-topic lenni, de kivancsi lennek, mikepp mérik le a CPU fogyasztasat a LostCircuitsnel. Ugyanis szamomra kisse nehez elkepzelni olyan "házi" modszert, amivel a CPU es csak a CPU fogyasztasa valoban precizen merheto. Nyilvan az Intel kepes olyan alaplapot gyartani, ami ki van erre a celra hegyezve, de azt csak hazon belul hasznaljak.
-
Balala2007
tag
válasz
Oliverda
#1825
üzenetére
A memoria bench ertekeket illetoen nekem ugy tunik, scientia keveri az elmeleti memsavszel fogalmat a kihasznalhatoval. Igaz, hogy mindket konfigban hasonlo memoriak vannak, kozel egyforma elvi savszellel (EVERESTben az Alaplap/Alaplap/Memoriabusz tulajdonsagai alatt nezheto meg), de hogy ezekbol mennyit tud tenylegesen kihasznalni egy egyszalas alkalmazas, az mar hw implementacio fuggo, es pont ezt mutatja meg az EVEREST. Mind a ket procin a szamara kedvezobb savszel mero rutin fut a tudtunkkal leggyorsabb verzioban. Ha felbukkanna egy gyorsabb kod K10-re (tobbszal es realtime priority nem er), akkor orommel lecserelnenk arra (bar erre eleg keves eselyt latunk, eleg sokmindent vegigprobaltunk mar).
A cache-eknel egyreszt tul lassu lenne, ha keresgelnenk mekkora meretu blokkot hasznaljunk, masreszt meg altalanossagban nem is mindig lehet szamitani arra, hogy lesz "lapos" resze az atviteli gorbenek. (ket pelda akosf-tol 1, 2) Igy mi inkabb a CPUID-bol olvassuk ki a cache meretet, es azt hasznaljuk.
Mivel non-temporal write-ot hasznalunk, ezert ritkan, de elofordulhat, hogy write gyorsabb, mint a read. (Bizonyos K7-eseknel tipikus volt anno...)
-
Fiery
veterán
válasz
Oliverda
#1240
üzenetére
Az a baj tudod, hogy mindenki mas adatokat szeretne latni az EVEREST CPUID panelen es a Cache & Memory Benchmark panelen. Ezek a panelek azonban statikus grafikat hasznalnak hatternek, es igy nem lehet dinamikusan varialni, hogy milyen adatok jelenjenek meg. Arra termeszetesen lenne lehetoseg, hogy 1 db dedikalt mezo legyen mindenfele adatoknak, es azt be lehessen allitani, hogy az az a 1 db mezo mit jelenitsen meg. De ezzel a temaval egyelore nem foglalkoztunk, ugyanis elobb at akarjuk gyurni mindket panelt (es ujakat is tervezunk hamarosan), hogy tobb infot tudjunk adott feluleten megjeleniteni.
-
Fiery
veterán
válasz
Oliverda
#1238
üzenetére
Koszi, javitottuk a hibat.
A Cache & Memory Benchmark ablakon nincs annyi hely, hogy mindenfele plusz informaciot feltuntessunk. Ennyi erovel relevans lenne a HyperTransport, QPI es a North Bridge orajel is. De ha minden vackot kiirnank a panelre, akkor 800x600-as felbontasban nem ferne el a kepernyon
A mai netbookos idokben pedig sajnos nem feltetelezhetjuk azt, hogy mindenki 1024x768-as vagy nagyobb felbontast hasznal. -
Fiery
veterán
válasz
Oliverda
#485
üzenetére
Kuldj kerlek valamelyik benchmark oldalrol egy teljes screen shot-ot (emailben, uusi KUKAC freemail.hu), miutan futtattad a benchmarkot es 0-t adott eredmenynek.
Az EVEREST aktualis betajanak mappajaban ugye van EVEREST_BENCH.DLL fajl Nalad? Ha van, akkor mekkora a fajlmerete?
-
Fiery
veterán
válasz
Oliverda
#258
üzenetére
Sajnalatos ez az eset, bar kicsit furcsa, hogy masoknal nem tortent (me'g) ilyesmi. Az unnepek utan razorgunk a DFI-ra, hatha ki lehetne talalni valami megoldast arra, hogy a jovobeni LANParty lapoknal ne kelljen az alaplap azonositojat tudni ahhoz, hogy elkeruljuk az ilyen eseteket. Valamint, szerzunk egy LANParty alaplapot, aminel melyrehatobban tudjuk tesztelni ezt a jelenseget -- remelem, nalunk nem fog "megzabalni" tobb procit is az alaplap, mire kisakkozzuk a dolgot

Megjegyzem, az Intel altal gyartott lapoknal (pl. D975XBX2) is ugyanigy fejreall a fesz.szabalyzo, de ott csak annyi tortenik, hogy a CPU core feszultseg visszaall alaphelyzetre (pl. 1.35V), es igy csak a tuningolt procik fagynak le (ahol az alapfesz nem elegendo a mukodeshez).
Az is furcsa, hogy az alaplapod fesz.szabalyzo ezek szerint kepes extrem feszultseget eloallitani -- hiszen pl. ha 0.5V-2.5V tartomanyban dolgozna a fesz.szabalyzo, akkor a CPU a maximumot (2.5V) is elviselne rovid ideig, legalabbis fizikai karosodas nelkul.
-
Fiery
veterán
válasz
Oliverda
#248
üzenetére
A komolyabb, modern DFI lapokon van egy feszultseg szabalyzo, ami a monitorozo szoftverek jol megszokott SMBus scannelese kozben fejreallitja a gepet. Mar beszeltunk a DFI-jal ez ugyben, de csak annyit tudtak mondani, hogy az ilyen lapoknal tiltsuk le az SMBus scannelest bizonyos SMBus eszkoz cimekre.
Itt egy uj EVEREST beta verzio, amiben mar elvileg le van tiltva az SMBus scanneles a lapod (es sok mas, pl. X38 chipsetes DFI lap) eseteben.
Ird meg, hogy jol mukodik-e most mar. Koszi!
Új hozzászólás Aktív témák
- droidic: [Memory Leak] Az agy defragmentálása
- Autós topik
- Örömkönnyek és üres kezek a TriFold startjánál
- Azonnali alaplapos kérdések órája
- Xbox tulajok OFF topicja
- iPhone topik
- Metal topik
- Töltő már van a Galaxy S26 Ultrához
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- EA Sports WRC '23
- További aktív témák...
- BESZÁMÍTÁS! MSI Katana15 HX B14WEK notebook - i7 14650HX 16GB DDR5 1TB SSD nVidia RTX 5050 8GB WIN11
- GYÖNYÖRŰ iPhone 13 256GB Midnight -1 ÉV GARANCIA -Kártyafüggetlen, MS3650
- HP EliteBook 850 G7 (15.6") i7-10610U - Garancia, Akció!
- Samsung Galaxy A80 128GB, Kártyafüggetlen, 1 Év Garanciával
- Targus DOCK423A - USB-C Dual HDMI 4K HUB - 2 x HDMI (120Hz)
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest

Sok dolognak kell azonban egybe allnia, tobb reszet is kell az AIDA64-nek ahhoz modositani, hogy megbizhato, normalis kimenetet tudjunk adni minden core-rol, minden PState allapotrol, minden orajelrol, stb. Raadasul -- jelenlegi ismereteink szerint --, ez leginkabb csak AMD processzorokon mukodhet olyan szepen, olyan vilagosan reprezentalhato modon, mint a PSCheckben, de me'g kutatunk, hatha Intel procikon is tudnank hasonlot produkalni. Jelenleg azonban teljes gozzel a GPGPU benchmarkokon dolgozunk, hamarosan megjelenik stabil kiadasban is, viszont utana meg a HSA-val es ujabb GPGPU benchmarkokon kezdunk dolgozni, ugyhogy nem tudom most megigerni, hogy a PState- es orajel monitorozo modul mikorra fog tudni elkeszulni
Sajnos az ilyen specifikus, nagyon szuk kör szamara hasznos modulokat kenytelenek vagyunk hatrebb sorolni a fejlesztesnel, amikor olyan nepszeru feature-okon kell dolgoznunk, mint a GPU benchmarkolas 

Persze csak a System Log eseteben, a tobbi maradhat alapbeallitason.
![;]](http://cdn.rios.hu/dl/s/v1.gif)

Csak K10 procikon mukodik a dolog, mas procival ne keressetek, mert ugysem talaltok semmit


