AMD Zen

[Nerkoon]

Jos osa noista prosessoreista ei koskaan saa tuota virhettä esiin, niin minusta se on merkki siitä, että kyse on joko valmistusongelmasta tai linuxista itsestään.

 

[vmovapd]

Kyllä se on kaikilla ryseneillä, Threadripperistä ei tietoa eikä EPYC:stä. Ja Threadripper on edelleen B1, ainoastaan EPYC on B2.

Kippaa EPYC:llä.

 

[Nerkoon]

Eli B2 ei korjaa sitä. AMD:n vastausta odotellessa

EDIT: Monikaan ei varmaan enää muista ja aikaakin on kulunut niin paljon, että netistäkään ei paljoa enää siitä tietoa löydy, mutta Intelin Pentium 3 aikakausi loppui prosessoriin joka ei pystynyt kääntämään Linuxin kerneliä. Tuossa tapauksessa syy oli suorastaan nolo: jos prosessoria alikellotti hiukan, käännös onnistui eli Intel myi vakiona liikaa ylikellotettua prosessoria. Kyseinen malli vedettiin kaikessa hiljauudessa takaisin ja jäi viimeiseksi P3 prosessoriksi.

 

[Sargo]

EDIT: Monikaan ei varmaan enää muista ja aikaakin on kulunut niin paljon, että netistäkään ei paljoa enää siitä tietoa löydy, mutta Intelin Pentium 3 aikakausi loppui prosessoriin joka ei pystynyt kääntämään Linuxin kerneliä. Tuossa tapauksessa syy oli suorastaan nolo: jos prosessoria alikellotti hiukan, käännös onnistui eli Intel myi vakiona liikaa ylikellotettua prosessoria. Kyseinen malli vedettiin kaikessa hiljauudessa takaisin ja jäi viimeiseksi P3 prosessoriksi.

Spoileri: OT

Pentium III - Wikipedia

A 1.13 GHz version was released in mid-2000 but famously recalled after a collaboration between HardOCP and Tom's Hardware[3] discovered various instabilities with the operation of the new CPU speed grade. The Coppermine core was unable to reliably reach the 1.13 GHz speed without various tweaks to the processor's microcode, effective cooling, additional voltage (1.75 V vs. 1.65 V), and specifically validated platforms.[4] Intel only officially supported the processor on its own VC820 i820-based motherboard, but even this motherboard displayed instability in the independent tests of the hardware review sites. In benchmarks that were stable, performance was shown to be sub-par, with the 1.13 GHz CPU equalling a 1.0 GHz model. Tom's Hardware attributed this performance deficit to relaxed tuning of the CPU and motherboard to improve stability.[5] Intel needed at least six months to resolve the problems using a new cD0 stepping and re-released 1.1 GHz and 1.13 GHz versions in 2001.


Ja 0,13 µm Tualatinit vielä tämän jälkeen.

 

[Nerkoon]

Muistin näemmä väärin sitten sen, että P3 aika olisi loppunut tuohon prosessoriin.

 

[JiiPee]

Eihän saman kernelin toimiminen prosessorilla X tarkoita 100% toimivuutta prosessorilla Y. Ensin pitäisi oikeasti sulkea softabugi pois ja sen jälkeen voitaisiin todeta vian olevan raudassa. Joka tapauksessa toivottavasti ongelman saa ratkaistua softapohjaisesti.

Kyllä tuota nyt on tutkittu jo siitä lähtien kun rysen julkaistiin ja niitä seqfaulteja ei tule pelkästään kääntäessä vaan jotkin muutkin kuormat niitä saa aikaiseksi. Ryzen on x86/x64 prosessori, joten kyllä voidaan sanoa että jos Intelin prosessorit ja vanhemmat AMD:n prosessorin toimii 100% varmasti tismalleen samassa tilanteessa, niin kyllä se on rytsölässä hardware vika.

Kiinnostaisi tietää vähän tarkemmin mikä on tällainen "oikeasti raskas kuorma". Siinä ei ole myöskään mitään kovin ihmeellistä että sama ohjelma toimii tietyllä prosessorilla muttei toimi jollakin toisella.

Kääntäminen. Se on kuormaa joka rassaa prosessoria ja muistoja ihan eri tasolla kuin nämä yleisesti käytetyt ylikellotus testit tekee. joku prime esim. kyllä piiputtaa prosessoria kovin, mutta se on samaa kuormaa jatkuvasti. Käännössä se kuorma vaihtelee ihan älyttömästi.

Kaikesta huolimatta käyttöjärjestelmänkin saa kaatumaan ohjelmallisesti hyvin helposti, esimerkiksi noin #16801 (Running a Virtual Machine when Windows Hyper-V is enabled should NOT Crash Windows) – Oracle VM VirtualBox

Tuossakin voidaan kysyä onko vika raudassa, Virtuaboxissa, Windowsissa, BIOS:ssa tmv vai kaikissa edellisissä.

Varmaan aika harvinainen tilanne että joku välttämättä haluaa ajaa 2 tai useampaa hypervisoria samassa koneessa.
Ja sanoisin että tuo on virtualbox ongelma. Kyllä sen pitäisi tsekata että onko hyper-v ajossa kuten vmware tekee.
Running Hyper-V and VMware Workstation on Windows 8.x - IVOBEERENS.nl

 

[Taneli-]

Kyllä tuota nyt on tutkittu jo siitä lähtien kun rysen julkaistiin ja niitä seqfaulteja ei tule pelkästään kääntäessä vaan jotkin muutkin kuormat niitä saa aikaiseksi. Ryzen on x86/x64 prosessori, joten kyllä voidaan sanoa että jos Intelin prosessorit ja vanhemmat AMD:n prosessorin toimii 100% varmasti tismalleen samassa tilanteessa, niin kyllä se on rytsölässä hardware vika.

Toisaalta sama kääntäen. Jos tuota ongelmaa ei saada 100% Ryzen prosessoreita todennettua onko se ongelma todella juuri kyseisessä prosessorissa jos toisen, ns. täsmälleen samanlaisen prosessorin vaihtamalla sitä ongelmaa ei enää tule?

Eli voidaan kysyä suoraan: jos 100% muista AMD:n prosessoreista, 100% muista Intelin prosessoreista ja 1 ainoa testattu Ryzen prosessori aiheuttaa ongelmaa mikä on ongelma? Tai miten laaja se ongelma on jos sitä ei pystytä useammalla prosessorilla saamaan samoilla testeillä aikaan?

Olen myös lukenut netistä että joku on ostanut Intelin prosessorin mikä ei ole toiminut, en silti menisi ihan väittämään ettei yksikään Intelin prosessori toimi, tai että kaikki kyseisestä kauppaketjusta ostetut prosessorit ovat hajalla.

Tarvisi siis saada hieman enempi tietoa tästä.

 

[JiiPee]

