- Gaming notebook topik
- Hobby elektronika
- Épített vízhűtés (nem kompakt) topic
- Milyen monitort vegyek?
- Érkezik Magyarországa az LG szuper dizájnos hordozható projektora
- Hogy is néznek ki a gépeink?
- Projektor topic
- Milyen házat vegyek?
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Vezetékes FEJhallgatók
Hirdetés
-
Musk szerint már jövőre itt vannak a Tesla Optimus humanoid robotok
it Musk a befektetőknek arról beszélt, hogy már az idei év végén gyárakban dolgozhatnak a Tesla Optimus robotok, a forgalmazás jövő év végén indulhat.
-
Nagyon olcsó, madzagos gaming headset a Sharkoon háza tájáról
ph A meglehetősen könnyű újdonság a Skiller SGH1 utódjaként értelmezhető.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
Aktív témák
-
zsiga667
addikt
Procihoz patch? LOL! :DD
-
Surranó
aktív tag
Az az ''igen ritka'' eset asszem az, amikor valaki MOVS utasítást használ, de előtte átállít egy flaget. Vagy valami ilyesmi. Tipikusan ritka utasítások úgy önmagukban ;]
-
putti
aktív tag
Elgondolkodtató! Felmerül bennem az a gyanú, hogy talán az intelt is fel lehetne így patchelni 32-ről 64 bitre. De az is lehet, hogy ez a gyanú tök hűlyeség.
-
anulu
félisten
-
HÁZIGAZDA
Megnéztem a tech doksit... hihi :)
Ha fordított irányú ciklust futtatsz 1 és 20 közötti alkalommal, és neadjaég még egy szegmens regisztert is betöltesz előtte (LDS, LES utasítások), bukó...
Hát, ez NAGYON nem olyan dolog, amit lehetetlen lenne előidézni, sőt, mint ex assembly-s arc, elég komoly bugnak tűnik. Persze ki tudja.dicranum scoparium + genista pilosa = :)
-
twollah
nagyúr
Kivancsi vagyok mikor jelennek meg az elso virusok amik kihasznaljak a CPU eme hibajat.
-
rATdrAgOn
senior tag
Akkor hadd emlekeztesselek a hires F00F bugra ami eppen az intel Pentiumokban jelentkezett :Y... szepen ki is kellett adni patchet az akkori linux kernelekhez, hogy ne rohadjon tole szet a rendszer. (azota is tartalmazza mind) :))))
[Szerkesztve]
[Szerkesztve]A pC vajommi?! A kindoz vajommi?! A szittyozium.hu jó. Amigát használok, commodoreos (c)(r)(tm)-al. Meg nextgent. Meg bármit. :D
-
Flashy
veterán
szinte minden processzorgenerációban volt eddig hiba :) POPAD, FDIV, F00F, nem akarom az AMD-t védeni, de az Intelt se kell félteni, csinálnak ők is szépeket :)
[Szerkesztve] -
hobizoli
nagyúr
válasz rATdrAgOn #10 üzenetére
Az benne volt am meg a Pentium Pro, a Pentium MMX es a Pentium II CPU-kban is, mivel ''csak'' '98 tajekan jottek ra...:U
CMPXCHG8B
''F0 0F C7 C8...8 byte, ami megrengette a vilagot''
Vmi PC-s ujsag cikk cime volt akkoriban (Ch*p? vagy PCW*rld?)
Errata lista egyebkent minden CPU-hoz van a gyartoknal, hol tobb, hol kevesebb
hobizolitöbb drón kell ;P
-
Flashcash
Közösségépítő
A Prescottról is megjött a hibalista:
''Az Intel weboldalán megjelent dokumentum szerint nem kevesebb mint 31 olyan hiba van még a vállalat Prescott -- 90 mikronos gyártástechnológiával készült -- Pentium 4 processzoraiban, melyeket napjainkig nem javítottak ki. Amint arról hírt adtunk, a rivális AMD Opteron és Athlon 64 processzorai egy hibájához adott ki egy szoftveres frissítést tegnap.
Az Intel processzoraiban talált hibák egy része BIOS frissités segítségével javítható, mások azonban nem orvosolhatók ilyen módon, csupán a processzorok egy következő revíziójában javíthatják ki őket. A 31 eddig nem javított hiba stabilitási és teljesítménybeli gondokat okozhat.
Minden piacra dobott processzor tartalmaz hibákat, melyeket a gyártók folyamatosan javítanak BIOS frissítések segítségével. Azonban egyes vélemények szerint a Prescottokban felfedezett hibák egy része meglehetősen komoly és a 31 darab még javítatlan probléma igen soknak mondható.'' -
Erasmus
őstag
válasz Flashcash #15 üzenetére
Gyerekek, nyugalom! Erőteljesen szenzációhajhász a hwsw-n megjelent hír. MINDEN ilyen bonyolultságú processzor számos kisebb-nagyobb bugot tartalmaz. Ezekből jó esetben egyik sem lesz olyan komoly, mint például a Pentium FPU-bugja annak idején. Ezeket többnyire újabb revíziókban javítják, de ha nem muszáj, nem módosítják a chipet, mert az értelemszerűen nem kevés pénzbe kerül, ezért inkább írnák egy BIOS-t, amellyel megkerülhető a probléma.
Ha itt megnézitek például, a Willamette/Northwoodban 91 darab bugot fedeztek fel (és akkor még nem beszéltünk azokról, amelyekről nem is tudnak): [L]ftp://download.intel.com/design/pentium4/specupdt/24919950.pdf[/L]
Tehát itt egyáltalán nem egyedi esetről van szó. Hogy mennyire komolyak a Prescottban lévő hibák, azt persze én nem tom, de az is biztos, hogy az idézett hír írója sem.
üdv, -
Flashcash
Közösségépítő
-
tocsa
senior tag
Ne hidd, hogy jobb lenne a hibaszámban a NorthWood. Maximum azért lehet jobb, mert későbbi revizió, ezért az _ismert_ hibák egy részét már kijavították. A Prescott és a Northwood is annyira nagy komplexitású már, hogy ugyanolyan gyakori lehet bennük a hiba. Meg az AMD-ben is.
Hangsúlyozzuk, hogy itt (pl Prescott 31 hibája) az ismert hibákról van szó.
Kb ugyanaz a helyzet mint a szoftvereknél. Csak itt sokkal nehezebb a helyzet a fixálással, mert nem lehet egyszerűen egy patch-el kijavítani. A BIOS javítás valszeg valami orbitális hack workaround a dologra.
Kivétel lehet a Transmeta, ahol ha valahogy pacth-elik a mikrokódit, akkor kijavíthatják kvázi szoftveresen a ''hardver'' hibát.
A processzorok ma már annyira sok állapotot vehetnek fel, hogy a tökéletes letesztelésük gyakorlatilag lehetetlen (vagyishát kivárhatatlan). Ehelyett heuristikákkal és okos logikákkal próbálják őket tesztelni, de néha nem sikerül tökéletesn.Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz
-
Erasmus
őstag
válasz Flashcash #18 üzenetére
Héló, én nem téged kritizáltalak, hanem a hírt (a szerzőjének is írtam, btw).
Hogy ki a szenzációhajhász, azt meg a hírcímek összehasonlításából döntse el ki-ki maga:
''Orvosolták az AMD64-processzorok apró hibáját''
vs.
''Tucatnyi javítható és javíthatatlan hiba az Intel 90 mikronos technológiával gyártott Pentium 4 processzoraiban''
:)
üdv, -
rog
addikt
nekem tök úgy jön le a cikkből, hogy a cpu hibáját majd a bios módosításval korrigálják, és innentől minden jól fog működni.
pedig inkább csak arról van szó, hogy a most használt bios-okban van egy olyan kódrész, ami ezt a hibás működést előidézi, és azt javítják ki a gyártók az amd útmutatásai alapján.
ettől még előfordulhat, hogy valakinek a programja, oprendszere is tartalmaz olyan kódot, ami előidézi ezt a problémát.. -
tocsa
senior tag
Valami szekértő elmondhatná, hogy egy ilyen hibát hogyan lehet BIOS-ból orvosolni.
Nekem csak óriási hack-ek jutnak eszembe:
- a chipset passzívan figyeli a az adatbuszt, és hogy milyen utasítások áramlanak rajta
- valahogyan figyelia proci DF falg értékét is (?)
- figyeli az RCX értékét is valahogy, hogy 1 és 20 között van-e
- ha DF=1 (vissza irányú a string művelet) és jön egy MOVS, előtte REP perfixxel
- és mindezek előtt az errata-ben említett utasítások voltak (BOUND, CLI, LDS, LES, LFS, LGS, LSS, IDIV, and most microcoded x87 instructions), akkor közbeavatkozik
Már ennek az esetnek a figyelése is baromi bonyolult, mert a mobo nem lát bele a prociba. Sőt, talán lehetetlen is.
És hogyan avatkozik közbe? Bead valami NOP-ot vagy más utasítást sutyiba a procinak, hogy a retire logikát egy kicsit siettesse? De akkor elromlik az IP értéke.
Ezt nem tudom elképzelni.Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz
-
Flashcash
Közösségépítő
Én ott még ilyen szavakat is látok a prohardver hírben hogy Opteron/lefagyás.
Nekem az a véleményem ha már ezzel a témával a főlapon foglalkoztok akkor az AMD 1db hiba mellett az Intel-ről is készítsetek egy hasonló hírt, így lesz objektív az oldal.
Valójában meg egyiknek sem kellene hírnek lennie. :) -
tocsa
senior tag
Szerintem nem erről van szó, mert ha ez lenne a szituáció, akkor a szóban forgó BIOS-os gépek mind eléggé faygtak volna. Itt egy laboratóriumi körülmények között reprodukált hibáról van szó. Azért nincs ennél nagyobb botrány, mert ugy néz ki, hogy a hiba előállásához szükséges csillagok szerencsétlen együttállása mindennapi gyakorlatban nem áll elő. Lehet hogy Parci assembly szemével durva hiba (szerintem is), de ha gyakorlatban is előfordulna (nem csak laborban), akkor nagyobb botrány lenne.
A hibából úgy veszem ki, hogy talán az elágazácsbecslés, Out-of-order-execution ill. retire logikákban lehet a hiba. És nem a REP MOVSB instruction végrehajtásában. És akkor ez lehet, hogy esetleg máskor is előjöhet. Ezért fontos az AMD-nek majd későbbi steppingekben sürgősen javítani a hibát.
Még a compilerek patch-elésével lehetne workaroundolni a cuccot, hogy azok toldjanak be a string művelet elé kamu utasításokat.Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz
-
tocsa
senior tag
válasz Flashcash #24 üzenetére
Ezt ne várjuk el a PH!-től. Nem ők itélik meg, hogy mi a súlyosabb hiba. Ez most tényleg annak mondható, ezért van ez csak felkapva. Az F00F bug idején a Pentium került reflektorfénybe, pedig abban az időben az MADknek is volt persze ugyanúgy hosszú erratajuk, csak egyik sem volt olyan súlyos hiba.
A lényeg az, hogy mi értünk hozzá, nem parázunk be, tudjuk, hogy nincs semmi komoly gond.Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz
-
rog
addikt
az lehet hogy szerinted nem erről van szó. de világ összes cikke a témában erről ír. hogy van ez a hiba, és hogy emiatt a bios patch-eket sorban készítik a cégek.
ha nem érinteé a bios-programokat a hiba, akkor gondolom viszonylag kevés cég adna ki javítást a biosához miatta. -
Flashcash
Közösségépítő
Nem kell megítélni a hiba súlyosságát.
Én azt ajánlottam hogy objektív legyen az oldal, tehát ha az AMD-nél 1db bios 'frissítéssel javítható' hibáról a főoldalon több példányban olvashatok, akkor az Intel Prescott 31db hibájáról miért nem látok semmit?
Azok nem olyan súlyos hibák? :) -
WN31RD
addikt
A buszfigyelgetés nyilván kivitelezhetetlen. :)
Nem tudom, ezt a hibát hogyan akarják orvosolni, de a többi hasonló esetben jellemzően a BIOS letilt a prociban valami olyan feature-t, ami nélkül nem jöhet elő a hiba.
Kérdés, hogy az ilyen letiltások mekkora teljesítménycsökkenést okoznak... mert ugye nem véletlenül rakták azokat a feature-öket a prociba.
Az eredeti hírben van egy link az AMD errata doksijára ([L]http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf[/L]), érdemes átböngészni.''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
kisfurko
senior tag
Már egy ideje a Pentiumokat is lehet ''felújítani''. Van külön hely mikrokód feltöltéshez. Azért kell ezt a BIOS-ba rakni, mert ez minden kikapcsoláskor elfelejtődik. Gondolom AMD-éknél is van mikrokód frissitési lehetőség (már egy ideje nem olvasom a data sheet-eket). A movs utasítás pedig komplex, így én elég valószínűnek tartom, hogy mikrokód patch-csel jól fog menni (ha lehet patch-elni AMD-éknél).
-
tocsa
senior tag
Tudom, asszem Linux alatt I2C és SMBus cuccokkal lehet is olvasni.
Nade az _nagyon_ pici része a procinak (?), csak bizonyos dolgok vannak benne. Az utasítás végrehajtások logikája, vagy az OOO (Out-Of-Order Exec Unit), retire unit logikája nyilván nincs benne. Akkor az egész CPU csak egy nagy tároló logika lenne. Akkor már majdnem egy transmeta proci lenne az egész. A proci legnagyobb része hardwired.Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz
-
tocsa
senior tag
válasz Pizzafutar #31 üzenetére
De nem hiszem, hogy a retire vagy OOO logika abban van. Meg azt sem, hogy mind a sokszáz utasítás végrehajtási programja ott van. Lehetetlen. Annyira gyorsnak kell lenni a procinak, hogy ezeknek a cuccoknak beépítettnek kell lenni.
Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz
-
kisfurko
senior tag
Szerintem mivel a hiba a movs utasításnál jön elő, és az teljes biztossággal mikrokódos, ezért némi teljesítmény rovására pl. beiktatnak plusz mikroutasítást a movs kódjába, ezzel már nem abban az állapotban lesz, ami előidézi a bug-ot. Nem teljesen szar a pipeline, hanem csak a csillagok nagyon rossz együttállásakor hibázik.
-
HÁZIGAZDA
-
kisfurko
senior tag
Biztosnak nem mondhatjuk, hiszen ezt csak a fejlesztők tudhatják...
Szerintem azért majdnem biztos, mert sok elemi részre lehet bontani. Betöltés, kiírás, cím növelés/csökkentés, számláló csökkentés és tesztelés (meg persze flag állítás). Másrészt pedig írták még a régebbi doksikban, hogy kerüljük ezeket a komplex utasításokat, mert lassú a dekódolásuk (a rep-es változatok persze hatékonyak, mert csak egyszer kell dekódolni).
Ha úgy vesszük, akkor már a K6 és a Pentium Pro óta mikrokódot futtatnak ezek. Lefordítják az x86-os utasításokat mikroutasításokra, és azokat futtatják. A primitív utasításoknak egy, de a komplex utasításoknak egy sor mikroutasítás felel meg, amit ROM-ból olvas.
Ha jól emlékszem, az AMD doksikban benne van, melyik komplex, melyik nem.
Egy jó oldal: [L]http://chip-architect.com/[/L] -
mr_ricsi
veterán
válasz Flashcash #15 üzenetére
''Az Intel weboldalán megjelent dokumentum szerint nem kevesebb mint 31 olyan hiba van még a vállalat Prescott ... Pentium 4 processzoraiban, melyeket napjainkig nem javítottak ki.
a 31 darab még javítatlan probléma igen soknak mondható''
Összehasonlításul: az AMD TBredB-s procikban 8db ilyen hiba van.Sokkal kellemesebb úgy hibát keresni, ha tudod, hogy másban kell!
-
Miracle
senior tag
a TBredB a K7es mag(ha jól számolok) 3. vagy 4. ráncfelvarrása, természetes, hogy kevés hiba van benne. a prescott meg brand new. persze ez kevéssé vígasztalhatja a xeon-vásárlókat, az otthoni gépeken meg nem számít.
értelmező késziszótár :: rekurzió --> lásd : rekurzió
-
mr_ricsi
veterán
''TBredB a K7es mag(ha jól számolok) 3. vagy 4. ráncfelvarrása, természetes, hogy kevés hiba van benne''
A TBredB a0-ás reviziójában még csak 7 db volt, aztán felvarrtak egy újabb ráncot... :))
(Az Athlon Classic -slotAs- első szériájában 6db volt)Sokkal kellemesebb úgy hibát keresni, ha tudod, hogy másban kell!
-
tocsa
senior tag
Azt tudjuk, hogy mikroutasításokra bomlanak az utasítások. Méga számunkra legegyszerűbbnek tűnő is. Már csak a pipeline miatt is szükséges.
De a mikroutasítások mikrokódban lennének? A mikrokód egy plussz indirekciót jelentene a végrehajtás során (pont amiatt, hogy változtatható). Ezáltal véleményem szerint lassabb az utasítás végrehajtás, mintha valami nem mikrokódos lenne. Lehet, hogy nincs igazam. Úgy gondoltam, hogy egy olyan elemi művelet, mint egy regiszter kiolvasása, vagy egyel növelése változtathatatlanul be vannak drótozva, és ki vannak optimalizálva a sebesség miatt. Mondjuk pont a pipeline elrendezés miatt előfordulhat, hogy egy stage ideje úgyis meghatározott, és egy nagyon egyszerű utasítás lehet, hogy belefér időben mikrokódosra az indirekció miatt.
Mi a véleményetek?Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz
-
kisfurko
senior tag
Fentebb azt próbáltam leírni, hogy a gyakran használt, egyszerű utasítások simán fordítódnak (egy ciklus alatt kidobja a dekóder), de a komplex utasítások mikroutasításait ROM-ból szedi. Talán ezt a ROM-ot lehet felülbírálni feltöltéssel.
Nekem a mikrokód=mikroutasítások, de lehet, hogy magyarul nem (nem emlékszem már a digit ezen részére pontosan). Intel doksiban download microcode néven fut az upgrade, ezért tettem a fenti egyenlőséget. -
tocsa
senior tag
Ja. Ez jó kérdés, hogy pontosan mit jelent a mikrokód.
Számomra olyasmit jelent, hogy egy assemblynél is jóval alacsonyabb ''nyelven'' leírt utasításokkal egy algoritmus/program. Amit értelmezni tud a prociban egy logika. Az program lehet persze egy dekódolt mikroutasítás végrehajtása is. Miért ne. De ezen a programozható területen gondolom lehetnek adatok is feltételezésem szerint.
Utána kéne járnom a dolgoknak, ha lesz időm rá.Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz