Twoje PC  
Zarejestruj się na Twoje PC
TwojePC.pl | PC | Komputery, nowe technologie, recenzje, testy
M E N U
  0
 » Nowości
0
 » Archiwum
0
 » Recenzje / Testy
0
 » Board
0
 » Rejestracja
0
0
 
TwojePC @ News RSSKanał Youtube @ TwojePC.pl
Szukaj @ TwojePC
 

w Newsach i na Boardzie
 
0 Najczęściej czytane 0
 
 » 74614  | Smartfony i tablety
Amazon Kindle. Koniec papieru? Wyświetlacze e-ink
 » 70779  | Dźwięk
Meloman na wynos - test odtwarzacza FiiO X1
 » 67025  | Dźwięk
Wejście smoka - recenzja Xiaomi Piston 2 II
 » 63346  | Obudowy
Test obudowy HTPC SilverStone ML07 i napędu SOB02
 » 61449  | Chłodzenie
Test Cryorig C1 - chłodzenie niskoprofilowe Mini-ITX
 » 55284  | Dźwięk
Płaski obiekt pożądania? Test Edifier M3300SF - głośniki 2.1
 » 54460  | Twarde dyski
W miarę tanie magazynowanie - test Seagate Archive HDD 8TB
 » 54346  | MiniPC
Test mini-PC Beelink Pocket P1 z Windows 8.1 za 108USD
 » 53970  | Dźwięk
Muzykalny urwis - test FiiO E10K Olympus 2
 » 52938  | Monitory
Recenzja monitora AOC q2770Pqu, WQHD 2560x1440 w akcji
 » 49723  | Drukarki
Recenzja OKI C301dn - ledowy druk w kolorze za rozsądne pieniądze?
 » 48896  | Smartfony i tablety
Huawei Honor 7 - wersja 16GB - recenzja smartfona
 » 48162  | Oprogramowanie
Przegląd Windows 10 na podstawie konferencji Microsoftu
 » 47753  | Dźwięk
Test Edifier R2730DB - Stoi na stacji lokomotywa...
 » 46658  | Twarde dyski
Test Samsung SM951 (256GB) PCIe SSD z adaptorem Delock
 » 44904  | Inne urzadzenia
Test PocketBook Ultra - o jeden krok za daleko?
 » 43094  | Dźwięk
Test Edifier C3X - mocy przybywaj!
 » 41604  | Inne urzadzenia
Robot pod strzechą – Test iRobot Roomba 776p
 » 41498  | Myszki
Przyjaciele portfela - test Genius SlimStar 8000 oraz Energy Mouse
 » 41138  | Oprogramowanie
Syndrom Ostatniego Questa: recenzja Wasteland 2
 » 40756  | Dźwięk
Recenzja Bayan Audio soundbook X3 - przenośny dźwięk
 » 40360  | Oprogramowanie
Syndrom ostatniego questa: recenzja Divinity: Grzech Pierworodny
 » 39748  | Smartfony i tablety
Test czytnika PocketBook Aqua - ''Poczytaj mi wszędzie''
 » 39654  | Myszki
Test Logitech MX Master - biurowy arystokrata
 » 38718  | Dźwięk
Słuchawki dla kibica - Test Skullcandy Hesh 2
 » 38239  | Inne urzadzenia
Test Synology DiskStation DS415+ 4-zatokowy NAS z DSM 5.2
 » 37078  | Drukarki
Recenzja OKI MB471dnW - kopiuj, drukuj, skanuj, faksuj
 » 36149  | Oprogramowanie
Recenzja Dying Light - polski survival-horror
 » 35493  | Dźwięk
Recenzja EP-81M i HS-ANC41M, rzut uchem na słuchawki Snab Overtone
 » 34187  | Dźwięk
Recenzja Ozone Blast OceloteWorld 7.1 - słuchawki do grania
 » 33293  | MiniPC
Test Beelink M18, tani MiniPC Android 5.1 ze wsparciem UHD 60fps
 » 32447  | Dźwięk