Toisaalta sama kääntäen. Jos tuota ongelmaa ei saada 100% Ryzen prosessoreita todennettua onko se ongelma todella juuri kyseisessä prosessorissa jos toisen, ns. täsmälleen samanlaisen prosessorin vaihtamalla sitä ongelmaa ei enää tule?

Eli voidaan kysyä suoraan: jos 100% muista AMD:n prosessoreista, 100% muista Intelin prosessoreista ja 1 ainoa testattu Ryzen prosessori aiheuttaa ongelmaa mikä on ongelma? Tai miten laaja se ongelma on jos sitä ei pystytä useammalla prosessorilla saamaan samoilla testeillä aikaan?

Olen myös lukenut netistä että joku on ostanut Intelin prosessorin mikä ei ole toiminut, en silti menisi ihan väittämään ettei yksikään Intelin prosessori toimi, tai että kaikki kyseisestä kauppaketjusta ostetut prosessorit ovat hajalla.

Tarvisi siis saada hieman enempi tietoa tästä.

En ole missään vaiheessa väittänyt että yksikään ryzen ei toimisi. Osa toimii ja osa ei. Tuossa on vielä sellainen homma että HT:n kun laittaa pois päältä niin ne joilla ongelmia on, niin ongelmat katoaa kokonaan tai lähes kokonaan. Ja toinen joka on tuota ongelmaa helpottanut on ollut toi opcachen disablointi.
Kyse nyt ei kuitenkaan ole ihan vain yhdestä rytsölästä joka piiputtaa ja eihän tuo nyt kovin hyvältä näytä kun EPYC piiputtaa kanssa. Lisäksi AMD:n hiljaiselo asian suhteen kyllä kielii siitä että ongelma on raudassa.

EDIT: gcc segmentation faults on Ryzen / Linux | Community

Seurasin tuota jonkuu viikon ja alun jälkeen AMD meni ihan mykäksi asian tiimoilta.

 

[Stephen Elop]

Phoronix testannut lisää 50+ Segmentation Faults Per Hour: Continuing To Stress Ryzen - Phoronix

Tapahtuu myös stock ryzen 7 1700 prossulla, joka taatusti ei ole liian kireälle kellotettu prossu, joten vikojen johtuminen huonosta prossuyksilöstä voidaan sulkea pois. Tietysti joku jolla Rytsölä on voisi testata tuota test_ryzen scriptiä ja kokeilla, josko kertoimen alentaminen esimerkiksi 20:een poistaa ongelman.

Lisäksi ongelma toistuu vain käännettäessä. Useampi enkoodaus, tieteellinen laskenta ja 3D mallinnus ei aiheuta ongelmaa. Tämän perusteella veikkailen jotain ongelmaa monen prosessin yhtäaikaisen levynkäytön kanssa, koska kääntäminen käyttää levyä suht tiuhaan mihinkään muuhun kuormaan verrattuna.

Toi yksi EPYC alusta jossa kanssa esiintyy ongelma voi johtua myös viallisista muisteista. Eli tarttis toteuttaa testi varmasti toimivilla muilla komponenteilla että jää vain prosessori mahdolliseksi ongelmaksi.

 

[JiiPee]

Lisäksi ongelma toistuu vain käännettäessä. Useampi enkoodaus, tieteellinen laskenta ja 3D mallinnus ei aiheuta ongelmaa. Tämän perusteella veikkailen jotain ongelmaa monen prosessin yhtäaikaisen levynkäytön kanssa, koska kääntäminen käyttää levyä suht tiuhaan mihinkään muuhun kuormaan verrattuna.

Jos kahlaisit läpi tuon AMD forumilla olevan jo 44 sivuisen ketjun, niin näkisit että seqfaulteja tulee myös muilla kuormilla. Kääntäessä se vain korostuu ja varsinkin tietyt käännöt on hyvin herkkiä aiheuttamaan tuota kuten MESA.

I'm one of the ones that reported that an RMA did not help. After running a number of tests with the 1st RMA'ed CPU, I've now gone through the RMA process again, where AMD offered to test the new CPU in a similar system to the one I have (Asrock x370 Taichi, 2x8GB G.Skill FlareX CL14 DDR4-3200) before shipping it to me. When they informed me it had passed all the tests and they were ready to ship it, I asked them for details of their testing and to confirm that it had been tested in Linux for compiling software. This is the response I received:

The test system is configured with Ubuntu 17.04 and Kernel 4.12. Using the same motherboard and RAM that is installed in your system, it ran our internal tests successfully.

As you have requested, I’ve ran the compile script that was shared on the forums using GCC version 7 for several hours and did not observe any issues.

I've now received the new CPU and installed it yesterday. With a fully cleared BIOS on default settings (Opcache enabled, SMT enabled, RAM at default 2400MHz) it ran overnight compiling gcc in a loop without error/segfault (14 hours, gcc 7.1 compiled 50 times in a row). I stopped the script and left the computer on and largely idle for the next 8 hours and did not observe any MCE, freezes or reboots. I will do some more extensive testing over the weekend and report back as to whether it appears that the CPU is stable, but certainly compared to both previous CPUs I had, this is much more promising. Neither of my previous CPUs could make it through more than a few hours of compiling gcc with make -j16 without throwing segfaults. Note, I am currently testing in Ubuntu 17.04 with kernel 4.10.0-30-generic #34-Ubuntu SMP.



N.B. Before you ask, I did try the kill_ryzen.sh script (with 16 threads) and it did not segfault but it did run out of memory eventually. As such, it's not a viable long-duration test for me due to the lack of sufficient RAM, but I am currently running two separate parallel compiles of gcc-7.1 in RAM with make -j9 each to stress the memory and CPU in a similar fashion to the kill_ryzen script.

Eli en oikeen ymmärrä että miten tämä voisi olla softavika kun RMA lotterystä saa takaisin viallisia ja toimivia prosessoreita?

 

[Stephen Elop]

Jos kahlaisit läpi tuon AMD forumilla olevan jo 44 sivuisen ketjun, niin näkisit että seqfaulteja tulee myös muilla kuormilla.

En oikein seuraa noita keskuteluita. Lähinnä Io-tech ja nyt hieman kommentteja tuolta phoronixilta. Foorumipostaukset on kuitenkin aina foorumipostauksia. Niistä ei oikeen aina tiedä postaako porukka huvikseen mitä sattuu ja joillakin muilla ongelma onkin jossakin muussa kohtaa järjestelmää.

Eli en oikeen ymmärrä että miten tämä voisi olla softavika kun RMA lotterystä saa takaisin viallisia ja toimivia prosessoreita?

Juu ei ole softavika. Se, että jos ihan oikeasti saa toimivan prosessorin takaisin poistaa suunnitteluvirheen, ellei uudessa prossussa ole eri stepping. En nyt kuitenkaan vielä luottaisi näihin foorumipostauksiin.

