AMD Zen
- Keskustelun aloittaja Hirvimies
- Aloitettu
Kippaa EPYC:llä.
- Liittynyt
- 18.10.2016
- Viestejä
- 5 894
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.
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.
Viimeksi muokattu:
- Liittynyt
- 16.10.2016
- Viestejä
- 359
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.
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.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 243
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.
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.
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-
☤ Virallinen ⚔ testaaja ☣
- Liittynyt
- 17.10.2016
- Viestejä
- 8 465
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ä.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 243
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.
- Liittynyt
- 07.03.2017
- Viestejä
- 1 950
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.
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.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 243
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.
Eli en oikeen ymmärrä että miten tämä voisi olla softavika kun RMA lotterystä saa takaisin viallisia ja toimivia prosessoreita?
- Liittynyt
- 07.03.2017
- Viestejä
- 1 950
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ää.
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.
- Liittynyt
- 12.12.2016
- Viestejä
- 3 930
En olisi siltikään niin varma. Kyllä softavialla saa hyvin helposti aikaan tilanteen jossa tietty prosessori toimii ja toinen ei.
Sitähän pitkään epäiltiin että tuo voisi johtua virransäästöistä. Nyt ei näytä siltäkään.
Kaksi kakkostyypin hypervisoria menee hyvin samanaikaisesti, kuten VMWare ja Virtualbox. Hieman häiritsee ettei tyypin 1 hypervisorin kanssa toimi kakkostyypin hypervisor, muttei ratkaisevasti onneksi.
Mahdollisesti AMD on hiljaa siksikin ettei ole saanut toistettua ongelmaa. Tuo prosessoriyksilöiden välinen ero tekee hommasta entistä kummallisempaa.
Levykäyttöongelma voisi viitata piirisarjaan, ellei käytössä ole prosessorin SATA liittimet.
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.
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.
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.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 243
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.
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ä.
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.
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ää.
- Liittynyt
- 12.12.2016
- Viestejä
- 3 930
Voisin itsekin kokeilla RAMdiskiä ellei muisti olisi nini kallista. Muistiongelmat tulevat yleensä esiin myös testiohjelmilla.
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.
- Liittynyt
- 18.10.2016
- Viestejä
- 5 894
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.
- Liittynyt
- 07.03.2017
- Viestejä
- 1 950
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.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 243
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.
- Liittynyt
- 07.03.2017
- Viestejä
- 1 950
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.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 243
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.
- Liittynyt
- 07.03.2017
- Viestejä
- 1 950
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.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 243
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
Last Man Standing
- Liittynyt
- 05.12.2016
- Viestejä
- 3 310
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öä.
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öä.
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.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 243
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.
Aaltoliike
Alkuperäinen jäsen
- Liittynyt
- 19.10.2016
- Viestejä
- 1 350
- Liittynyt
- 17.10.2016
- Viestejä
- 233
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.
- Liittynyt
- 07.03.2017
- Viestejä
- 1 950
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.
Tarvetta nostaa meikää jalustalle tai koittaa mennä henkilökohtaiseksi?
- Liittynyt
- 17.10.2016
- Viestejä
- 233
Annoin ryzen-testin kill-ryzen.sh:n pyöriä tunnin ajan - ei segfaultia.
- Liittynyt
- 07.03.2017
- Viestejä
- 1 950
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.
- Liittynyt
- 18.10.2016
- Viestejä
- 5 894
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ä.
- Liittynyt
- 07.03.2017
- Viestejä
- 1 950
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ä?
Muistia pitää olla yli 16Gb. Ei kyllä readme filussa määritellä tarkemmin. Kukaan tuskin testannut 18Gb:llä?
- Liittynyt
- 17.10.2016
- Viestejä
- 233
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
Koodi:
USE_RAMDISK=falseja 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.
- Liittynyt
- 22.10.2016
- Viestejä
- 11 771
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.
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.
- Liittynyt
- 22.10.2016
- Viestejä
- 11 771
Jos scripti aiheuttaa joillain bugittomallakin prossulla huomattavan määrän segfaultteja, niin miten erottaa bugaavan prossun bugittomasta?
Viimeksi muokattu:
- Liittynyt
- 17.10.2016
- Viestejä
- 233
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.
Viimeksi muokattu:
- Liittynyt
- 07.03.2017
- Viestejä
- 1 950
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.
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.
Viimeksi muokattu:
- Liittynyt
- 21.06.2017
- Viestejä
- 7 243
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.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 243
Juu on muillakin MESA kipannut, ei siis pelkästään Gentoossa.
- Liittynyt
- 18.10.2016
- Viestejä
- 5 894
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ä.
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
Last Man Standing
- Liittynyt
- 05.12.2016
- Viestejä
- 3 310
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
Hrrrr...
- Liittynyt
- 17.10.2016
- Viestejä
- 7 858
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
Last Man Standing
- Liittynyt
- 05.12.2016
- Viestejä
- 3 310
mRkukov
Hrrrr...
- Liittynyt
- 17.10.2016
- Viestejä
- 7 858
Totta totta. Täytyy kyllä itse jossain kohtaa testata. Sen verran tulee linuxeja ajeltua.
Taneli-
☤ Virallinen ⚔ testaaja ☣
- Liittynyt
- 17.10.2016
- Viestejä
- 8 465
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
Hrrrr...
- Liittynyt
- 17.10.2016
- Viestejä
- 7 858
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?
Uutiset
-
Uusi artikkeli: Testissä Samsung Galaxy S24 FE
22.11.2024 20:48
-
Live: io-techin Tekniikkapodcast (47/2024)
22.11.2024 13:35
-
DeepCool julkaisi uudet LP240- ja LP360-AIO-coolerit matriisinäytöllä
22.11.2024 02:58
-
Google julkaisi Android 16:n ensimmäisen kehittäjäversion
22.11.2024 02:39
-
NVIDIA saavutti päättyneellä neljänneksellään jälleen uuden ennätystuloksen
22.11.2024 02:17
Uutisia lyhyesti
-
Gigabyte julkaisi uudet 4K- ja 1440p-tarkkuuksien QD-OLED-näytöt- Kaotik
- Vastauksia: 0
-
Chiefteciltä kaksikammioinen Visio-kotelo kahtena eri versiona- Juha Kokkonen
- Vastauksia: 2
-
