- Gurulunk, WAZE?!
- bitpork: Phautós tali a Balcsinál 2025 Augusztus 2 napján (szombat)
- KRTLPC: Ki és hogyan élt túl? Volt ám fennakadás
- sziku69: Szólánc.
- SzőkeKapitán: Világ vége túlélők topicja
- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- Meggyi001: Anya, tudsz segíteni a matekban?....Nem érek rá kisfiam, majd segít a ChatGPT...
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
Új hozzászólás Aktív témák
-
S_x96x_S
addikt
BIOS frissités állítólag jót tesz neki !
"AGESA 1.0.0.6b Might Fix The Ryzen Linux Performance Marginality Problem"
https://www.phoronix.com/scan.php?page=news_item&px=AGESA-1.0.0.6b-Update -
janos666
nagyúr
Nekem az jutott eszembe erről a Linux<->Ryzen dologról, hogy kallódott nálam hónapokon át egy Intel G4400 CPU, míg egyszer vettem alá egy C232-es deszkát, és ECC-s RAM-ot, majd áttettem az új gépbe a régiből az összes adattárolót. Először működött minden, de miután újraforgattam a teljes Gentoo rendszert (emerge -e @world) march=native GCC paraméterrel (a költöztetés előtt ugyan ezt futtattam, csak generic amd64-re, hogy egyszerűen átpakolhassam a rendszer SSD-t a gépek közt), akkor nem boot-olt többé.
Nagy nehezen kiderítettem, hogy a CPU hibásan jelezte valamilyen kiterjesztés támogatását, ami igazából le volt tiltva. Ez már 2016 októbere volt, tehát durván egy évvel a CPU megjelenése után, de még csak akkortájt jelent meg a microcode, ami javította ezt.
Ha a megjelenés utáni 1-2 hónapban futottam volna bele ilyenbe, azt még megértettem volna, de egy évvel később ilyen triviális baki, amire sem a friss hivatalos alaplapi BIOS nem volt még felkészülve egy "workstation" jellegű lapon, se a viszonylag friss GCC nem tudott még róla... -
#45997568
törölt tag
Kis update a proci cseren, 2 napja jelentettem AMD-nek es OCUK-nek a problemat, hogy elhasalt a proci a gcc teszten. OCUK adott egy RMA szamot, tegnap reggel elkuldtem, ma delben erkezett meg hozzajuk a proci, fel oraval kesobb mar jott az email hogy az ujat most keszitik elo nekem, ma kuldik, holnap megjon.
Szoval ha valaki normalis boltbol vasarolt az gyorsabb mint AMD-n keresztul.
-
Cathulhu
addikt
Azert azt tegyuk hozza, hogy egy nagyon nehezen megfoghato hibarol van szo, nincs olyan teszt amivel biztosan reprodukalhato lenne. Meg a phoronix fele stresszteszt is csak nagy valoszinuseggel hozza elo, de nem mindig, nem ugyanott es nem ugyanazon a magon. En pl eleg sokat forditottam gcc-vel 16 szalon, de sose segfaultolt, ettol fuggetlenul most aggodok kicsit es ragaszkodom a cserehez. De az egesz szituacio nagyon ugy tunik, hogy egy nagyon specialis, akar idozites akar feszultseg akar barmijen egyeb zaj es a csillagok egyuttallasa miatt kovetkezik be, erre elore tesztet irni nem feltetlen volt lehetseges es nem a kapkodas az oka. Sot lehet azota sem tesztelheto, es mivel nehezen reprodukalhato, mert ilyen jellegu hibaknal gyakran elofordul az, hogy mar attol, hogy vizsgalod magat produktomot mar azzal eloidezhetetlenne teszed a hibat, szoval lehet azota sem tudjak mi okozza es hogy lehetne tesztelni es ezert nincs uj stepping sem. Ki tudja, lehet a csereprocikat is a kill-ryzen scripttel kinozzak a laborban es azt kuldik ki, ami jo.
-
Abu85
HÁZIGAZDA
-
XMI
csendes tag
[l]Ezek a piacon most lényegtelenek.
Én egészen biztosan meg vagyok róla győződve, hogy az AMD-nél pár manager pontosan így gondolkodott, azért állhatott elő ez az egész szerencsétlen helyzet. A time to market megint fontosabb volt, ezért a tesztelésen spóroltak: mindig csak azt a tesztkészletet futtatták, amiről úgy gondolták, hogy a "megcélzott" vásárlóközönség felhasználási körét fedi.Én értem, hogy egy AMD-s manager így gondolkodik, csak azt nem értem Te miért gondolkodsz így.
Én mint potenciális felhasználó - akinek munkára kéne - ezzel nem vagyok kisegítve. Hadd ne kelljen már Threadripper-t vennem, >260eFt-ért, és AM4-esnél lényegesebb drágább TR4-es alaplapot alá, csak mert egy hibátlan processzort szeretnék. Ennyiért már kapok Xeon-t is. A Ryzennek pont az lenne az egyik fő erőssége, hogy kapsz 8C/16T-t, ECC-s memóriát támogat -> ez egy olcsó munkaállomás.
-
eegen, 2 ccx, de amíg az r7es ryzenben csak egyféle ccx van (az aktív magok alapján), addig az r3ashoz már hatféle ccxet legózhatsz össze az aktív és a letiltott magokból. ebből van ugye kettőd, szóval összesen 36féle elrendezésben lehet az a 4 aktív mag a procin.
és akkor az l2-l3 cache méretével még nem is foglalkoztam, mert ezekben is van eltérés. -
XMI
csendes tag
válasz
velizare
#123
üzenetére
a magasabb modellszámú ryzenek több ccxet és aktív magot is tartalmaznak, nemcsak base/boost órajelben és xfr on/offban van különbség.
Arra még nem láttam tesztet, hogy magletiltással megszüntethető-e. Annak esetleg utána lehet nézni a fórumokban elérhető logokban, hogy egyes magokra korlátozódik-e a hiba. De lehet, hogy ezt az ötletet már körbejárták, csak eddig elkerülte a figyelmemet.
Amúgy CCX-ben tudtommal nincs különbség, a legkisebb Ryzen3 is mindig 2 CCX-es
-
Clay
senior tag
Lehet le fogják szedni a fejem, de szinte biztos vagyok benne, hogy nincs 10% akik csak és kizárólag Linux-szal használják a gépüket. Ha tartana a Prohardver szavazást, az se fedné a valóságot, mert egy csomó ember akik PC-t használnak ide se szagol. Kíváncsi lennék egy ilyen szavazásra.
-
-
Gyuri27
félisten
Egen. Azért mert az ember wint használ. Meg néha elindit egy kínaimesekártyajátékot még nem gémer.
De mennyi a linuxot használók aránya? 10%? Legyen 15. Azoknál se mind jön elő a hiba.
Persze jó idejönni és sírni. Helyette én kicserélném a procit és csók.
De akinek a sirukálásra van igénye az ne tartsa magába. -
Gyuri27
félisten
-
Jack@l
veterán
Biztos vagyok benne, hogy elő lehet hozni windows alatt is. Csak idő kérdése hogy kiderüljön milyen progival kapja el ugyanazt a neki nem tetsző terhelés tipust. Windows alatt valószínű az ütemező kezeli máshogy a szálakat, ami miatt nem hányja össze magát, de ez egy update-el, SP-el simán változhat később.
-
sayinpety
tag
Hetfo ota ellenorzom a tesztgepeim. 7 Ryzenem van. 1 ES, 2 1800X, 1 1700X, 1 1700, 1 1600X, 1 1300X. Mindegyik majus elotti, kiveve 1300X. 3 jelez hibat. 1700, 1700X, es egyik 1800X. Az 1700 vizzel hutve megjavul. Tegnap egesz delutan teszteltem, am csak gyari hutovel hibazik.
-
-
-
XMI
csendes tag
Az a baj, hogy a fene tudja. A leírások szerint a hiba túl egyenetlenül jelentkezik, néha 2-3-5 óráig semmi, aztán 30 percen belül 2-3 hibaeset. Így elég nehéz a valószínűségi várható értékét számolni. Kb hetekig kéne futnia egy-egy beállítással, hogy elég adat legyen, hogy értelmes konfidenciával lehessen állítani bármit. Emiatt simán lehet, hogy egy-két BIOS beállítás valójában teljesen véletlen egybeesés miatt tűnik úgy, mintha segítene rajta.
Egyébként valóban olvastam olyan teóriát (most nem keresem elő a linket) - ez szigorúan spekuláció -, hogy ez az egész leginkább egy belső energiagazdálkodási hibára utal, ha az összes mag egyszerre terhelt, akkor előfordulhat a körülmények egy különleges együttállásakor, hogy valami belül nem kap elég feszültséget, vagy a sok párhuzamos terhelés miatt túl sok zaj kerül egy belső tápvonalra. A túlfeszelés vagy feszültségcsökkentés két okból nem tudhatja korrektül megoldani: egyrészt minden részegység fogyasztása egyszerre változik tőle, tehát a belső feszültségingadozás mértéke is arányosan együtt fog mozogni a tápfeszültség változtatásával. Másrészt lehet, hogy a belső tápelosztó hálózatban valami beépített szabályozás ellenkorrigálja a külső feszültségemelést. Na itt lehet, hogy valamit tényleg túl szorosra szabtak, és nem tudják AGESA-ból a belső energiagazdálkodást vezérlő mikrokóddal korrigálni.
Az is biztos, hogy több alaplapról bebizonyosodott, hogy a memóriát, pontosabban a Ryzen memóriavezérlőjét és vele együtt a teljes uncore-t overclock-olják, ami tud nagyon hasonló hibákat produkálni. Elvileg a legjobb eset 1modul/csatorna single rank modul esetén 2400 MHz a támogatott max freki, de 2 modul esetén már csak 2133 MHz, dual rank modulnál már csak 1866 MHz. Viszont megfelelő modul esetén az alaplapok XMP profilból simán megpróbálnak beállítani 3000 vagy 3200MHz-et is, ami az újabb AGESA kiadás óta többé-kevésbé sikerül is, csak éppen kissé hibázik. Jelen pillanatban a segfault-ra tesztelőket kérik is, hogy ügyeljenek rá, hogy a memória véletlenül se menjen az AMD-által hivatalosan támogatott órajel fölött.
-
tlac
nagyúr
Az AMD community oldalon viszont állítják, hogy nem segít
pedig az, hogy a feszültségemelés hatására később döglött meg az egyik community-s user beszámolója szerint, ez alapján lehet hogy az tpu-s usernek szerencséje volt és nála tényleg segített, mert éppen jobb minőségű szilícium darab jutott neki
Ez ugyan általánosságban igaz, de a mostani konkrét esetben nem utal semmi arra, hogy túl magas modellszámot kaptak volna, és alacsonyabb modellszámmal és hozzá tartozó frekvenciával stabilak lennének.
vagy az összes kategóriát túl szorosra lőtték meg
mivel azt szinte biztos, hogy pár teszteset kimaradt és lehet ehhez állították be azt a maximumot, amit még elvisel a procibár ennek ellentmond, hogy a underclock sem segít, ha jól értem
-
XMI
csendes tag
az itteni hírből származik
Nekem valahogy elsőre leesett, hogy a cikk ezt így szó szerint nem állítja, de visszaolvasva már értem, miért gondolhatják úgy. Valóban félrevezető itt példálózni ezzel:
"az adott modell hitelesítésénél a tesztek nem fednek le minden eshetőséget, így esetlegesen olyan paraméterezést kaphat egy lapka, amelyet bizonyos körülmény mellett nem bír el."
Ez ugyan általánosságban igaz, de a mostani konkrét esetben nem utal semmi arra, hogy túl magas modellszámot kaptak volna, és alacsonyabb modellszámmal és hozzá tartozó frekvenciával stabilak lennének. Ha csak nem tekintjük modellszámnak a "0"-t, mint "selejt" besorolást is.
Azért fogalmaztam úgy, hogy a 'legtöbb felhasználónál' nem oldja meg, mert a napokban egy user a techpowerup fórumban elkezdte terjeszteni, hogy a túlfeszelés megoldja: [link]
Az AMD community oldalon viszont állítják, hogy nem segít: [link]
ez elég erős kijelentés, biztos vagy benne, hogy nincs rá példa?
Én természetesen nem vagyok biztos benne, próbáltam is direkt óvatosan fogalmazni, de ahogy olvasom többen is kutatnak ilyen után az AMD community fórumban, Redditen is, phoronix fórumban is, és hírértéke lenne, ha fognának ilyet. A táblázatba biztosan azonnal beírnák. Fogalmazzunk úgy, hogy boltból vett hibátlan Ryzen valamint tesztelni és eredményt megosztani kívánó user ezidáig nem találkozott össze. -
Raymond
titán
"ez elég erős kijelentés, biztos vagy benne, hogy nincs rá példa?"
Az osszes oldal/forum ahol ezzel foglalkoznak egyseges ebben a velemenyben. A 25.-ik het gondolom nem veletlenszeru szam es valami oka van hogy azt avgy ujabbat kuldenek cserebe. A fenti idezet azert is implicit valos mert 25.-ik heti vagy ujabb gyartmanu termek meg nincs a polcokon.
-
tlac
nagyúr
köszi a részletes összefoglalót
tehát nem arról van szó, hogy a hibás darabok túl magas modellszámot kaptak volna, nem tudom honnan veszik itt a fórumban ilyen sokan ezt az információt
az itteni hírből származik
A processzor órajel-csökkentése, memória órajel-csökkentése, túlfeszelés a legtöbb felhasználónál nem oldja meg a problémát
ezek szerint volt akinél megoldotta?
mert ha igen, akkor helyes lehet az a következtetés, hogy csak órajel lett rosszul belőveJelen pillanatban nincs olyan ismert eset, ahol boltban vásárolt Ryzen processzor átment volna a kill-ryzen teszten
ez elég erős kijelentés, biztos vagy benne, hogy nincs rá példa?
-
XMI
csendes tag
Egy pillanat!
Itt igen sok téves állítást látok tényként leírva.
Mivel alapvetően Linux-ot használok és szándékoztam Ryzen-t venni, kicsit közelebbről követtem a hiba körüli történet alakulását.Először is ajánlom figyelmébe minden érdeklődőnek az AMD community oldalán levő fórumtémát, jelen pillanatban itt találhatóak a leginkább elsőkéz-közeli információk: [link]
Másodsorban ajánlom a folyamatosan frissülő követő táblázatot, ahol gyártási dátummal követik a hibás és hibátlan processzorokat: [link]
Az AMD community thread alapján eddig ismert tények a következők:
- Kétféle hiba van: a segfault és a machine check exception / random reboot. Ebből a segfault-os hiba kapott nagyobb hírverést.
- Kezdem az egyszerűbbel: a machine check exception / random reboot hiba a gép üresjárati állapotában jön elő, egyértelműen energiagazdálkodási eredetű, van rá ismert workaround: a C-state-eket, vagyis energiatakarékos processzorállapotokat le kell tiltani BIOS-ban. Viszonylag kevés processzort érint.
- A segfault hiba gcc vagy clang-os fordítással reprodukálható, más módszer egyelőre nem ismert, a processzor bármilyen más tesztben stabilnak mutatkozik. A kill-ryzen teszt [link] is ezzel a módszerrel provokálja.
- A segfault hibát nemcsak Linux alatt lehet reprodukálni, kellően intenzív sokszálú gcc vagy clang fordítással Windows alatt is előjön.
- A WSL esetén nincs Linux kernel sehol a rendszerben, ilyenkor a windows kernel látja el a Linux kernel szerepét. A legvalószínűbb következtetés, hogy a hiba nem oprendszer-specifikus.
- Az ilyen fordítási terhelés egyáltalán nem "extrém" és nemcsak fanatikus Gentoo felhasználókat érint, akik mindent maguknak fordítanak, hanem például szoftverfejlesztőket is, akik munkához használnák build gépnek.
- A segfault hibára eddig nem ismert workaround. Vannak akiknél az SMT vagyis a magonként kétszálas végrehajtás letiltása hozott javulást, vannak akiknél a BIOS-ban az uOpCache vagyis mikroművelet gyorsítótár tiltása segített valamennyit (5-7% teljesítménycsökkenés árán), vannak akiknél a Linux kernelben a címtartomány randomizációs biztonsági feature kikapcsolása javított a helyzeten. Általános megfigyelés, hogy egyik megoldás sem oldja meg teljesen a problémát, csak lecsökkenti az előfordulás gyakoriságát.
- A processzor órajel-csökkentése, memória órajel-csökkentése, túlfeszelés a legtöbb felhasználónál nem oldja meg a problémát -> tehát nem arról van szó, hogy a hibás darabok túl magas modellszámot kaptak volna, nem tudom honnan veszik itt a fórumban ilyen sokan ezt az információt
A hiba előfordulásáról:
- Jelen pillanatban nincs olyan ismert eset, ahol boltban vásárolt Ryzen processzor átment volna a kill-ryzen teszten! Ez még nem feltétlen jelenti azt, hogy az összes Ryzen hibás lenne, hiszen akinek hibátlan jutott, az nem biztos hogy egyáltalán foglalkozik a problémával. De ezidáig senki nem állt elő ilyennel, ami legalábbis gyanús.
- Bizonyítottan hibátlan Ryzen processzorhoz eddig csak RMA (gyártói garanciális) csere útján jutottak hozzá
- A Threadripper és EPYC processzorokból eddig nem találtak hibásat
- Az RMA-csereprocesszorok mind 25. hetiek vagy későbbi gyártásúak voltak
- Már legalább két felhasználó jelezte, hogy 25. vagy későbbi gyártású processzor is hibás (az írás pillanatában is próbálják ellenőrizni, hogy nem más-e a hiba oka, pl XMP profil hibás kezelése miatt RAM instabilitása). Mindenesetre egyelőre nem jelenthető ki, hogy a 25. heti vagy későbbi példányok biztosan jók lennének.
- A visszakapott RMA cserepéldányok közül jónéhány felhasználó jelezte, hogy a dobozában post-it cetlit találtak "Pass", "Passed", "Ok" feliratokkal. Vagyis igen valószínű, hogy a jó processzorok külön kézi tesztelésen mentek át.
Jelen pillanatban ismert tények alapján sokan arra következtetnek, hogy az AMD valójában még nem tudta megbízhatóan megoldani a problémát, egyszerűen kézzel válogatják az RMA-hoz a véletlenül jól sikerült példányokat.
-
CPT.Pirk
Jómunkásember
Nem keverednek a fogalmak. A processzor továbbra sem hibás, csak rossz kategóriába került besorolásra. A cég elismerte a probléma létét és cserélik is a rossz kategóriás termékeket. Igazából nincs itt semmi látnivaló, ez nem TLB bug vagy valami hasonló.
Továbbá ahogy sh4d0w is mondja, nincs hibátlan processzor a piacon, régen sem volt és ezután sem lesz. Egyszerűen lehetetlen olyat gyártani.
-
_DiEGO_
őstag
Nagy lol , mert ez így teljesen IGAZ
abból a szempontból , hogy hibátlan termék nem létezik . Hibás termékek léteznek , csak nem tudunk a hibáikról 
max ha nyilvánosságra hozzák.
Ha nem robbantják ki USA-ban a diesel ügyet , sosem tudtuk volna meg hogy szinte az összes dízel gyártó csal szoftveresen, de még a benzines vissza van
csak valakiknek kell hogy nagyon ba...ák a csőrüket. Például USA idetolna csomó benzines autócsodát és európai kocsikat nemigazán vennének... -
tlac
nagyúr
-
_DiEGO_
őstag
-
CPT.Pirk
Jómunkásember
Ez már nagyon erőltetése a dolognak... A termék továbbra sem hibás, csak a nem elég megbízható tesztelés miatt néhány példány kapott olyan órajel és társai paramétereket, amiket bizonyos körülmények között nem bír el. Itt a hibás a tesztelés volt, ezért is cseréli a procikat az AMD.
Azért kell ezt kihangsúlyozni mert messze nem arról van szó, hogy a mérnökök elrontották volna a procit és így hibás lenne a termék. (értve ezt a minden létező procinál meglévő errata-s hibákon felül)
-
Cathulhu
addikt
Aki kicsit ert a linuxhoz, annak segitseg, mert latom sok a zavar (aki meg nem ert hozza, az ne agonizaljon olyan hiban, ami soha nem fogja erinteni jelenlegi tudomasunk szerint)
1) Tolts le egy x64-es Ubuntu 17.04 distrot.
2) UUIval csinalj egy bootolhato pendriveot
3) toltsd le ezt a script gyujtemenyt zipkent
4) tomoritsd ki a pendrivera
5) bootolj a pendriverol, try ubuntu
6) terminalba cp -r /cdrom/ryzen-test-master ./
7) cd ryzen-test-master
8) chmod +x kill-ryzen.sh
9) ./kill-ryzen.shfejbol irtam, ha elirtam valamit, bocs
ha jon segfault viszonylag az elejen, akkor irj az AMD-nek, ha nem, akkor felesleges gyotorni magad, valoszinuleg semmi baja a procidnak
menet kozben df -h /mnt/ramdisk menjen parszor, mert 64 GB-os ramdisket csinal es nyilvan ha betelik a ramod, akkor ugyis kipurcan. -
Abu85
HÁZIGAZDA
Nem pont a gyártás számít. Így nem lehet megállapítani, mert számos jó proci is van. Persze az AMD-nek sokkal nagyobb az adatbázisa és a rálátása, így ők lehet, hogy ebből is meg tudják mondani nagy pontossággal. Például tudják, hogy melyik die hol helyezkedett el a waferen, stb.
Nem valószínű, hogy ott cserélheted, ahol vetted. A boltot azért akarják kizárni, mert ott azt fogják neked mondani, hogy nincs semmi baja, ugyanis akármeddig tesztelik tipikus Windows környezetben, a proci nem fog hibát jelezni. Windows alatt még nem sikerült ezt reprodukálni Linux subsystem nélkül. Lehet, hogy megvan a módja, de még senki sem jött rá, hogy mi az.
-
_DiEGO_
őstag
Az egész cikkhez miért nem csak az AMD-s felhasználók jönnek ? Miért kell teleszemetelni egy sokakat érintő vagy érinthető információs oldalt nem AMD processzorokkal rendelkezőknek ? Idejönnek okoskodni , illetve csak hergelik azokat akiket picit sem kellene . Mi ez itt óvoda ? Én sem azért jöttem az oldalra / ebbe a topikba , hogy ilyen ocsmánykodást olvassak , hanem informálódásként. De legalább moderátorok törölnék a kéretlen hsz-eket...
Node miért is vagyok itt ? Jah , mert esetleg érintett lehetek (?) a dologban ...
Nos az én procimon :
UA 1715 PGT
Plusz , ugyanott készült a proci:
Made is MALAYSIA
Valami pontosabb listáról ha tudna valaki , hogy az ott készült procik ezzel a PGT jelöléssel meddig voltak gyártva ?
http://support.amd.com/en-us/contact/email-formIde már írtam , jeleztem s küldtem 3 képet is hogy valóban AMD Ryzen tulaj vagyok . Annyi történt , hogy felvettek a listára és hogy még kapok majd mailt .Ellenben én ott szeretném cseréltetni ahol vettem , ha erre sor kerül.
Intel fanok kerüljenek , mert i5 procit cseréltem le , mert nagyon nem szerette ha mind a négy magot terheltem MMORPG játékommal ... 3 Bot és egy online , ugyan az a game csak 3X BOT proggi vitte és egyet online magam. Ha úgy gondolta hogy nincs elég erőforrása ledobta egyik BOT proggit . Egy évig szenvedtem vele , elég volt ... egy játék miatt meg nem fogok egy 120K i7-et venni ... nem is tudtak meggyőzni
-
#82729984
törölt tag
"Itt nincs mit kezelni, mert csak a tesztelő folyamat nem volt maximálisan alapos"
Ez csak gumicsont, az összes hibára rá lehet fogni hogy a tesztelő folyamat nem volt maximálisan alapos.
Te láttál már olyan hibás terméket ahol a tesztelő folyamat maximálisan alapos volt? Na ugyeA kettő kölcsönösen kizárja egymás.
-
CPT.Pirk
Jómunkásember
válasz
#82729984
#86
üzenetére
Nem. Az gyári hiba, ami bekerül az errata-ba és később ilyen vagy olyan úton de kezelik. Itt nincs mit kezelni, mert csak a tesztelő folyamat nem volt maximálisan alapos és így a termékek közül néhány olyan kategóriába került, ahová nem kellett volna neki. De ettől még nem hibás a termék...
-
Abu85
HÁZIGAZDA
válasz
#82729984
#86
üzenetére
Ezt már a gyártók megkülönböztetik, mert ha fizikai probléma van, akkor módosítani kell a gyártóst. Emiatt a gyártási hiba mellett már létezik a minőségbiztosítási hiba is, amibe azok a hibát tartoznak, amelyek javítása nem igényli a gyártástechnológia módosítását. Bármilyen hibát be lehet sorolni ebbe a három kategóriába: tervezési, gyártási és minőségbiztosítási. Utóbbinak azért van különösen nagy jelentősége, mert ezek után a hibák után is kutatnak, tehát a hitelesítés egy termék élettartama alatt többször megváltozik, csak nem kürtölik világgá, hogy találtak laborkörülmények között egy olyan reprodukálható tesztsort, amit ki kell szűrniük, hogy az alatt is stabil maradjon a processzor.
-
#82729984
törölt tag
Igazából ez gyártási hiba (vagy nevezhetjük gyártástechnológiai problémának is), ahogy korábban már írták.
Az hogy a hitelesítési teszt nem fogta meg részletkérdés, igazából hozzád csak úgy kerülhet bármilyen gyártó bármilyen hibás terméke hogy a gyártó tesztje nem szűrte ki. De ettől még ezt gyártási hibának hívjuk nem teszthibának.
-
-
Yutani
nagyúr
Szalmabáb érvelést jelez a detektorom...
Nem a processzorról van itt szó, nem érdekel, hogy mennyire jó vagy gyenge játék alatt, hanem egy hibáról, annak feltárásáról, megelőzéséről és a hibás termékek cseréjéről van szó. Az AMD elismerte a hibát, javította a tesztelési eljárást, valamint cseréli a hibás processzorokat. Ami hülyeség, az a hibán való felesleges rugózás. Ez nem egy fix, architektúra hiba, amit csak BIOS frissítéssel lehet javítani (lásd Skylake és Kaby Lake HT hiba), hanem egy validációs hiba, amit az eljárás módosításával kiküszöböltek.
A szerverprocesszorok meg azért jönnek később, mert azoknak hosszabb a validációs eljárásuk. Ezért jött márciusban a Ryzen, és ugyanezért jött csak ki a Treadripper és EPIC az elmúlt 1 hónapban.
Problem?
-
Jack@l
veterán
Ahha, szóval hülyeség egy procicsaládról csúnyát mondani amelyik épp a HEDT meg Server platformra készül betörni, mert játékra elég gyenge...
Mit gondolsz ezeken a vonalakon mekkora valószínűséggel botlanak bele a linuxba és gcc-be? Jó dolog e úgy árulni a cuccot, hogy az éppen beüzemelendő szervert még tesztelgesse a devops, meg küldje vissza pár hétre gariztatni a procit? -
Yutani
nagyúr
Jól van, értelmezd félre nyugodtan a szavaimat! De emeld ki légy szíves, hogy hol ostobáztam le a GCC-t futtató felhasználókat! Ugye?
[moderálva]
Tényleg kell még ezen rugózni, vagy zárható a topik és áttérhetünk egy másik témára, ahol tovább lehet fikázni az AMD-t?
[ Módosította: Qru ]
-
Oliverda
félisten
We saw some really bad Intel CPU bugs in 2015, and we should expect to see more in the future
Anyway, back to 2015. We’ve seen at least two serious bugs in Intel CPUs in the last quarter, and it’s almost certain there are more bugs lurking. Back when I worked at a company that produced Intel compatible CPUs, we did a fair amount of testing and characterization of Intel CPUs; as someone fresh out of school who’d previously assumed that CPUs basically worked, I was surprised by how many bugs we were able to find. Even though I never worked on the characterization and competitive analysis side of things, I still personally found multiple Intel CPU bugs just in the normal course of doing my job, poking around to verify things that seemed non-obvious to me. Turns out things that seem non-obvious to me are sometimes also non-obvious to Intel engineers. As more services move to the cloud and the impact of system hang and reset vulnerabilities increases, we’ll see more black hats investing time in finding CPU bugs. We should expect to see a lot more of these when people realize that it’s much easier than it seems to find these bugs. There was a time when a CPU family might only have one bug per year, with serious bugs happening once every few years, or even once a decade, but we’ve moved past that. In part, that’s because “unpredictable system behavior” have moved from being an annoying class of bugs that forces you to restart your computation to an attack vector that lets anyone with an AWS account attack random cloud-hosted services, but it’s mostly because CPUs have gotten more complex, making them more difficult to test and audit effectively, while Intel appears to be cutting back on validation effort. Ironically, we have hardware virtualization that’s supposed to help us with security, but the virtualization is so complicated that the hardware virtualization implementation is likely to expose “unpredictable system behavior” bugs that wouldn’t otherwise have existed. This isn’t to say it’s hopeless – it’s possible, in principle, to design CPUs such that a hang bug on one core doesn’t crash the entire system. It’s just that it’s a fair amount of work to do that at every level (cache directories, the uncore, etc., would have to be modified to operate when a core is hung, as well as OS schedulers). No one’s done the work because it hasn’t previously seemed important.
Vonatkozik az AMD-re is.
-
Yutani
nagyúr
Ha egy szakmai oldalon ilyen sok ostoba véleményalkotó ember van, akik szerint az AMD csal (átver, meglop, megcsinál téged szárazon és még csak fel sem hív utána), akkor mit várjunk az egyszeri PC felhasználótól? Így alakulnak ki az urban legendek, ami után persze, hogy nem tudja az AMD feljebb tornázni a részesedését, vagy legalábbis nagyon nehezen.
De mindegy is, nekem Kaby Pentiumom van, engem nem csinál meg az AMD!
-
VirsLee
őstag
Az elegedetlenkedoket kerdeznem, hogy szerintuk mi a helyes ut ilyen esetben? Mitol lennenek elegedettek? Szimpla tesztelesi hiba a gyartas folyaman. Millio egy ilyen vesz korul minket szamos kulonbozo termeknel, a rossz teszteles miatt hibasan besorolt procikat cserelik, mi kell meg? Van itt legalabb egy nyavajgo, akit erint a dolog? Elmondtak, hogy elkurtak, garancia kereteben cserelik, ennyi. Aki szembesult a problemaval annak ez egy jo megoldas, akinek pedig ryzen procija sincs, csak nyavajog, az ne lepodjon meg, hogy nem az tortenik, amit o szeretne, hisz nem erintett ebben a tortenetben...
-
Jack@l
veterán
A helyzet az, hogy engem baromira zavarna, ha olyan hektikus lenne egy proci gyártása, hogy még a ráírt alap órajelen is instabil. Ez nem túl jó ómen, ha valaki netán egy kis tuning reményében venne procit... (mert valljuk be 4 ghz környéke elkél a ryzennek az elfogadható egyszálas teljesítményhez)
-
#63
janos666
nagyúr
Dr. Romano
#59
janos666
nagyúr
válasz
Dr. Romano
#59
üzenetére
Az, hogy dokumentálva van egy jól körülírható, ismert módon előállítható tesz, ami jó eséllyel reprodukálja a hibát, az nem azt jelenti, hogy csak és csakis olyankor fordulhat elő. Más körülmények közt is megtörténhet hasonló.
Ez a felhasználók által körülírt "teszt" is egy olyan teszt, aminek egy ideális világban eleve a gyári tesztelés részét kellett volna képeznie valamilyen formában (nem pont GCC-t kellett volna futtatni rajta, de valamit, amitől előáll ez a bizonyos állapot). Ez nem így volt, tehát hiányos volt a teszt, ami hibás termékek eladásához vezetett.
Ezen nincs mit tovább magyarázni, hogy Józsi úgysem futtat soha GCC-t rajta, csak Excel-t. Ha GCC-vel kidől 10-ből 9-szer 1 perc után, akkor lehet hogy Battlefield alatt is kidől 10-ből 1-szer 60 perc után, csak az olyan ritka és olyan nehéz megfogni, mitől volt, hogy csak vakargatja évente egyszer Józsi a fejét, hogy "naba... most mé fagyott meg, he!?".
Attól hogy egy hiba nem tragédia, a hiba az még mindig hiba, nem nem-hiba. Ha nem-hiba lenne, akkor akkor nem lenne hiba. Ez pedig itt hiba.
-
#59
Dr. Romano
veterán
[CS]Blade2
#55
Dr. Romano
veterán
válasz
[CS]Blade2
#55
üzenetére
Ahogy olvasom a cikket nem winrar alatt dőlt ki
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#57
antikomcsi
veterán
Real_Gabe
#54
-
#56
schawo
titán
[CS]Blade2
#55
válasz
[CS]Blade2
#55
üzenetére
Ez a cucc gyárilag kidől egy tesztprogram alatt
-
#55
[CS]Blade2
addikt
Dr. Romano
#50
[CS]Blade2
addikt
válasz
Dr. Romano
#50
üzenetére
Ez inkább úgy nézne ki, hogy
megvetted azt a 2Ghz-es procit, és alapórajelen használtad, de az WinRAR alatt mindig kidőlt, és onnantól inkább nem tömörítettél vele.Ez a cucc gyárilag kidől, ami azért kicsit más kategória, hiába garanciális hiba.
-
Real_Gabe
tag
Jézusom, hogy lehettek ennyire fogalmatlanok?!
Nem a lapka a hibás, hanem a teszt, amivel meghatározták a processzor paramétereit!
Ez annyit jelent,hogy egy lapkát a teszt alapján 1800X-nek soroltak be, holott mondjuk csak sima 1600-asnak kellett volna, mert nem bírja azokat az órajeleket, amiket 1800X-ként kellene bírnia, ezért magas órajelen nagy terhelés mellett elkezd hibázni.
Ezért is cserélik, hisz a prociba bele van ütve hogy ő egy 1800x és eszerint kezeli a gép, holott 1600-ként kellett volna gyárilag minősíteni. Ezért kicserélik neked egy olyan 1800X-es procira, ami már az új teszten ment át, és biztosan bírja azt amit egy 1800x-nek tudnia kell.
Ennyi történt!
-
#95904256
törölt tag
Az AMD csak azt tagadja, hogy a lapka tervezése lenne a hibás. Azt nem állítják, hogy nem hibáztak. Sőt, cserélik is a hibás darabokat.
1994-ben volt az Intel-nek egy FDIV bug nevű bakija a Pentium processzorok első szériájánál. Ez annak idején 475 millió dollárjába került az Intel-nek. Gondolom, egy ilyen jellegű dolognak kíván elébe menni az AMD.
Egyébként az "teljesen normális", hogy több tucat hiba van egy új processzorban.
-
-
#50
Dr. Romano
veterán
Dr. Romano
veterán
Na ez most olyan mint amikor az E2180-as procimat húztam anno 2GHz-ről 3,2GHz-re. Napi használatban, soha nem volt vele gondom stabilan tette a dolgát, de komoly prime95 stressz alatt viszont kidőlt.
A vége az lett hogy használtam ugyanúgy napi szinten 3,2GHz-n csak nem futtattam prime-ot, ennyi -
-
Abu85
HÁZIGAZDA
Natív Windows környezetben még nem tudták reprodukálni. Próbálták, de sehogy se megy. Ezért kezelik csak Linux (subsystem)-hez kötődő problémaként.
(#42) ddekany: Olyan volt, hogy a környezeti hőmérséklet csökkenésével elmúlt a hiba. Sokkal valószínűbb egyébként, hogy az órajelváltás hozza elő, de erről kevés az adat.
-
ddekany
veterán
Ha csupán a paraméterek meghatározása volt túl optimista, akkor elég hamar le kellett, hogy vonják a kísérletező magánemberek a tanúságot, hogy alacsonyabb órajelen és tán magasabb feszültségen stabil. Volt ilyen konklúzió részükről, csak nem jött át a médián? Ha meg nem volt, akkor nem kerek a sztori.
-
#39
Abu85
HÁZIGAZDA
antikomcsi
#38
Abu85
HÁZIGAZDA
válasz
antikomcsi
#38
üzenetére
Ezért van garancia. Ott a teszt, telepíts Linuxot, vegyél elég memóriát, és megmondja, hogy érintett vagy-e.
-
#38
antikomcsi
veterán
Zeratul
#25
antikomcsi
veterán
Amikor nálad van, mint felhasználó, és rossz, akkor minek a hibája?
Semmihez nem nyúlsz, se szoftverhez, se más hardverhez, csak kicseréled a cpu-t egy újra, egy másikra, ami után minden megjavul, akkor mi okozta a hibát?
Te valamit vettél, amit úgy szeretnél használni, ahogy vetted, de arra nem alkalmas, akkor az sajnos hibás termék. Lehet, hogy 1800X-nek nem jó, de majd 1700-nak jó lesz, de attól még te rossz terméket kaptál. Az, hogy milyen okból, az már csak rizsa!
-
Abu85
HÁZIGAZDA
De, pont az a lényeg, hogy ekkora monstrumot futtass, mert alatta nem jön elő a probléma. Itt nem egy egzakt szilíciumban megbúvó dologról van szó, hanem arról, hogy egy olyan extrém terhelést kényszeríts a rendszerre, amelytől az instabillá válik. Ha ezt nem tudod alárakni, akkor sose lesz instabil.
Nem fogják megmondani. A részükről valószínűleg az ügy ezzel le van zárva. Aki jelentkezik, és hibás a termék, annak kicserélik.
-
tlac
nagyúr
egy tesztalkalmazás is felépíthetné a hozzávaló környezetet
másrészt az amd valószínűleg már pontosan tudja, hogy hol van a gyenge láncszem és nem kellene egy ekkora monstrumot futtatniegyébként az is segítség lenne, ha megmondanák, hogy mikortól vezettek be a szigorúbb tesztelést
az újakkal valószínűleg már felesleges küzdeni -
Abu85
HÁZIGAZDA
Világos, de a hiba jellege eleve olyan, hogy nem lehet egy szimpla tesztalkalmazással előhozni, tehát mindenképpen muszáj felépítened otthon azt a környezetet, amivel ez elő is jön. A másik lehetőség, hogy az AMD-t megkéred, hogy vizsgálja be a terméked, és ha nem jó, akkor cseréljék, ha jó, akkor pedig küldjék vissza. Ezért használják a Costumer Care csatornát a kereskedők kizárásával.
-
Abu85
HÁZIGAZDA
Lényegében igen. A rostán a lyukak túl nagyok voltak, így az elején átment olyan lapka is, ami valójában nem volt elég stabil az adott paraméterezésre.
Kb. hasonló a dolog, mint amikor megy az undervolting a GPU-knál, hogy a hülye AMD túl nagyra nyomta a feszültséget, és a user tuninggal korrigál. Látja, hogy nem okoz semmi hibát, miközben biztos van olyan extrém terhelés, amikor már gondot jelentene az alacsonyabb feszültség. Csak a felhasználók 99%-a a termék használata alatt nem fut bele.
Világos, kiegészítem, hogy érthetőbb legyen.
-
Oké, megvilágosodtam, már nem vagyok Matolcsi. Tehát arról van szó, hogy nem jól szűrték ki a gyártási hibákat.
Ez van a cikkben:
Ezek miatt már az eredeti hírben is kifejtettük, hogy a hitelesítési teszt lehet a bűnös, ugyanis egy processzort a dobozolása előtt egy komplett tesztsorral ellenőriznek, és ekkor határozzák meg a lapka paramétereit is.De a lapka paraméterei kifejezés számomra teljes homály, szóval a cikk semmit sem segített.
Ez az ami segített
Ez alapján mondják meg az adott lapkáról, hogy melyik tényleges termékjelölést kapja meg. -
Abu85
HÁZIGAZDA
Benne van a hírben csak el kellene olvasni. A hitelesítési teszt alapján határozzák meg egy processzor végleges paramétereit. Ez alapján mondják meg az adott lapkáról, hogy melyik tényleges termékjelölést kapja meg.
Eleve a hiba jellege olyan volt, hogy nem minden CPU-val jött elő. Tehát van számos korai Ryzen, amelyek hibátlanok, illetve az egész a környezeti hőmérséklettől is függ. Emiatt merült fel már az elején, hogy itt a hitelesítés a gond, mert nem mindenki futott bele ebbe a hibába. Az új is azért jó, mert az éppen jól lett lehitelesítve, holott fizikai szinten semmit sem változott.
-
#25
Zeratul
addikt
antikomcsi
#21
Zeratul
addikt
válasz
antikomcsi
#21
üzenetére
Abu már elmondta, az órajel validáció hibája. Adott lapka nem bírja az extrém terhelést adott órajelen. Intel esetében ez nem bug lenne hanem feature.
-
#22
Abu85
HÁZIGAZDA
antikomcsi
#21
Abu85
HÁZIGAZDA
válasz
antikomcsi
#21
üzenetére
A hitelesítési teszt hibája.
Ezeknek a termékeknek ugyanaz lesz a sorsuk, mint amikor egy gyári tuningos VGA visszakerül instabilitás miatt. Újra hitelesítik őket, és az új paraméterekkel mennek a megfelelő batch-be, ahol újra értékesítik őket. -
#21
antikomcsi
veterán
antikomcsi
veterán
Akkor minek a hibája?Egyébként engem nem érint a jelenség, és még csak az sem zavar, hogy van ilyen, hisz valljuk be, hogy előfordulhat, ha meg cserélik is, akkor meg még inkább nem számít.
Maga a hülyítés az, ami zavar egy ilyen esetben!
-
#20
Abu85
HÁZIGAZDA
huskydog17
#14
Abu85
HÁZIGAZDA
válasz
huskydog17
#14
üzenetére
Ez nem tervezési hiba, hanem egy hitelesítési. Kb. ugyanaz a kategória, mint amikor a gyári tuningos VGA-k nem működnek.
Persze, hogy cserélik, hiszen rosszul lett az órajel-paraméterezésük meghatározva, de csak a hibás procikat cserélik, és egy szót sem mondtak a gyártási időszakról. Ezt a Phoronix költötte bele.
A cím közkívánatra egyértelműsítve.
-
-
Abu85
HÁZIGAZDA
Ez elég jó. [link]
Natív Windows környezetben még nem tudták reprodukálni, így mindenképpen Linux kell hozzá, akár WSL formában.(#12) arn: Sehol. Ezért van a gari. Ha kiteszteled és hibás, akkor küldheted vissza, és küldenek egy másikat.
(#17) jacint78: Hardveres a hiba, csak nem tervezési, vagyis a lapka jó. Olyan jellegű a gond, mint amikor a VGA-k gyári tuningja sok, és fagy. Az se a lapka hibája, de kicserélik a VGA-t.
-
#14
huskydog17
addikt
huskydog17
addikt
Cím:
"Nem a lapka hibája az egyes asztali Ryzen processzorok Linux alatti viselkedése"
Inkább no comment. Inkább utánaolvastam máshol is.
Akkor egészítsük ki egy picit a "hírt" az eredeti infókkal:
Augusztus 7-én:
"This morning I was on a call with AMD and they are now able to confirm they have reproduced the Ryzen "segmentation fault issue" and are working with affected customers."Tehát AMD elismerte a hardveres hibát.
További fontos infó:
"AMD has not provided an official public explanation of the fundamental problem, but from those in our forums and elsewhere, it appears to affect Ryzen CPUs manufactured prior to week 25."Végezetül az AMD szó nélkül cseréli a hibás CPU-kat.
Szóval a PH hír címe Epic Fail!
#10 Szaby59: +1! Ezek után mégis mit gondoljon az olvasó a PH lapcsaládról?
-
-
Zotya84
őstag
És akkor a kétforintos kérdés: Amennyiben a termék nem változott olyan mértékben, hogy új steppinget kapjon, de mégis változott, viszont az egyikkel nem megy, a másikkal igen, akkor mégis minek a hibája, ha nem a lapkáé? Azt nekem ne mondja senki, hogy egy teszt megváltoztatása után jó lesz a lapka, ami eddig nem volt jó arra a spéci feladatra...
Vagy én keveredtem bele ebbe a változott, de mégsem, így vagy érintett, de lehet, hogy mégsem, ugyan nem a lapka hibája, de mégis kicseréljük, ha a tied nem jó dologba?
Kérdezem ezt egy 1700X eddig elégedett, újdonsült tulajaként.
Szerk.: Ahogy látom, nem csak én furcsállom a dolgot.
-
Egon
nagyúr
A hír címe: Nem a lapka hibája az egyes asztali Ryzen processzorok Linux alatti viselkedése
A hírből egy mondat: Az AMD hivatalosan azt javasolja, hogy ha valaki belefutott a hibába egy adott Linux disztribúcióval, akkor jelentkezzen az AMD Customer Care szolgáltatáson keresztül és kicserélik a processzort.
Tehát nem a lapka hibája, de ha valaki belefut, cserélik. Értem...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Hatalmas és igaz.
Nem megbántva a linuxos társadalmat. 
abból a szempontból , hogy hibátlan termék nem létezik . Hibás termékek léteznek , csak nem tudunk a hibáikról 
max ha nyilvánosságra hozzák.
Új hozzászólás Aktív témák
- MW2 - MW3 játékosok baráti köre
- Mibe tegyem a megtakarításaimat?
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- Sorozatok
- PROHARDVER! feedback: bugok, problémák, ötletek
- Kínai és egyéb olcsó órák topikja
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- PlayStation 5
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Nintendo Switch 2
- További aktív témák...
- AMD Ryzen 7 7700X - 8 mag 16 szál - AM5 - ÚJ! Bontatlan
- ÚJ AMD Ryzen 5 3600 4.2GHz Socket AM4 BOX Processzor - Áfás számla & garancia
- ÚJ AMD Ryzen 5 5600X 4.6GHz Socket AM4 OEM Processzor - Áfás számla & garancia
- AMD Ryzen 7 7800X3D Processzor - Készletről Azonnal - Áfás Számla & Garancia
- AMD Ryzen 5 7500F Processzor - Készletről Azonnal - 27% Áfás Számla & Garancia
- PS Plus előfizetések
- 3DKRAFT.HU - 3D NYOMTATÁS - AZONNALI ÁRAJÁNLAT - GYORS KIVITELEZÉS - 480+ POZITÍV ÉRTÉKELÉS
- ÁRCSÖKKENTÉS Dell Latitude E6320 notebook eladó
- Game Pass Ultimate előfizetés azonnal, élettartam garanciával, problémamentesen! Immáron 8 éve!
- HATALMAS AKCIÓK / MICROSOFT WINDOWS 10,11 / OFFICE 16,19,21,24 / VÍRUS,VPN VÉDELEM / SZÁMLA / 0-24