Edit: Pikku korjailua.

 

[Threadripper]

Kyllä tuota nyt on tutkittu jo siitä lähtien kun rysen julkaistiin ja niitä seqfaulteja ei tule pelkästään kääntäessä vaan jotkin muutkin kuormat niitä saa aikaiseksi. Ryzen on x86/x64 prosessori, joten kyllä voidaan sanoa että jos Intelin prosessorit ja vanhemmat AMD:n prosessorin toimii 100% varmasti tismalleen samassa tilanteessa, niin kyllä se on rytsölässä hardware vika.

En olisi siltikään niin varma. Kyllä softavialla saa hyvin helposti aikaan tilanteen jossa tietty prosessori toimii ja toinen ei.

Kääntäminen. Se on kuormaa joka rassaa prosessoria ja muistoja ihan eri tasolla kuin nämä yleisesti käytetyt ylikellotus testit tekee. joku prime esim. kyllä piiputtaa prosessoria kovin, mutta se on samaa kuormaa jatkuvasti. Käännössä se kuorma vaihtelee ihan älyttömästi.

Sitähän pitkään epäiltiin että tuo voisi johtua virransäästöistä. Nyt ei näytä siltäkään.

Varmaan aika harvinainen tilanne että joku välttämättä haluaa ajaa 2 tai useampaa hypervisoria samassa koneessa.
Ja sanoisin että tuo on virtualbox ongelma. Kyllä sen pitäisi tsekata että onko hyper-v ajossa kuten vmware tekee.
Running Hyper-V and VMware Workstation on Windows 8.x - IVOBEERENS.nl

Kaksi kakkostyypin hypervisoria menee hyvin samanaikaisesti, kuten VMWare ja Virtualbox. Hieman häiritsee ettei tyypin 1 hypervisorin kanssa toimi kakkostyypin hypervisor, muttei ratkaisevasti onneksi.

En ole missään vaiheessa väittänyt että yksikään ryzen ei toimisi. Osa toimii ja osa ei. Tuossa on vielä sellainen homma että HT:n kun laittaa pois päältä niin ne joilla ongelmia on, niin ongelmat katoaa kokonaan tai lähes kokonaan. Ja toinen joka on tuota ongelmaa helpottanut on ollut toi opcachen disablointi.
Kyse nyt ei kuitenkaan ole ihan vain yhdestä rytsölästä joka piiputtaa ja eihän tuo nyt kovin hyvältä näytä kun EPYC piiputtaa kanssa. Lisäksi AMD:n hiljaiselo asian suhteen kyllä kielii siitä että ongelma on raudassa.

EDIT: gcc segmentation faults on Ryzen / Linux | Community

Seurasin tuota jonkuu viikon ja alun jälkeen AMD meni ihan mykäksi asian tiimoilta.

Mahdollisesti AMD on hiljaa siksikin ettei ole saanut toistettua ongelmaa. Tuo prosessoriyksilöiden välinen ero tekee hommasta entistä kummallisempaa.

Lisäksi ongelma toistuu vain käännettäessä. Useampi enkoodaus, tieteellinen laskenta ja 3D mallinnus ei aiheuta ongelmaa. Tämän perusteella veikkailen jotain ongelmaa monen prosessin yhtäaikaisen levynkäytön kanssa, koska kääntäminen käyttää levyä suht tiuhaan mihinkään muuhun kuormaan verrattuna.

Toi yksi EPYC alusta jossa kanssa esiintyy ongelma voi johtua myös viallisista muisteista. Eli tarttis toteuttaa testi varmasti toimivilla muilla komponenteilla että jää vain prosessori mahdolliseksi ongelmaksi.

Levykäyttöongelma voisi viitata piirisarjaan, ellei käytössä ole prosessorin SATA liittimet.

Eli en oikeen ymmärrä että miten tämä voisi olla softavika kun RMA lotterystä saa takaisin viallisia ja toimivia prosessoreita?

Juuri sen takia viittaa softavikaan. Ei ihan heti tule mieleen tapauksia joissa saman mallin eri prosessoriyksilöt toimivat eri tavalla. Poikkeuksena valmiiksi tappiin kellotetut prosessorit joista ei nyt ole kyse.

 

[vmovapd]

Itsekin hankin Ryzenin (R7 1700) kesäkuun alussa vaikkei varsinaista tarvetta ollut. En ollut vielä kasannut uutta rautaa koteloon kun luin Phoronixista seuraavana päivänä noista segfaulteista Gentoolla, minun tuuria (käytän Gentoota).

Aluksi testasin vakautta kevyessä käytössä ja heti oli ongelmia. Kernelin versiot 4.11.[3-4] eli vain 1-3 päivää ennen reboottia tai jumia. Kokeilin sitten Fedora 25:lla (taisi olla kerneli 4.10.17-200) ja kone pysyi helposti pystyssä 7 päivää. Gentoossa sitten päivitin järjestelmän ja boottasin kerneliin 4.11.7 ja kahdesti kone saavutti 7 pv uptimen (Kernel.org:in changelogeissa ei Ryzen-fixejä). Kokeilin vielä uudelleen 4.11.4 ja odotetusti se reboottasi hieman yli 2 vuorokauden jälkeen. 4.11.12 vaikuttaa myös vakaalta, nyt 6 vuorokautta ylitetty. Vasta jälkikäteen hoksasin grepata logit mce-viestien varalta, löytyi 3 hardware error-tapausta kun kerneli luki ytimien mce-rekistereitä itsestään tapahtuneen rebootin jälkeen. En tiedä kuinka pysyviä nuo rekisterit ovat, ovatko pyyhkiytyneet jumi-tapauksissa joissa ei ole itsestään rebootannut. Pari kertaa jouduin katkaisemaan virrat virtalähteestä kun kone ei reagoinut resettiin tai power-nappiin.

Kun kone alkoi pysymään pystyssä, niin sitten segfaulttasi mesan kääntö päivityksen yhteydessä. 2-4 yritystä kymmenenestä kaatui. Disabloin ASLR:n ja segfaultit näytti katoavan. Pistin skriptin kääntämään Mesan 250 kertaa (kesti ~15 h) ja kaikki meni läpi, ainoastaan yksi kääntö oli kestänyt 5 kertaisen ajan muihin nähden, mutta emerge antoi sillekin koodia 0. Päivitin Biosin, ja ASLR päällä 10/30 feilasi. Ruuvasin 4c/4t Ivyn Ryzenin tilalle ja ASLR päällä sama käyttis ja edelleen -j16 ja tein 125 kääntöä (~12,5 h), kaikki onnistui.

 

[JiiPee]

Levykäyttöongelma voisi viitata piirisarjaan, ellei käytössä ole prosessorin SATA liittimet.