Recenzja mini głośników Arctic S111-BT @ bardzo przenośne stereo
 » 31845  | Obudowy
Test obudowy Fractal Design Define Nano S - seria Define w pigułce
 » 31723  | Oprogramowanie
Pixel Heaven 2015 - trzecia edycja za nami!
 » 31387  | Dźwięk
Granie i gadanie - recenzja słuchawek Ozone ONDA-PRO
 
0 0 0


TwojePC.pl © 2001 - 2017
Środa 9 sierpnia 2017 
    

AMD potwierdza błędne działanie Ryzenów na niektórych PCtach z Linuksem


Autor: Wedelek | źródło: Phoronix | 06:44
(29)
Od kilku dni w sieci można przeczytać o problemach niektórych posiadaczy Ryzenów używających do pracy Linuxa. Niewielka grupa użytkowników donosi, że przy długotrwałym i intensywnym obciążeniu całego CPU sporadycznie występują tzw. problemy segmentacji. Istnienie takiego błędu potwierdziło samo AMD, które natychmiast po otrzymaniu pierwszych zgłoszeń zaczęło poszukiwania źródła problemu. Na razie jednak go nie odnaleziono, bo jak przyznaje sam producent cała sprawa jest dość skomplikowana. Wiadomo tylko, że błąd pojawia się u niewielkiej grupy użytkowników i dotyczy tylko pierwszych partii Ryzenów.

Threadrippery oraz Epyci mają go być całkowicie pozbawione. Co ciekawe bardzo trudno sprokurować sytuację, w której Ryzen zacząłby źle funkcjonować.

