AMD rozwiązało problemy z działaniem Linuxa na Ryzenach

1. Noo i to się nazywa (autor: kombajn4 | data: 1/09/17 | godz.: 08:54)
   właściwe podejście do klienta przyznać że istnieje problem, wprowadzić poprawkę i zaoferować wymianę procesora na nowy. AMD może zrobić akcje serwisową, koncerny samochodowe mogą robić akcje serwisowe.. a Intel? A Intel np nie tak dawno napisał żeby nie podkręcać procesora (który kosztuje więcej bo jest sprzedawany jako przeznaczony do podkręcania) to się nie będzie przegrzewał.
   
   
2. U Intela takie podejście do klienta to "standard" (autor: zartie | data: 1/09/17 | godz.: 10:11)
   Parę lat temu wypuścili badziewne SSD, na których dane użytkownika trafiał szlag. Na gwarancji wymieniali je na ... tak samo badziewne dyski tej samej serii, z tą samą usterką. Aż się klientowi znudziło zawracać im dupę.
   
   
3. coś tu nie pasuje i cuchnie z daleka oślizgłą ściemą (autor: Sławekpl | data: 1/09/17 | godz.: 10:20)
   Epyc i Threadripper jak samo AMD przyznało to selekty, 5% z normalnych Ryzenów więc jak niby wprowadzili tą zmianę w warstwie krzemu w selektach z początku produkcji?
   wycinają laserem jakiś blok lub inaczej je programują, tylko to tłumaczy poprawę działania,
   Epyc i Threadripper na pewno są inaczej oprogramowane niż zwykłe Ryzeny, zapewne w nich nie zrobili błędu dlatego wszystkie działają poprawnie
   
   
   Zbyszek to bodaj jedyny "nowy" news dziś na TPC, nie przeglądałem od kilku dni innych stron ale resztę dzisiejszych Twoich newsów czytałem dobre kilkanaście dni temu na polskich stronach
   
   z jakich stron korzystasz wyszukując ciekawostki?
   może podesłać Tobie jakieś adresy? również komentujący na TPC na pewno podzielą się swoimi ulubionymi stronami ;)
   
   
4. błyskawiczną reakcją na błąd jest łątka w krzemie... (autor: Qjanusz | data: 1/09/17 | godz.: 10:45)
   od AMD
   epicka postawa granicząca wręcz z niemożliwością.
   
   lubimy w tym temacie pojechać po liderze, więc ja przypominam to:
   http://www.computerworld.pl/...m-C2000,407335.html
   
   
5. Ile to trwa? (autor: @GUTEK@ | data: 1/09/17 | godz.: 15:33)
   Ktoś wie ile trwa odpowiedź AMD na zgłoszenie? Dzisiaj będzie 3 dzień jak napisałem do ich supportu, wysłałem logi z kill-ryzen.sh i cisza. Jedynie mi przyszło potwierdzenie zgłoszenia.
   
   
6. News wyssany z translatora, że aż boli. (autor: daver | data: 1/09/17 | godz.: 15:40)
   Przede wszystkim, AMD nikogo o niczym nie poinformowało i prawdopodobnie nic nie naprawiało, a już na pewno nie po oficjalnym zgłoszeniu błędu.
   
   Segmentation fault, czyli naruszenie ochrony pamięci ("błąd segmentacji" poleciał prosto z translatora?), nie jest niewielkim problemem - jest błędem krytycznym.
   
   Ludziska wydedukowały, że wadliwe są Ryzeny wyprodukowane przed 25 tygodniem, czyli ~2 miesiące zanim AMD oficjalnie przyznało się do błędu i zaczęło nad nim pracować. Stepping się nie zmienił, co sugeruje brak zmian w architekturze.
   
   http://www.phoronix.com/...w-ryzen-fixed&num=1
   
   
7. A co z właścicielami starej partii procesorów (autor: rarek | data: 1/09/17 | godz.: 19:44)
   czy AMD ma dla nich jakieś pocieszające wieści?
   
   
8. @rarek (autor: daver | data: 1/09/17 | godz.: 21:39)
   RMA, wymieniają procki. http://support.amd.com/en-us/contact/email-form
   
   
9. @ daver (autor: Zbyszek.J | data: 2/09/17 | godz.: 00:12)
   Od lipca (od 25 tygodnia) po prostu wpuścili do produkcji nową maskę litograficzną z drobnymi poprawkami. Wystarczyło aby załatać błąd z Linuxa i poprawić taktowania o ~ 100 MHz. Już z tej nowszej wersji robią te selekty 5% rdzeni do Threadripperów, które podkręcają się właśnie o ~ 100 MHz lepiej niż najlepsze partie Ryzenów sprzed 25 tygodnia. Lub inaczej 4 GHz na wszystkich rdzeniach te procesory po 25 tygodniu robią przy 1,325V, zamiast 1,4V ja wcześniej. Z tego względu XFR w Threadripperach to 4,2 Ghz a nie 4,1 GHz.
   
   
10. @ Slawekpl (autor: Zbyszek.J | data: 2/09/17 | godz.: 00:14)
    Możesz podać stronki. Ja ogólnie jeśli chodzi o newsy to jestem tutaj weteran, poprzeglądaj archiwa od połowy 2007 do 2012 roku.
    
    
11. @9, Zbyszek (autor: daver | data: 2/09/17 | godz.: 00:52)
    25 tydzień to ~połowa czerwca. Wtedy (oficjalnie) nawet nie wiedzieli o "błędzie z Linuxa". W sierpniu nie mieli pojęcia co jest przyczyną ww. Cofnęli się w czasie i naprawili? Poza tym, erraty wprowadza się z nowym steppingiem. Jedno jest, właściwie już było, pewne. Problem leżał w procesie produkcji.
    
    Skąd jednak masz pozostałe informacje, które przekazałeś w newsie? Na pewno nie z Phoroniksa. Możesz rzucić sznurkiem do tej oficjalnej informacji AMD?
    
    
12. faktycznie (autor: Zbyszek.J | data: 2/09/17 | godz.: 22:41)
    nie ma info od AMD, jest potwierdzenie społeczności Phoronix.
    
    Problem leżał w produkcji i nowa maska go rozwiązała. Zakładam że wiesz, co to znaczy maska w litografii.
    
    
13. No i po co cwaniakujesz? (autor: daver | data: 3/09/17 | godz.: 01:58)
    To, że nowsze Ryzeny były wolne od wady było wiadomo ~miesiąc temu, gdy ludzie testowali procki po RMA. https://community.amd.com/...mment-2816648#2816648
    https://twojepc.pl/...orych-PCtach-z-Linuksem.html
    
    
14. Wstępne wnioski userów prawdopodobnie były zbyt optymistyczne (autor: daver | data: 3/09/17 | godz.: 19:36)
    "[...] the new one is 17 week 30 and still faulty! I have dissapearing files and segfaults during compile!"
    https://community.amd.com/...mment-2820575#2820575