Ei ole levykäyttöön mitenkään kytköksissä. Kääntämisessä porukka tykkää käyttää nykyisin temppiä ramdiskissä varsinkin näin SSD aikana koska levytemppi on aika raakaa SSD:lle. Ja toi ramdiskin käyttö ilmeisesti on rysenille oikein paha noissa käännöissä. Käsittääkseni levytemppiä käyttäessä ei seqfaulttaa läheskään niin paljon. Eli kyllä ongelmat omasta mielestäni vaikuttavat ryzenin muistinhallinta ongelmilta.

Juuri sen takia viittaa softavikaan. Ei ihan heti tule mieleen tapauksia joissa saman mallin eri prosessoriyksilöt toimivat eri tavalla. Poikkeuksena valmiiksi tappiin kellotetut prosessorit joista ei nyt ole kyse.

Itse en kyllä pysty tätä näkemystä jakamaan. Jos ongelma olisi vain linuksilla, mutta ongelma on myös BSD:llä. Ja jos en ihan väärin muista niin joku oli windowsinkin saanut tilttailemaan käännöissä.

löytyi 3 hardware error-tapausta kun kerneli luki ytimien mce-rekistereitä itsestään tapahtuneen rebootin jälkeen.

Juu toi MCE homma on toinen josta ei ole varmuutta onko kytköksissä tuohon sqfaulttailuun. Toisilla tulee vain MCE erroria ja juuri noita jumeja/rebootteja idlenä. Toisilla taas esiintyy molempia.

Disabloin ASLR:n ja segfaultit näytti katoavan. Pistin skriptin kääntämään Mesan 250 kertaa (kesti ~15 h) ja kaikki meni läpi, ainoastaan yksi kääntö oli kestänyt 5 kertaisen ajan muihin nähden, mutta emerge antoi sillekin koodia 0.

Juu toi ASLR ja opcache disablointi on tuonut monille vakautta koneeseen. Toinen millä on saatu vakautta on SMT disablointi. SMT ja opcache on melemmat AMD:llä uusia ominaisuuksia. Ja ASLR on muistiin kytköksissä niin itse todellakin veikkaan että rytsölässä on muistinhallinnassa jotain häikkää.

 

[Threadripper]

Ei ole levykäyttöön mitenkään kytköksissä. Kääntämisessä porukka tykkää käyttää nykyisin temppiä ramdiskissä varsinkin näin SSD aikana koska levytemppi on aika raakaa SSD:lle. Ja toi ramdiskin käyttö ilmeisesti on rysenille oikein paha noissa käännöissä. Käsittääkseni levytemppiä käyttäessä ei seqfaulttaa läheskään niin paljon. Eli kyllä ongelmat omasta mielestäni vaikuttavat ryzenin muistinhallinta ongelmilta.

Voisin itsekin kokeilla RAMdiskiä ellei muisti olisi nini kallista. Muistiongelmat tulevat yleensä esiin myös testiohjelmilla.

Itse en kyllä pysty tätä näkemystä jakamaan. Jos ongelma olisi vain linuksilla, mutta ongelma on myös BSD:llä. Ja jos en ihan väärin muista niin joku oli windowsinkin saanut tilttailemaan käännöissä.

Mikäli Windowsissa tuota ongelmaa olisi, luulisi siitä olevan enemmän juttua julkisuudessa. Nyt ei ole käytännössä ollenkaan. Se on tässä suurin epäilyttävä seikka.

 

[Nerkoon]

Se EPYCin segfault (PHP / conftest) ei ilmeisesti ole sittenkään Ryzeniin liittyvä. Sen saa nähtävästi aikaan myös Intelin ja AMD muillakin malleilla eli lienee jonkinasteinen softavika.

Alkuperäisen EPYC segfault uutisen postaaja ei kuulema enää saa aikaan segfaulttia kun poisti tuon viallisen PHP / conftest softan testipaketistaan.

 

[vmovapd]

Se EPYCin segfault (PHP / conftest) ei ilmeisesti ole sittenkään Ryzeniin liittyvä. Sen saa nähtävästi aikaan myös Intelin ja AMD muillakin malleilla eli lienee jonkinasteinen softavika.

Alkuperäisen EPYC segfault uutisen postaaja ei kuulema enää saa aikaan segfaulttia kun poisti tuon viallisen PHP / conftest softan testipaketistaan.

Kuuluu näemmä conftestin normaaliin toimintaan testata tsydeemejä jotka johtavat segfaultiin. EPYC-tyyppi päivittikin ettei ole saanut muita segfaultteja vielä aikaiseksi. AMD näemmä tietää ongelman kun Brigdman kommentoi phoronixissa kuultuaan conftestin käyttäytymisestä, että hän ajattelikin jo, ettei jokin täsmää.

Ja tietenkin oma kone reboottasi itsensä vajaan 6,5 vuorokauden uptimen jälkeen 4.11.12-kernelillä. Näemmä 4.11.7 ja 4.11.12 teki koneen kippaamisesta vain epätodennäköisempää. Ei ole tullut uusia mce-viestejä kesäkuun puolivälin 3 erillisen virheen jälkeen.

 

[Stephen Elop]

Ja tietenkin oma kone reboottasi itsensä vajaan 6,5 vuorokauden uptimen jälkeen 4.11.12-kernelillä. Näemmä 4.11.7 ja 4.11.12 teki koneen kippaamisesta vain epätodennäköisempää. Ei ole tullut uusia mce-viestejä kesäkuun puolivälin 3 erillisen virheen jälkeen.

Tää tieto vain ei kerro muuta kuin että järjestelmä on tällä hetkellä epävakaa.

Täytyisi testata dual boottaavalla järjestelmällä. Toinen käyttis windows, jota testaa ja rääkkää oikein kunnolla, jotta siinä käyttiksessä on vakaa kone. Sitten bootataan samalla koneella Linuxiin ja katsotaan tuleeko ongelmia. Sitten jos ongelmia esiintyy koetetaan etsiä/haarukoida miten ongelman saisi helpoiten toistettua.

 

[JiiPee]

Tää tieto vain ei kerro muuta kuin että järjestelmä on tällä hetkellä epävakaa.

Niin ryzen on epävakaa. EPYC toi ei kerro vielä mitään. Se että php seqfaulttaa on tarkoituksellinen eli toimii niin kuin pitää ja muissa testeissä joissa ryzeneilla on ollut ongelmia, toi EPYC on selvinnyt niistä eli vaikuttaisi että EPYC ei riivaa tää ryzen ongelma.
Olisi ollut hiukan outoa jos out of the box EPYC olis ollu alttiita tälle koska noi ryzen ongelmat on ollu AMD:n tiedossa jo tuolta maaliskuulta.

 

[Stephen Elop]

Niin ryzen on epävakaa.