AMD poinformowało też zainteresowanych użytkowników, że problem dotyczy nie tylko samych Linuksów, ale i systemów z rodziny Unix. Jednocześnie producent zapowiedział szybkie wydanie stosownej poprawki i obiecał, że w przyszłości będzie więcej testów sprzętu pod Linuksem.



 
[ zgłoś błąd w treści newsa @ mail ]
  


    
K O M E N T A R Z E
    

  1. Poprzednio Intel, teraz AMD... (autor: Kenjiro | data: 9/08/17 | godz.: 08:06)
    Jeśli błąd występuje na FreeBSD i Linuksie, to tylko kwestią czasu jest wykrycie go na Windowsie. Z drugiej zaś strony dzisiejsze procesory są na tyle skomplikowane, że może to być problem np. nie do końca obsługiwanego procesora w kernelu, patrz np. poprawka dla FreeBSD sprzed tygodnia:
    https://svnweb.freebsd.org/...&revision=321899


  2. Skandal, kompletnie nie do pomyślenia , Intel takich błędów nie ma (autor: Sony Vaio Surprise | data: 9/08/17 | godz.: 09:01)
    Jak zwykle amd struga procesory z patyków, potem coś nie działa, a fanboje się cieszą i mówią ze to zaleta. Intel jak coś wypuszcza, to jest to sprawdzone i użytkownik ma stuprocentowa gwarancje sprawności.

  3. A ja się zastanawiam, (autor: muerte | data: 9/08/17 | godz.: 10:37)
    czy taki procesor wymieniają na gwarancji, jeśli jako powód podać błędne działanie np. Linuxa.

  4. Ten news brzmi jak efekt pracy sztabu PR AMD (autor: daver | data: 9/08/17 | godz.: 11:28)
    "od kilku dni", "natychmiast", "niewielka grupa użytkowników" https://forums.gentoo.org/...rder-asc-start-0.html
    http://www.phoronix.com/...x=Ryzen-Compiler-Issues
    https://community.amd.com/...?start=0&tstart=0

    "przy długotrwałym i intensywnym obciążeniu " 83 sekundy to długotrwałe obciążenie? http://phoronix.com/...mp;px=Ryzen-Test-Stress-Run



    @3 tak, https://community.amd.com/...mment-2816271#2816271 "Support suggested RMA and offered to test replacement chip with my MB+RAM configuration"


  5. nieeee mozeee byc...... (autor: g5mark | data: 9/08/17 | godz.: 11:46)
    AMD....uwielbieniec swoich fanbojow ????To jawna niesprawiedliwosc, co na to Sue ?

  6. niestety, (autor: angh | data: 9/08/17 | godz.: 13:47)
    widac pewne podobienstwa do Intela;)

  7. Rabneli Intelowi projekt (autor: Wyrzym | data: 9/08/17 | godz.: 15:39)
    to i te same bledy maja, a co ^^

  8. @1 nie zawsze to musi byc blad programowy... (autor: gantrithor | data: 9/08/17 | godz.: 16:21)
    ale tez specyficzne warunki dzialania samego procesora ,pamietacie moze pentium 4 northwood? okazal sie najlepszym procesorem z seri p4 i smialo konkurowal z athlonami , otoz posiadal on dosc specyficzny blad podczas podkrecania po przekroczeniu pewnej granicy napiecia procesor ten dawal ogromny skok w czestotliwosci taktowania ale bylo to okupione "syndromem naglej smierci nortwooda" prawdopodobnie po podniesieniu napiecia nastepowalo przebicie elektryczne gdzies w procesorze pozwalajac na wzrost taktowania ale to z kolei prowadzilo do degradacji ukladu.

  9. @8. (autor: pwil2 | data: 9/08/17 | godz.: 16:51)
    To samo można było zaobserwować na Pentiumie Dual Core E5200 2.5@4+GHz. Procesory się dobrze kręciły, ale powyżej pewnej granicy szybko się degradowały i @2.5GHz wymagały podniesionego napięcia...

  10. @1. (autor: pwil2 | data: 9/08/17 | godz.: 16:53)
    Były opisane sytuacje, gdzie pomagała zmiana - pamięci, zasilacza, płyty+AGESA, wyłączenie kilku optymalizacji. Pod Windowsem problem przy kompilacji nie występował, więc wnioski były, że to kwestia kernela.

  11. c.d. (autor: pwil2 | data: 9/08/17 | godz.: 16:56)
    Niektórym pomagało wyłączenie ASLR pod Linuksem.

  12. c.d. (autor: pwil2 | data: 9/08/17 | godz.: 17:00)
    Po aktualizacji BIOS/AGESA u niektórych domyśne napięcie SOC uległo obniżeniu, stąd może wynikać część problemów.

  13. c.d. (autor: pwil2 | data: 9/08/17 | godz.: 17:11)
    "A compile job forks a lot of processes each with their own layout. Try compiling without ASLR. "echo 0 > /proc/sys/kernel/randomize_va_space".
    ops... it seems to do the trick for me

    yesterday I left this machine compiling continuously gcc in a shell and mesa in another;

    with randomize_va_space set to 1 or 2, mesa compilation fails quite always with the usual segfault in bash or in libc; with randomize_va_space set to 0, during the test, gcc was compiled 8 times and mesa 78 times with no segfault or whatever."


  14. Tak, tak. Wina kernela, ASLR i Intela (autor: daver | data: 9/08/17 | godz.: 17:32)
    "I got the second RMA'd processor. As mcl00 already reported in #642, it has stepping 1 and UA 1725SUS printed on the processor while my original one has UA 1707PGT and the first RMA'd one has UA 1716PGT.
    I tested more than 13 hours last night with stock BIOS settings and no workarounds (it means SMT enabled, uOP cache enabled, ASLR enabled), and got no segfaults." https://community.amd.com/...mment-2816648#2816648

    Będą mieli problem, jeśli nie uda się workaround mikrokodem.


  15. c.d. (autor: pwil2 | data: 9/08/17 | godz.: 17:48)
    "If there is a hardware bug depending on specific address in user address space it would make sense that compile jobs triggers it. Linux use address space layout randomization to put memory segments on different addresses on each run. A compile job forks a lot of processes each with their own layout. Try compiling without ASLR. "echo 0 > /proc/sys/kernel/randomize_va_space".
    Thank you for the tip. ;-)
    Just tried and run fine now without segfault when I build my cross environment
    "make --jobs=16 MXE_TARGETS='x86_64-w64-mingw32.static i686-w64-mingw32.static' qt5" on my Debian Sid.
    Before I saw a lot of "segfault at 10 ip 0000000000000010 sp 00007ffcdbc8df58 error 14 in cc1plus""

    ***

    "Thank you very much. This workaround seemed to work for me. Before this setting, I could reproduce this problem at least once per ten kernel build by make -j16.
    But that build worked fine during 100 times after this setting."

    ***

    "Could you tell me why you think this problem is HT specific?

    If the problem which you pointed out is the same as mine, SEGV should disappear if I disable SMT. However, when I did so,
    SEGV still happened. On the other hand, when I disabled ASLR, which is expected to reduce the probability of the problem
    you mentioned, SEGV disappeared at all."

    ***

    "Mine freezes while doing practically nothing at all.
    Sounds like the issues I had with my 1700 with early BIOS versions. It would survive torture tests, but then would randomly freeze, often while doing nothing. Hours of gaming and no freeze, then freeze on the desktop a few minutes later. After re-installing ubuntu and updating to a 1.0.0.4a series BIOS it's been up for weeks without issue at 3.8GHz and thoroughly stress tested. My motherboard (ASRock AB350 K4) hasn't released a 1.0.0.6 BIOS yet. Hoping problems don't return for me when they do as I'd like to update in hopes of better RAM speed/timings."

    ***

    "I've managed to fix my freezes. Turns out it was CONFIG_RCU_NOCB_CPU and CONFIG_RCU_NOCB_CPU_ALL. These are enabled in Fedora. After enabling just these in my minimal config, there was no freeze. After disabling these in Fedora's config, I got a freeze. I don't know the reasoning but it seems quite conclusive. I don't yet know whether it's merely a workaround for some underlying issue or even whether it simply makes a freeze less likely. What's the best way to get this information across to AMD? @bridgman?

    Interestingly, CONFIG_RCU_NOCB_CPU is not enabled in Debian. We haven't seen swarms of Debian users reporting freezes with Ryzen so perhaps this issue is specific to the motherboard or some other factor. I did want to try a prebuilt Debian kernel but I was surprised that I couldn't find anything newer than 4.10, even among Ubuntu, Mint, and Sid.

    I previously said that I hadn't seen any segfaults. I did see some eventually but disabling ASLR fixed it. I am now booting with norandmaps to ensure that ASLR is disabled immediately on boot. Enabling CONFIG_COMPAT_BRK in the kernel doesn't actually disable ASLR entirely."

    ***

    PS. Tak czytając fora Linuksowe mam wrażenie, że o ile jest tam pewnie wielu świetnych programistów, to większość z nich zna się w stopniu przeciętnym na sprzęcie (w tym podkręcaniu, szukaniu przyczyn niestabilności). Prędzej przekompilują cały kod źródłowy z dysku na inną architekturę, niż spróbują podnieść któreś z napięć.

    Połowa przypadków problemów polega na tym, że gość idzie do sklepu, kupuje R7 1700 wraz z DDR4 3200 i zaczynają się problemy, których na jego poprzednim i5 SandyBridge nie było.

    Na Intelu obsadzenie wszystkich banków na P55 wymagało czasem 1.25V napięcia IMC. Na Ivy Bridge do uzyskania wyższych taktowań pamięci (DDR3 2133C11) też trzeba było ruszać napięcia, albo szukać selekta procesora - moje 3 sztuki i7QM nie dały rady, a niektórym na i7-3840QM chodziło).


  16. @14. (autor: pwil2 | data: 9/08/17 | godz.: 17:54)
    Inna sztuka procesora to inne domyślne napięcia. U mnie 3 sztuki i7 z pamięciami DDR3 2133C11 zachowywały się inaczej. Na jednym czarny ekran, na innym system startuje, ale zachowuje się "dziwnie", a kolejnym chodzi stabilnie do czasu maksymalnego obciążenia. Te same pamięci w parze z 1866C10 chodzą @1866C10 stabilnie z każdą sztuką.

  17. c.d. (autor: pwil2 | data: 9/08/17 | godz.: 17:59)
    "I figured I'd throw a comment in here as i've seen all these errors at one point or another.
    It seems that any memory speeds over 2666 require a vsoc voltage bump for me to get rid of errors ie: 1.225v currently
    Also today was the hottest day of the year and I started getting the uop cache parity errors during a firefox compile on settings that were otherwise stable for over a month.
    Heat could be a big factor for that. The ~1.4v turbo voltage is just intense.

    1800x
    gigabyte gaming K7
    64GB ecc mem overclocked at 2933 (no errors)"

    "I'd recommend that people who aren't overclocking, considering raising the vsoc a tad and see if it makes their issue go away.
    I'm running the llc settings at "regular" because the vrm's get hot."

    "Also worth noting the PWM fan control on my system is inverted.
    So 0 is max speed and 255 is slowest speed.
    I had to modify the fancontrol script to get this right and use a git version of the it87 module for the sensors output.
    This could be very dangerous for some people if they don't notice, as the fans will spin slower as the cpu gets hotter."


  18. angh dziwi Cię to? mnie wcale (autor: Sławekpl | data: 9/08/17 | godz.: 18:17)
    nie ma szans by tylko u jednego coś takiego się pojawiło skoro jedni od drugich zrzynają wszystko
    także to nie żaden błąd, to ficzer, a skoro tak ... ;)
    ... to celowa implementacja aby obronić kompa przed coraz większą liczbą wirusów i innych cholerstw na Linuxa, tylko to tajne przez poufne rozwiązanie, przynajmniej do niedawna takie było, niestety jakaś plotkarska pierdoła nie wytrzymała i się musiała pochwalić przed innymi :P


  19. @daver (autor: pwil2 | data: 9/08/17 | godz.: 18:20)
    "Some. A subset of users seems to benefit from upping the SoC voltage from ~.945 (auto) to 1.05-~1.1v. I'm fairly sure it's mostly an electrical issue, as exchanging processors doesn't seem to make any difference, but it's not yet led to AMD announcing any kind of fix."

    Nawet jeśli zmiana procesora pomaga, może oznaczać lepszą sztukę kontrolera i zbyt niskie domyślne napięcie w UEFI/AGESA. Skoro część kompów z Ryzenami przechodzi testy, które wysypują się u innych zawsze, to sugeruje, że nie jest to bug w architekturze procesora.


  20. @16 (autor: daver | data: 9/08/17 | godz.: 18:27)
    LOL, 3 procesory zachowywały się inaczej na, jak mniemam, wspieranych pamięciach? Pełna profeska, nie ma co. Proszę, nie wklejaj więcej internetów, bo zaczynam wątpić, czy ta platforma to zabawka na komunię dla małego majsterkowicza, czy stabilna platforma do pracy.

    BTW. DDR4-3200 są na liście wspieranych pamięci https://www.amd.com/...emory-support-list-en_0.pdf


  21. @slawekPL (autor: angh | data: 9/08/17 | godz.: 21:01)
    Musze zaczac dawac /s na koncu niektorych postow... ;)
    Poziom skomplikowania hardware obecnie jest tak duzy, ze bledy sa nie do uniknienia. Kazda generacja Intela ma bledy, AMD zreszta rowniez mialo, wiec nie jest to nic zaskakujacego. Na szczescie zwykle pomaga upgrade Bios, a poza tym, to jest wlasnie powod dla ktorego nie kupuje sie pierwszej fali sprzetu;)
    Nie zmienia to faktu, ze jest to swietny procesor i gdybym mial zmieniac to wybor bylby prosty.
    Mam jedynie nadzieje, ze Vega nie zostanie przechwycona przez gornikow, bo akurat gpu chce zmienic i najchetniej na Vege wlasnie.


  22. angh proszę wyjaśnij co ma dać "/s" (autor: Sławekpl | data: 10/08/17 | godz.: 00:58)
    na końcu postu bo nie łapie, pewnie przez późną porę ;)
    też to przy premierze Zen pisałem, kupię kolejny ich procek gdy znajdą oraz uporają się z większością błędów
    co do grafy / Vegi, ja nadal czekam na grafę od AMD zajmującą jeden slot i nisko profilową do HTPC, kupno wersji Pro za 1400 zł średnio mnie się uśmiecha
    może się kiedyś doczekam, pewnie dopiero jak wyjdzie Navi w 7 nm :P


  23. @20. (autor: pwil2 | data: 10/08/17 | godz.: 07:43)
    Dla Ryzena 1700:
    "Memory Max Memory Speed
    2667MHz"

    Dla i7-7700K:
    "Memory Types
    DDR4-2133/2400, DDR3L-1333/1600 @ 1.35V"

    Dla i7-6700K:
    "Memory Types
    DDR4-1866/2133, DDR3L-1333/1600 @ 1.35V"


  24. pwil2 to oficjalne dane producentów (autor: Sławekpl | data: 10/08/17 | godz.: 08:48)
    jednak u jednych i drugich można użyć szybszych kości po OC, da to wymierne korzyści w praktycznie wszystkich zastosowaniach
    warto dołożyć, czasem tylko kilka złotych do lepszych pamiątek ;)


  25. @24. (autor: pwil2 | data: 10/08/17 | godz.: 14:32)
    OC = nie nie jest gwarantowane, a wsparcie polega na trzymaniu kciuków ;-)

    PS Mam (z pamięci licząc) 32GB DDR4 3000, 48GB DDR4 2666, 32GB 2400, 64GB DDR4 2133 i garść wolniejszych/mniejszych pojemności, więc wiem coś o dokładaniu ;-)


  26. edit (autor: pwil2 | data: 10/08/17 | godz.: 14:33)
    Jedno "nie" za dużo

  27. pwil2 przy topowych pamięciach, zgadza się (autor: Sławekpl | data: 11/08/17 | godz.: 21:24)
    wręcz trzeba dać na mszę w tej intencji :E
    ale jak kupisz o dwie, trzy podziałki szybsze to musisz mieć pecha by nie ruszyły, zwłaszcza markowe ;)


  28. @27. (autor: pwil2 | data: 16/08/17 | godz.: 16:40)
    Miałem kości pamięci A-Daty 1333 zupełnie seryjne, 2 komplety i na Intelach trzeba się było nagimnastykować, by działały. Niby MemTest przechodził, ale nie do końca stabilnie na co dzień. Na niektórych płytach/procesorach zupełnie ok.

  29. c.d. (autor: pwil2 | data: 16/08/17 | godz.: 16:43)
    W 2 laptopach sprawdzałem 3 sztuki i7QM i w różnym stopniu nie działały mi HyperX DDR3 2133C11, a podobno szczęściarzom z selektami i7-3840QM ruszały. Za to Cruciale 2133C11 chodziły z różnymi sztukami (szkoda mi było już kolejnej kasy wykładać na zamiany)

    