Eli jossakin on varmasti testattu muistit toimiviksi, emo toimivaksi, kiintolevyt ja SSD:t ja niihin vievät kaapelit ja niin edelleen? Myöskään se että käytetään AM4 kantaan sopivaa APU prosessoria ja sillä järjestelmä toimii, ei sulje pois ongelmaa muistiasetuksissa, koska Ryzen voi vaatia erilaiset muistiasetukset kuin APU prosessori. On turha huudella Ryzenia epävakaaksi, koska win 10 alustalla se tuntuisi olevan vakaa. Jos vakaa kone win 10 alustalla ei ole vakaa linux alustalla, niin sitten aletaan pääsemään asiaan.

Omasta kokemuksesta taisi aikoinaan omasta järjestelmästä lähteä Fedoralle vähän virheellisiä bugirapsoja x38 alustaa kohtaan. Oma dual boottaava kone sekoili Fedoralla. No Fedoraan bootattiin toisella kiintolevyllä ja lisäksi oli viallinen SATA kaapeli, joka aiheutti häiriötä silloin tällöin. Oli pikkasen V:mäinen ongelma, mutta nykyisin sama masiina toimii ihan OK Fedora 25:lla. Kaapelit on vaihdettu ja samoin kiintis. Tämä vain esimerkkinä, että se järjestelmän vakaus täytyy aluksi varmistaa.

 

[JiiPee]

Eli jossakin on varmasti testattu muistit toimiviksi, emo toimivaksi, kiintolevyt ja SSD:t ja niihin vievät kaapelit ja niin edelleen? Myöskään se että käytetään AM4 kantaan sopivaa APU prosessoria ja sillä järjestelmä toimii, ei sulje pois ongelmaa muistiasetuksissa, koska Ryzen voi vaatia erilaiset muistiasetukset kuin APU prosessori. On turha huudella Ryzenia epävakaaksi, koska win 10 alustalla se tuntuisi olevan vakaa. Jos vakaa kone win 10 alustalla ei ole vakaa linux alustalla, niin sitten aletaan pääsemään asiaan.

Omasta kokemuksesta taisi aikoinaan omasta järjestelmästä lähteä Fedoralle vähän virheellisiä bugirapsoja x38 alustaa kohtaan. Oma dual boottaava kone sekoili Fedoralla. No Fedoraan bootattiin toisella kiintolevyllä ja lisäksi oli viallinen SATA kaapeli, joka aiheutti häiriötä silloin tällöin. Oli pikkasen V:mäinen ongelma, mutta nykyisin sama masiina toimii ihan OK Fedora 25:lla. Kaapelit on vaihdettu ja samoin kiintis. Tämä vain esimerkkinä, että se järjestelmän vakaus täytyy aluksi varmistaa.

No se nyt on faktaa että ryzen on epävakaa OSALLA ei sitä voida enää kiistää mitenkään. On henkilöitä jotka on vaihtanu kaiken koneesta paitsi prosessorin ja seqfaultit senkuin jatkuu. Itse olen meinaan seurannut tuota AMD:n forumilla käytyä ketjua mielenkiinnosta ja lukenut läpi sen koko 45 sivuisen ketjun ja lisäksi lueskelin myös gentoo forumin ketjua jonkin aikaa + freebsd bugtracker ketjua, joten on melko kattava kuva ongelmasta kaiken lukemani jälkeen syntynyt.
Kyllä se on selvästi prosessori ongelma. Se että onko se design moka, niin en ole varma. Veikkaisin että tuotantoon eksynyt happamia komponentteja ja ainoastaan tiettynä aikana valmistetut prosessorit on viallisia.
Yks jamppa joka sai RMA:sta viikolla 16 valmistetun prosessorin seqfaulttas, sitten se sai viikolla 25 valmistetun ja seqfaultit loppui.

 

[Stephen Elop]

Se että onko se design moka, niin en ole varma. Veikkaisin että tuotantoon eksynyt happamia komponentteja ja ainoastaan tiettynä aikana valmistetut prosessorit on viallisia.
Yks jamppa joka sai RMA:sta viikolla 16 valmistetun prosessorin seqfaulttas, sitten se sai viikolla 25 valmistetun ja seqfaultit loppui.

Just tuon perusteella veikkaisin kyllä nyt jotain asetus ongelmaa BIOSista tai muuten jotain järjestelmän ongelmaa, joka korjaantunut prossua veihdettaessa (muistipalikka loksahtanut epähuomiossa kohdilleen tai jokin kaapeli lukittunut oikeaan asentoonsa). Se että ongelmaa on usealla henkilöllä kertoo vain että alusta on tällä hetkellä hieman ongelmallinen. Itse seuraillut noita IO-techin Ryzen keskusteluja, niin kyllä niissä porukalla on tuntunut vähän kestävän että saa edes Windowsissa toimivaksi. Lopulta ongelmat ovat ratkenneet.

Mutta jos löytyy yksi kone joka on testattu win alustalla vakaaksi ja linuxilla ei ole, niin sitten voisin minäkin pistää asioita Ryzenin viaksi vähän painokkaammin.

 

[JiiPee]

Mutta jos löytyy yksi kone joka on testattu win alustalla vakaaksi ja linuxilla ei ole, niin sitten voisin minäkin pistää asioita Ryzenin viaksi vähän painokkaammin.

Ei vaan silloin ongelma olisi linuksissa. Mutta nyt ongelmaa esiintyy niin linuksissa, freebsd:ssä ja joissain määrin myös windosissa.
Näillä samoilla henkilöillä kone toimii windowsissa ns. ongelmitta peruskäytössä, mutta ongelmat alkaa kun aletaan linuksissa antamaan prosessorille oikeasti raskasta kuormaa.
Kuten jo sanoin aikaisemmin, niin windowsilla kun ajellaan näitä synteettisiä rasitustestejä niin ne EI vastaa kuormaa joka saadaan tietyissä käännös tilanteissa. Linux puolella osa käännöistä toimii ihan hyvin ilman ongelmia, mutta sitten ongelmia alkaa esiintyä tiettyjen pakettien kääntämisessä, esim. MESA on yksi sellainen joka alkaa ryzenilla pukkaamaan seqfaultia helposti. Jotain toista pakettia saa kääntää vaikka maailman tappiin eikä se kaadu koskaan.
Siis kyllä nuo pojat on tuolla ehtiny tässä monen kuukauden aikana testaamaan jo paljon enemmän eri tilanteita kuin sinä ehdit miettiä tuota viestiä kirjoittaessasi.

 

[copter]

En lähde sen enempää sanomaan onko @JiiPee sanomisissa perää vaiko ei, mutta todettakoon että oma X370-PRO ja 1700X combo ei ainakaan kaatunut tai muuten toiminut epäloogisesti ajaessamo Linuxia siinä.

Windows puolella aikoinaan hain kellotukset kivelle ja muisteille enkä niihin ole nyt pitkään aikaan koskenut, näillä sitten olen Linuxia ajanut viimeiset pari kuukautta koneessa kehityskäytössä jne. Tosin ajan binääridistroa, eli paketteja ei pahemmin ole sillä tullut käännettyä C/C++ vaan enemmänkin sitten kompiloitua Javaa ja ajettua niihin liittyviä sovelluspalvelimia + tietokantaa sekä tietty muuta kehitysympäristöä.

 

[Griffin]

No se nyt on faktaa että ryzen on epävakaa OSALLA ei sitä voida enää kiistää mitenkään. On henkilöitä jotka on vaihtanu kaiken koneesta paitsi prosessorin ja seqfaultit senkuin jatkuu. Itse olen meinaan seurannut tuota AMD:n forumilla käytyä ketjua mielenkiinnosta ja lukenut läpi sen koko 45 sivuisen ketjun ja lisäksi lueskelin myös gentoo forumin ketjua jonkin aikaa + freebsd bugtracker ketjua, joten on melko kattava kuva ongelmasta kaiken lukemani jälkeen syntynyt.
Kyllä se on selvästi prosessori ongelma. Se että onko se design moka, niin en ole varma. Veikkaisin että tuotantoon eksynyt happamia komponentteja ja ainoastaan tiettynä aikana valmistetut prosessorit on viallisia.
Yks jamppa joka sai RMA:sta viikolla 16 valmistetun prosessorin seqfaulttas, sitten se sai viikolla 25 valmistetun ja seqfaultit loppui.

Tuo vikahan ei selkeästikään ole "väärä logiikan kytkentä" tyyppinen. Sensijaan tuo voi olla esim jonkinlainen prossun sisäiseen virranhallintaan tms liittyvä ongelma, jonka seurauksena jos rankaistaan kovasti ja jos tietyt ehdot täyttyvät (esim tietyt bittistringit tietyissä paikoissa jne ) ja sattuu sopiva prossuyksilö, niin homma voi ottaa ja kusahtaa.

 

[JiiPee]

En lähde sen enempää sanomaan onko @JiiPee sanomisissa perää vaiko ei, mutta todettakoon että oma X370-PRO ja 1700X combo ei ainakaan kaatunut tai muuten toiminut epäloogisesti ajaessamo Linuxia siinä.

Niin ei kaikilla niitä ongelmia ole ja ongelmaa ei välttämättä esiinny ellei sitä osaa hakemalla hakea. Todennäköisesti maailmassa on paljon ryzen käyttäjiä joilla on "viallinen" CPU mutta he eivät koskaan tule havaitsemaan ongelmia sen kanssa.
Minä myös yritin jossain vaiheessa kysellä täällä että onko kukaan testannut tuota seqfault ongelmaa mutta en saanut vastauksia eli täällä ei ilmeisesti ole juurikaan linuxin käyttäjiä paikalla.

 

[copter]

Voihan tuota jossain välissä kokeilla, mutta en ole nyt hetkeen kerennyt tätä keskustelua seuraamaan.

 

[Aaltoliike]

@copter Taas 503 :sta tuolla Ryzen Watchdog :is.

//OT

 

[PietroMennea]

Niin ei kaikilla niitä ongelmia ole ja ongelmaa ei välttämättä esiinny ellei sitä osaa hakemalla hakea. Todennäköisesti maailmassa on paljon ryzen käyttäjiä joilla on "viallinen" CPU mutta he eivät koskaan tule havaitsemaan ongelmia sen kanssa.
Minä myös yritin jossain vaiheessa kysellä täällä että onko kukaan testannut tuota seqfault ongelmaa mutta en saanut vastauksia eli täällä ei ilmeisesti ole juurikaan linuxin käyttäjiä paikalla.

Käännän säännöllisen epäsäännöllisesti GCC:llä softaa (makella optiona -j 16), enkä ole vielä törmännyt tuohon mahdolliseen bugiin.
Täytynee kokeilla tuota testiä ja raportoida miten kävi.

 

[Stephen Elop]

Mutta nyt ongelmaa esiintyy niin linuksissa, freebsd:ssä ja joissain määrin myös windosissa.
Näillä samoilla henkilöillä kone toimii windowsissa ns. ongelmitta peruskäytössä, mutta ongelmat alkaa kun aletaan linuksissa antamaan prosessorille oikeasti raskasta kuormaa.
Kuten jo sanoin aikaisemmin, niin windowsilla kun ajellaan näitä synteettisiä rasitustestejä niin ne EI vastaa kuormaa joka saadaan tietyissä käännös tilanteissa.

Niin onko noi henkilöt, joilla ongelmia Lnuxissa esiintyy testanneet konettaan myös Windowsissa ajaen Prime95 28.(mikä olikaan se paras versio). HCI memtestiä 500% ja muutenkiin testanneet rasitusta myös windowsissa. Se että windows tuntuisi toimivan ja nettiä voi selata ei merkitse vakaata järjestelmää.

Jos Windowsissa toimii hyvin kunnon rasituksessakin ja Linuxissa sitten kääntämisessä esiintyy ongelmia, jos kyse on rasituksen tuomasta epävakaudesta niin esimerkiksi väylän alentaminen 1-2 mhz ja muistien sekä prosessorin kertoimien lasku pitäisi auttaa. Jos kertoimien lasku ei auta, niin kyseessä on suunnitteluvirhe prossussa, jos sama kääntäminen onnistuu muilla prossuilla ongelmitta.

Jos kertoimien lasku auttaa, niin prossut on myyty liian korkeille kelloille kykenevinä. Ei tarvita mitään ERRATAa koska ongelmaa ei varsinaisesti ole, vaan prossu pitää vaihtaa RMA prosessilla. Tällöin jotkin Ryzenin ovat viallisia, mutta Ryzenissä ei ole vikaa.

Mitä keskustelua kattonut, niin se Ryzennewbie siellä nyt eniten itkee, ja musta näyttää ihan siltä että se on kasannut koneen ja vain ladannut BIOS default asetukset ja kaiken pitäisi sitten hänen mukaansa toimia. Voin kertoa että BIOS defaultteihin ei aina kannata luottaa.

Siis kyllä nuo pojat on tuolla ehtiny tässä monen kuukauden aikana testaamaan jo paljon enemmän eri tilanteita kuin sinä ehdit miettiä tuota viestiä kirjoittaessasi.

Tarvetta nostaa meikää jalustalle tai koittaa mennä henkilökohtaiseksi?

 

[PietroMennea]

Annoin ryzen-testin kill-ryzen.sh:n pyöriä tunnin ajan - ei segfaultia.

 

[Stephen Elop]

Annoin ryzen-testin kill-ryzen.sh:n pyöriä tunnin ajan - ei segfaultia.

Pitäisi testata vähintään 2 tuntia, mielellään 8. Sitten katsellaan logia. Nyt en valitettavasti heti löydä mihin tuo scripti tuon login sitten kirjoittaa.