D O D A J   K O M E N T A R Z
    

Aby dodawać komentarze, należy się wpierw zarejestrować, ewentualnie jeśli posiadasz już swoje konto, należy się zalogować.

    
0 Ostatnie recenzje / testy 0
 
Recenzja TP-Link NC450 - kamera IP z nocnym trybem 
Recenzja TP-Link NC450 - kamera IP z nocnym trybem

odsłon 3555 komentarzy 9
Test Wilkinson Hydro Connect 5 - ku uciesze obojga 
Test Wilkinson Hydro Connect 5 - ku uciesze obojga

odsłon 5202 komentarzy 27
Test SteelSeries Arctis 5 - cienka muzyczna linia 
Test SteelSeries Arctis 5 - cienka muzyczna linia

odsłon 2413 komentarzy 10
Test Supermyszy - SteelSeries Rival 310 oraz Sensei 310 
Test Supermyszy - SteelSeries Rival 310 oraz Sensei 310

odsłon 4080 komentarzy 2
Test Razer Hammerhead BT - mobilne słuchawki nie tylko dla gracza? 
Test Razer Hammerhead BT - mobilne słuchawki nie tylko dla gracza?

odsłon 4599 komentarzy 5
Muzyka wpadająca w ucho - recenzja słuchawek RHA S500 i MA600 
Muzyka wpadająca w ucho - recenzja słuchawek RHA S500 i MA600