Logista pitäisi kuitenkin näkyä jotain seuraavanlaista

grep -v OK log.txt | grep -v CPU
Segmentation fault (core dumped)
12226: sø. 06. aug. 01:07:16 +0200 2017: NG
Segmentation fault (core dumped)
...

Kuka alunperin ajoi tuota logia vastaavan testin, piti scriptiä käynnissä 26 tunnin ajan, näin foorumipostausten perusteella.

 

[Nerkoon]

Annoin ryzen-testin kill-ryzen.sh:n pyöriä tunnin ajan - ei segfaultia.

Kuulema se voi kaatua muistin puutteeseen. Sen perusteellä mitä siitä on kirjoitettu, se vaatii tajuttoman määrän muistia. Joku puhui 90 gigan piikeistä tavallisella R7 Ryzenillä.

 

[Stephen Elop]

Pistänpä linkin tuon testin Github projektiin. Siellähän lukee nuo logi paikatkin ja muistivaatimukset jne. GitHub - suaefar/ryzen-test: Tools to reproduce randomly crashing processes under load on AMD Ryzen processors on Linux

Muistia pitää olla yli 16Gb. Ei kyllä readme filussa määritellä tarkemmin. Kukaan tuskin testannut 18Gb:llä?

 

[PietroMennea]

Kuulema se voi kaatua muistin puutteeseen. Sen perusteellä mitä siitä on kirjoitettu, se vaatii tajuttoman määrän muistia. Joku puhui 90 gigan piikeistä tavallisella R7 Ryzenillä.

Tunnin ajon jälkeen minulla oli ramdiskin koko 27 Gt joten kyllähän se muistia näytti syövän. Tuohon skriptiin voi muuttaa

USE_RAMDISK=false

ja käyttää levyä, jolloin skriptin suoritus hidastuu mutta muistin loppuminen ei vie swapille tai aiheuta itsessään segfaultia jos swappikin loppuu.

En kyllä tämän testin perusteella olisi vielä väittämässä että segfaultin aiheuttava bugi on CPU:ssa. Varmasti tarvitaan enemmän testejä ja alustavertailua, jotta ongelman aiheuttaja selviää.

Oma kokoonpanoni jossa ongelmia ei esiinny on R7 1700X (vakio), 32 Gt RAM @2933, PRIME X370-PRO, Fedora 25 ja kernel 4.11.12.

 

[JiiPee]

Koittakaa ennemmin jotain MESA loop buildilla, tuo MESA kääntö on ollut kaikista ongelmallisin tapaus.

 

[hkultala]

Sellainen huomio, että segmentation fault ei mitenkään välttämättä tarkoita prosessorin bugia/epävakautta, vaan voi tulla myös bugista softassa, bugista käyttiksessä/ajureissa, tai vaan muistin lopumisesta kesken.

Joten "sain segmentation faultin" ei ole mikään peruste alkaa vaatimaan prossusta rahoja takaisin, ellei jotenkin pysty sulkemaan pois mutia syitä sille segfaultille.

Jos kyseessä on scripti joka käynnistää ziljoona yhtäaikaista käännöstä voi tuo muistin loppuminen kesken selittää osan kippauksista, jos käytössä ei ole tarpeeksi swappia.

 

[copter]

No eikö tuo skripti nyt ole tehty juuri sitä varten että sillä mahdollinen ongelma ilmenee jos sellainen on olemassa?

 

[hkultala]

No eikö tuo skripti nyt ole tehty juuri sitä varten että sillä mahdollinen ongelma ilmenee jos sellainen on olemassa?

Jos scripti aiheuttaa joillain bugittomallakin prossulla huomattavan määrän segfaultteja, niin miten erottaa bugaavan prossun bugittomasta?

 

[PietroMennea]

Koittakaa ennemmin jotain MESA loop buildilla, tuo MESA kääntö on ollut kaikista ongelmallisin tapaus.

Esiintyvätkö nuo Mesan kääntöongelmat pelkästään Gentoolla vai oliko ongelmia muillakin alustoilla? Laitoin looppina Mesan kääntymään, pyöriköön tovin ja katsellaan josko vikoja ilmenee.

EDIT:

Käänsin Mesaa loopissa 16-säikeellä reilun tunnin ajan, samalla kun käytin konetta kevyesti techbbs:n selailuun. Lukuunottamatta silloin tällöin esiintyneitä hetkellisiä 1-2s mittaisia jumahduksia, ei mitään ongelmia tai segfaulteja esiintynyt. Vesijäähdytetyn CPU:n lämmöt kävivät maksimissaan 73 C asteessa (todellisuudessa 53 C). Verrokkina sanottakoon että tuolla kill-ryzen.sh:lla lämmöt kävivät 79 C asteessa.

 

[Stephen Elop]

Lainausta Phoronixin forumilta. Bridgeman jampalla on vissiin jotain tekemistä AMD kanssa (tukihenkilö tai jotain). Tämä on Ryzennewbie:n (joka tehnyt bugi rapsan FreeBSD käyttiksen bugirapshoihin) kommentti

Originally posted by bridgman View Post
Are you talking about adding a guard page at the top of canonical userspace (the workaround Matt Dillon mentioned)?

Linux has had that for years, and I imagine Windows has as well:

http://elixir.free-electrons.com/lin...sm/processor.h

If BSD does not already have a guard page then I strongly recommend you add one because there are at least three older CPU families (two Intel and one AMD IIRC) which can exhibit unexpected behaviour when executing code in the top page of user space.

EDIT - looks like a guard page was just added to FreeBSD:

https://svnweb.freebsd.org/base?view...evision=321899

Just remembered that there was already a small (less than a page) guard region in BSDs but AFAIK other OSes went with a full page from the start.

Ja Ryzennewbien kommentti tossa alla.

I have no idea whether a guard page is already included or not - I'm currently trying to clarify that with the FreeBSD devs and in how far that could be relevant.

But my question still stands: why do I need that now and not with all the previous CPUs (including Phenom)?

Eli FreeBSD puolella tarvitaan ilmeisesti muistisivutukseen muutoksia. Onko Ryzen sitten spekseiltään sen verran erilainen Phenomiin nähden että muutoksia täytyy tehdä? Itsellä ei tietoa, eikä intoa ruveta lukemaan ja tulkitsemaan saatavilla olevia dokumenttejä.

Mutta Ryzennewbien pitäisi kyllä ymmärtää että käyttis voi vaatia muutoksia vaikka prossu tukisikin samaa käskykantaa kuin toinen prosessori.


EDIT.
AMD varmistanut että joillakin prossuilla on ongelmaa
AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR - Phoronix