odsłon 6204 komentarzy 5
Test klawiatury Xtrfy K2-RGB – profesjonalny ''mechanik'' 
Test klawiatury Xtrfy K2-RGB – profesjonalny ''mechanik''

odsłon 6763 komentarzy 10
Gimby nie znajo. Audiomagic Player - recenzja przenośnego odtwarzacza MP3 
Gimby nie znajo. Audiomagic Player - recenzja przenośnego odtwarzacza MP3

odsłon 9515 komentarzy 9
Felieton: Xbox One X i pojękiwania klientów 
Felieton: Xbox One X i pojękiwania klientów

odsłon 6847 komentarzy 18
Test myszki Gigabyte XM300 - czyżby świetna mysz za 120 zł? 
Test myszki Gigabyte XM300 - czyżby świetna mysz za 120 zł?

odsłon 9888 komentarzy 5
Pixel Heaven 2017 - raport z retroimprezy 
Pixel Heaven 2017 - raport z retroimprezy

odsłon 9123 komentarzy 7
Recenzja chłodzenia cieczą Fractal Design Celsius S24 
Recenzja chłodzenia cieczą Fractal Design Celsius S24

odsłon 10410 komentarzy 4
Test Snab Overtone HS-42M - słuchawki do tańca i do różańca 
Test Snab Overtone HS-42M - słuchawki do tańca i do różańca