Eli jotkin Ryzen yksilöt olisivat huonoja. Itse Ryzenissa ei olisi ongelmaa. Ne jotka kärsivät ongelmasta saavat uuden prossun RMA menetelyn kautta. Tuohon menettelyyn sitten kuuluu myös tiukka varmistus, että muistit, mobo poweri ja jäähdytys on varmasti kunnollinen joten aivan helposti ei uutta prossua käsiinsä saa.

 

[JiiPee]

Jos scripti aiheuttaa joillain bugittomallakin prossulla huomattavan määrän segfaultteja, niin miten erottaa bugaavan prossun bugittomasta?

Sinä varmaan sekoitat nyt phoronix test suiten ja muut testaukseen käytetyt scriptit. Toi phoronixin kikkare kääntää php:n jonka kuuluukin jossain käännön testissä segfaultata josta syystä se nyt vähän sotki koko asiaa, mutta toisaalta "Make some noise" ja nythän AMD on tosiaan myöntänyt että osassa Ryzen CPU:ta on ongelma.

 

[JiiPee]

Esiintyvätkö nuo Mesan kääntöongelmat pelkästään Gentoolla vai oliko ongelmia muillakin alustoilla? Laitoin looppina Mesan kääntymään, pyöriköön tovin ja katsellaan josko vikoja ilmenee.

Juu on muillakin MESA kipannut, ei siis pelkästään Gentoossa.

 

[Nerkoon]

AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR - Phoronix

AMD on kuulema saanut selville sen Linux segfaultin syyn. Ongelma ei koske Windowsia ollenkaan ja Linux / Unix puolellakin vain pientä osaa piireistä. Threadripper ja Epyc piirien ei AMD:n mukaan pitäisi segfaultata ja ongelma on vissiin ollut alkupään Ryzen piireissä.

 

[copter]

Eilen noita ketjuja tms lueskelin lävitse ja olihan se niiden perusteella aika selviö että joku ongelma on. Ilmeisesti RMA prosessin kautta sitten vaihtoa jos tuo ongelma esiintyy tms. Pitää varmaan oma siru jossain välissä testata vielä, kun on ihan ekasta erästä niin varmaan mahdollisuus on suurempi että tuo ongelma on.

 

[mRkukov]

EDIT.
AMD varmistanut että joillakin prossuilla on ongelmaa
AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR - Phoronix

Eli jotkin Ryzen yksilöt olisivat huonoja. Itse Ryzenissa ei olisi ongelmaa. Ne jotka kärsivät ongelmasta saavat uuden prossun RMA menetelyn kautta. Tuohon menettelyyn sitten kuuluu myös tiukka varmistus, että muistit, mobo poweri ja jäähdytys on varmasti kunnollinen joten aivan helposti ei uutta prossua käsiinsä saa.

AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR - Phoronix

AMD on kuulema saanut selville sen Linux segfaultin syyn. Ongelma ei koske Windowsia ollenkaan ja Linux / Unix puolellakin vain pientä osaa piireistä. Threadripper ja Epyc piirien ei AMD:n mukaan pitäisi segfaultata ja ongelma on vissiin ollut alkupään Ryzen piireissä.

Eilen noita ketjuja tms lueskelin lävitse ja olihan se niiden perusteella aika selviö että joku ongelma on. Ilmeisesti RMA prosessin kautta sitten vaihtoa jos tuo ongelma esiintyy tms. Pitää varmaan oma siru jossain välissä testata vielä, kun on ihan ekasta erästä niin varmaan mahdollisuus on suurempi että tuo ongelma on.

Sama juttu. Tilattu heti ekojen joukossa, eli pitänee testata jossain kohtaa.

Se vain mietittää että jos nyt laittaisi 3.925GHz kulkevan 1700 vaihtoon niin saako sieltä sitten 3.825GHz kulkevan tilalle. :/

 

[copter]

@mRkukov samaa itsekin mietin kun oma 1700X menee sen 4GHz, mutta enpä nyt ala asiaa miettimään ennen kuin olen testannut oman kiveni että onko edes koko ongelmaa. Toisaalta jos ei ole tähän mennessä mitään haitannut / esiintynyt, niin onko sitten tarvetta edes mitään tehdä.

 

[mRkukov]

@mRkukov samaa itsekin mietin kun oma 1700X menee sen 4GHz, mutta enpä nyt ala asiaa miettimään ennen kuin olen testannut oman kiveni että onko edes koko ongelmaa. Toisaalta jos ei ole tähän mennessä mitään haitannut / esiintynyt, niin onko sitten tarvetta edes mitään tehdä.

Totta totta. Täytyy kyllä itse jossain kohtaa testata. Sen verran tulee linuxeja ajeltua.

 

[Taneli-]

@mRkukov samaa itsekin mietin kun oma 1700X menee sen 4GHz, mutta enpä nyt ala asiaa miettimään ennen kuin olen testannut oman kiveni että onko edes koko ongelmaa. Toisaalta jos ei ole tähän mennessä mitään haitannut / esiintynyt, niin onko sitten tarvetta edes mitään tehdä.

Mietin tuota mutta kun ei ole tähän mennessä ollut mitään ongelmaa en taida viitsiä. Tosin keskimäärin 0% ajasta tulee linux/unix käyttistä käytettyä. Viimeksi taisin asennella modeemi/ISDN aikoina / ennen vuosituhannen vaihtumista omalle koneelleni. Silloin kiinnostus aika tehokkaasti kuoli kun nettiä ei saanut toimimaan millään joten sekin dual bootti sitten sai jäädä...

 

[mRkukov]

Spoileri: OT

Mietin tuota mutta kun ei ole tähän mennessä ollut mitään ongelmaa en taida viitsiä. Tosin keskimäärin 0% ajasta tulee linux/unix käyttistä käytettyä. Viimeksi taisin asennella modeemi/ISDN aikoina / ennen vuosituhannen vaihtumista omalle koneelleni. Silloin kiinnostus aika tehokkaasti kuoli kun nettiä ei saanut toimimaan millään joten sekin dual bootti sitten sai jäädä...

Joo ei tuo bugi taida montaakaan henkilöä juuri haitata. Lähinnä mietin että voiko tuo aiheuttaa winkkarissa ongelmia esim kerran 6kk aikana? Jos kerran Linuxilla esiintyy ja on ihan rautavika niin periaatteessa jossain tulevaisuuden casessa voisi mahdollisesti ilmetä.
Toki näyttää niin harvinaiselta tilanteelta, että siitä on turha jauhaa. AMD vaihtaa kiltisti prossun, jos juuri sinun yksilö on harvinaisuus jossa bugi ilmenee.

Olikos nyt niin että Epyc saa parhaat piirit, threadripper seuraavaksi ja sitten parhaat ryzenit ja viimeiseksi nämä 1700 "hinnat alkaen" mallit? Eli jos lähtisi vaihtamaan prossua niin mahdollisuus saada nykyistä huonompi olisi vain kasvanut?