odsłon 9680 komentarzy 10
Test Creative Aurvana ANC - cisza, cisza wszędzie? 
Test Creative Aurvana ANC - cisza, cisza wszędzie?

odsłon 12319 komentarzy 2
Recenzja klawiatur mechanicznych MasterKeys Pro L oraz Genesis RX75 
Recenzja klawiatur mechanicznych MasterKeys Pro L oraz Genesis RX75

odsłon 12245 komentarzy 12
Test TP-LINK Neffos C5 Max - tani dualsim z dużym ekranem 
Test TP-LINK Neffos C5 Max - tani dualsim z dużym ekranem

odsłon 13872 komentarzy 9
Test obudowy NZXT S340 Elite - hartowane szkło, VR i minimalizm 
Test obudowy NZXT S340 Elite - hartowane szkło, VR i minimalizm

odsłon 17210 komentarzy 5
Akustyczna ambrozja - test słuchawek RHA MA750 i T20 
Akustyczna ambrozja - test słuchawek RHA MA750 i T20

odsłon 13518 komentarzy 4
Felieton: SLI - mity i fakty 
Felieton: SLI - mity i fakty

odsłon 10330 komentarzy 4
Recenzja obudowy SilverStone Kublai KL07 
Recenzja obudowy SilverStone Kublai KL07

odsłon 14451 komentarzy 7
Recenzja Somic V2 - słuchawki z dalekiego wschodu 
Recenzja Somic V2 - słuchawki z dalekiego wschodu

odsłon 17763 komentarzy 7
W otoczeniu dźwięku - recenzja Ozone Rage Z90 
W otoczeniu dźwięku - recenzja Ozone Rage Z90

odsłon 16712 komentarzy 3
 
0 0 0