Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
"2× 10Gb" - to vypadá jako chyba. Nevidím proč do takového lower-endu a na rychlý pohled u Rtl8111g vidím jen 1Gb. (Tlačítko na nahlášení chyby mi nereaguje.)
2x 10Gb je priamo z procesora
Neni to low-end, ale SOC pro prumyslove pouziti. Navic na 10Gbit jiz davno neni vyrobne nic zvlastniho, premrstena cena 10Gbit prvku je jen marketingove rozhodnuti.
To "lower-end" jsem myslel tak, že v rámci (Ry)Zen CPU jsou tyhle výkonově dost nízko, takže kombinace s higher-end sítí by byla na relativně dost specifické využití. Ani ta cílová použití v článku nevypadají že by to potřebovala. NAS apod. bych si představit uměl, ale to by tam muselo být místo na nějaké disky :-)
Jde o oficiální specifikaci čipu:
https://diit.cz/sites/default/files/ryzen_r1000_dual_10gbit_ethernet_01.jpg
https://diit.cz/sites/default/files/ryzen_r1000_dual_10gbit_ethernet_02.jpg
To není chyba, jak píší ostatní, přímo ten SOC má v sobě dva 10GbE porty, nicméně ASRock je ven nevyvedl a použil dva externí 1GbE porty od Realteku.
pekne.
Zaujimava vecicka na par veci. Osobne by som si to doma vedel predstavit.
hlavne tie 2 10Gbps porty, takto som musel kupovat pci 1Gbps kartu aby som mal 2 porty
Jsou tam dva 1GbE porty, ASRock ty dva 10GbE porty co jsou přímo v SOC ven nevyvedl.
Marketingove kouzlo - pridanim dvou cipu navic se zvysi vyrobni cena, ale umozni to drzet nadsazenou cenu za 10GbE.
Nechápu co tím chcete říct - v čipu je jenom digitální část pro 2x10Gb LAN, výrobce by na motherboard stejně musel osadit 2x10Gb PHY (a myslím, že celá 1Gb síťovka je levnější než 10Gb PHY)
"... ale čekal bych, že rozumně nový Linux pojede bez problémů." <= Nevím zda mi něco uniklo, ale dosud pod Linuxem fungují AMD Ryzen APU velmi problematicky. Mám Ryzen 2200G a je běžné, že mi náhodně a celkem často mrzne. Tento problém není ojedinělý a údajně souvisí s (nedodělanými) ovladači pro iGPU Vega, potažmo poslední AMD APU platformu.
Už máme rok od vydání a není mi známo, že by naprosto běžně běhal stabilně Linux na AMD Ryzen APU.
Já nový Linux s AMD APU používám a na žádný problém jsem zatím nenarazil - a to ta APU dost trápím, abych je otestoval. Četl jsem však, že vadné jsou například některé starší verze AMD mikrokodu. Z těchto důvodů například zatím nedošlo k zapnutí úsporného režimu "GFXOFF" v amdgpu.
Přidávám se s hlášením k ap, od října, kdy jsem koupil R3 2200GE, nepozoruji žádný problém. Jediné, co není dotažené do konce je podpora pro encoding se staršími kodeky, jako DivX apod. (chyba není ve VAAPI). Implementace x264, x265 a snad i VP9 je už celkem v pořádku. Celá léta se říká, že se podpora GPU od AMD v Linuxu zlepšuje, což byla spíš mizérie rychlostí opilého šneka. Kritizoval jsem AMD za toto celkem pravidelně i zde v diskuzích. Ale vzali za to, s APU není problém. Samozřejmě záleží na tom, jestli nemáš nějakou "stabilní distribuci" se starým kernelem, mesou atd.
Můžete kdyžtak prosím uvést jména a verze otestovaných distribucí? Koketuju s myšlenkou pořízení pasivně chlazeného APU do htpc místo (relativně stabilní) ARM krabičky.
Můžu, měl jsem čas na blbnutí (testy, provozní vlastnosti...). Pravidlo číslo jedna - rolling update distro, minimálně do doby, než se do stabilních vydání dostane kernel 4.19 a tomu odpovídající MESA a X a dále doporučuji ohlídat, aby verze VAAPI byla 2.3 nebo novější (aktuální je 2.4). V lubuntu verze 2.1 (tuším, že 2.1) celkem fungovala, ale rozdíl mezi 2.1 a 2.3, potažmo 2.4 je značný. Poslední testy v dále jmenovaných distrech jsem provedl naposledy v lednu, některé ještě o něco dřív. U rolling update dister nemusím uvádět verze :).
Kolega ap provozuje Arch Linux, já zase openSUSE Tumbleweed. V rámci blbnutí jsem absolvoval distribuční kolečko, povětšinou mainstreamových dister - Fedora 29, Debian testing, Mageia 7 alpha, PCLinuxOS, lubuntu 18.10, Manjaro, Mint 18 a pro ověření absence supportu Vegy v nižších verzích jádra ještě openSUSE Leap 15. Mint nenajel vůbec, lubuntu ano, leč provozní vlastnosti byly katastrofa a Leapem jsem si to potvrdil (kernel 4.14). Z ostatních byl problém v Debianu testing (stabilita X) a Fedora padala na úrovni DE, byť podle logů to nebylo vinou hardwaru či modulů, ale chybami v distru (build DE). Naopak Mageia 7 (byť alpha), PCLOS i Manjaro měly podobné provozní vlastnosti, jaké mám s openSUSE Tumbleweed.
Pánové, díky za příjemně konstruktivní komentáře, tipy a triky... Pročteno, zazálohováno a zabookmarkováno pro budoucí referenci. :)
Nemáš vůbec zač.
Mám vyzkoušené počítače ASRock DeskMini A300. Do nich jsem dal Athlony 200GE. BIOS jsem ponechal v původní verzi (1.10) - povoleno bootování bez EFI. K monitoru je připojuji přes HDMI. Aktuální Arch Linux (kernel 5.0, mesa 19.0, amdgpu 19.0, amd-ucode 20190313.efd2c1c). Povolen "early microcode update" https://wiki.archlinux.org/index.php/Microcode#Enabling_early_microcode_... V parametrech jádra mám povoleno použití gfxoff - parametr "amdgpu.ppfeaturemask=0xffffbfff" - snižuje to spotřebu v klidu a při nízké zátěži. Používám X11. V xorg.conf mám povoleno Option "TearFree" "true". Firefox jsem zkoušel v mnoha různých verzích konfigurace (layers.acceleration.force-enabled, media.hardware-video-decoding.force-enabled, gfx.webrender.all, ...). Přehrávače mpv a mplayer jsem zkoušel v mnoha konfiguracích. Testoval jsem různé nastavení výkonostních stavů CPU a GPU. A po několika týdnech testování zatím nikdy nedošlo k zatuhnutí grafiky. VLC nepoužívám - tam se nemohu vyjádřit.
Pokud jde speciálně o to A300, tak tam jsem zjistil nějaké menší chyby: Na desce jsou dva výstupy k připojení ventilátoru, které se nastavují v BIOSu - tam je chyba - aby regulace fungovala, je nutné v BIOSu zadat stejné hodnoty pro oba ventilátory, i v případě, kdy připojen je jen jeden. Též jsem četl, že první verze BIOSu je přehnaně vybíravá ohledně použitých RAM.
Spotřeba toho zařízení je velmi příznivá, s SSD, připojené k full HD monitoru, s USB optickou myší, USB klávesnicí a připojené do sítě to má v desktopu v klidu spotřebu okolo 6W.
Bohužel to ale není pasivně chlazené.
Pánové, díky za příjemně konstruktivní komentáře, tipy a triky... Pročteno, zazálohováno a zabookmarkováno pro budoucí referenci. :)
Edit: Option "TearFree" "true" je pro mě celkově novinka. Ale kacířsky se přiznám, že už je to pár let od posledního nasazení linuxu na desktopu.
Edit2: Navíc s nvidií
A300 už mám otestovanou a recenze bude, ten bug s ventilátory, na tom jsem narazil taky, poslali mi tedy Beta verzi BIOSu, ale než jsem to stihl flashnout, fixli to s BIOSem 3.40
Existuje nejaka moznost prepojit A300 s USB-C monitorom? Nie je na to nahodou nejake nastavenie v BIOSe? Kedze USB-C by mal nativne podporovat DisplayPort Alt. Mode?
To by mne též zajímalo. Bohužel já nemám možnost to vyzkoušet, protože nemám USB-C monitor. Předpokládám, že to zřejmě není možné, protože výrobce v manuálu A300 možnost DP přes USB-C neuvádí a neviděl jsem ohledně toho ani žádné nastavení v BIOSu. Pokud by se to někdy v budoucnu podařilo zprovoznit například aktualizací firmware, tak bych to bral za velmi příjemné překvapení, ale moc na to nespoléhám, že k tomu dojde.
Ja mam prenosny 15.6" monitor ASUS MB169C+ ktory sa cez jeden USB kabel napaja aj posiela DisplayPort signal, s tymto PC by to bola idealna prenosna stanica konkurujuca radovo drahsim notebookom. Bohuzial skusal som to zapojit a s A300 to nefunguje, len som este nemal cas pohrabat sa v nastaveniach ci tam nahodou nieco ohladom tohto nieje..
Vím, že ty jednokabelové monitory existují. Díval jsem se v recenzi na HP elitedisplay S14
https://www.laptopmag.com/reviews/monitors/hp-elitedisplay-s14-portable-...
Problém je, že USB-C konektor na A300 je pouze "3.1 Gen 1", tedy by měl mít přenosovou rychlost maximálně 5Gbit/s. Ale DisplayPort má nejnižší režim 5,184 Gbit/s, alespoň tedy myslím.
Řekl bych spíš že ne. Podle mě tam není přivedený DP, kdyby byl, tak se tím ASRock pochlubí + by přibyla možnost připojit až čtyři monitory, teď jdou připojit maximálně tři, což mám i ozkoušené.
USB-C je "jenom" konektor - nemá specifikované nějaké povinné signály. Je v něm jen to, co do něj výrobce nacpe.
2200GE se dá běžně koupit? Viděl jsem ho jen avízovaného v novinkových článcích, ale nikdy ne v reálném eshopu. Může někdo doporučit nějaké uživatelsky přítulnější rolling release distro? Zkusil bych LMDE 3, ale jinde se tu píše i o problémech s Debianem.
Běžně se koupit nedá, jde o OEM verzi, ale dá se objednat z Británie. Poštovné mne stálo celé 4€ :). Tehdy jsem dostal tip myslím zrovna od ap. Už tam nabízejí i v článku zmíněný AMD Ryzen V1605B. Předesílám, že se platí předem, do Německa mi to přišlo asi za 4 dny.
https://www.quietpc.com/amd-2nd-gen-ryzen-apus
https://www.quietpc.com/sys-mmdpc
> Může někdo doporučit nějaké uživatelsky přítulnější rolling release distro?
Záleží na tom, co si pod tím představuješ a jaké distro znáš. Na větvi Archu je slušně vyhlížející Manjaro, na větvi Mandrivy je to PCLOS, já používám openSUSE Tumbleweed. Všechny tři mají nějaké ty GUI nástroje pro uživatele, podle mě má nejlepší nástroje openSUSE. Jen varování předem, openSUSE Tumbleweed se nedá aktualizovat přes správce balíčků, jak bývá zvykem, ale buď přes applet (na panelu hlásí aktualizace a klikem se instalují) nebo z terminálu. IMHO zbytečnost, ale prý odůvodněná. Z větve Debianu neumím poradit uživatelsky přívětivé rolling update distro. Třeba ti poradí někdo jiný. Je jich celá řada, např.
https://en.wikipedia.org/wiki/Rolling_distribution
> Zkusil bych LMDE 3
Linux Mint není rolling update distro; ani verze založená na Ubuntu, ani ta postavená na Debianu.
Dosud všechny mé zkušenosti byly Ubuntu based, tedy Ubuntu, Lubuntu, Linux Mint Xfce, nyní Ubuntu MATE. Před výběrem distra jsem si četl o balíčkovacích systémech a zároveň vhodnosti pro nezkušené uživatele. Takže jsem vybral APT. Na Linuxu sice jedu někdy od roku 2010, možná dřív s tím, že od roku 2013 nepoužívám nic jiného, ale za nějakého zkušeného uživatele se nepovažuju. Prostě to nainstaluju a jedu, když něco potřebuju najdu na webu nějaký návod a naházím příkazy do konzole. Doposud jsem krom systémového disku používal oddíly formátované na windowsí NTFS, do teď mi není jasné jak je to s oddíly a Linux systémem. :-D Dokonce jsem o tom hledal nějaké články, ale nikdy jsem nic polopatického jak na oddíly a strukturu linuxového prostoru pro data nenašel ...
LMDE je Mint který staví na Debianu, ostatní verze Linuxu Mint jsou Ubuntu based. http://en.wikipedia.org/wiki/Linux_Mint#LMDE
Já vím co je LDME :), resp, že Mint je na bázi Debianu a Ubuntu, koneckonců jsem to zmínil výše. Debian je svým způsobem opakem rolling update dister; myšleno tak, že v něm najdeš starší verze kernelu a dalších inkriminovaných součástí systému, než v tzv. stabilních verzích různých distribucí. Debian používám typicky na server, kde je starší HW a vím, že to prostě fungovat bude, stejně jako třeba CentOS. Ale to nejsou distra vhodná na nový HW. Na distribuce je potřeba nahlížet s ohledem na to, co od nich chceš a co máš za HW. Já jich používám několik a na novější desktopy a laptopy automaticky rolling update distro, běžným uživatelům automaticky openSUSE, protože má Yast (naklikaj si v podstatě vše myší a neprudim je s terminálem). Podobné je to i s větví Mandrivy.
Uživatelsky znáš distribuce z větve Debianu. Jak jsem psal, neumím ti poradit rozumné rolling update distro z této větve. Osobně se domnívám, že balíčkovací systémy jsou v principu stejné. Jestli používáš terminál, tak jestli napíšeš apt-get install mc nebo zypper install mc (resp. zypper in) je celkem jedno. A tuplem je ti jedno, jestli je to balík deb nebo rpm nebo třeba pkg.tar.xz. U správce balíků je to už trošku jiné, Synaptic je podle mne asi nejlepší správce balíků, ale opět nemám sebemenší problém používat Yast nebo třeba Octopi :). Princip je prostě stejný, stačí se rozkoukat. Já nejsem zastánce ani konkrétního distra, ani konkrétního balíčkovacího systému, nedej bože formátu balíčků. Z uživatelského pohledu jsou to jen žabomyší války. Jediné co uživatele nakonec zajímá je to, jestli mu ten či onen systém funguje dle představ a nic víc.
Oddíly v Linuxu? Stejně jako ve Windows, jen jiné souborové systémy. Ve Windows se disky "nikam nepřipojují", jmenují se C: D: E: atd. V Linuxu ve správci souborů vidíš vlevo diskové oddíly a můžeš si je pojmenovat jak chceš, třeba i C a D :). Nicméně je běžné, že disky připojíš do adresářové struktury. Disk připojuješ do libovolného adresáře. Když máš jednouživatelský PC a /home/peliculiar jako domovskou složku, můžeš třeba připojit disky do adresářů /home/peliculiar/C a /home/peliculiar/D. Pro víceuživateslké PC volíš třeba /disk1 a /disk2 nebo třeba /media/disk1... jak je libo a podle potřeb. To je celé. Kdyžtak mi napiš mail na můjnick zavináč email.cz a já ti to podrobněji vysvětlím, jestli chceš. Není na tom nic složitého - ať tu nezasviníme diskuzi ještě víc :D
Mám podobné špatné zkušenosti - Ryzen 5, 2400G (základní deska Gigabyte GA-350) a Xubuntu 18. Mesu jsem teď upgradoval na 19, ale i 18 se chovaly stejně - náhodné mrznutí.
Poměrně často to zamrzne s VLC ve fullscreenu - ale ne jen. Někdy to zamrzne 1x denně, jindy i 3x po sobě (bez spuštěného VLC, jen s FireFoxem). Někdy vidím pohyb kurzoru myši, někdy ani to. Přepnutí do jiné konzole taky nefunguje - pomáhá jen tvrdý reset.
Mám připojený monitor na DVI-D a televizi na HDMI. V Mese 18 to nezobrazovalo základní dialog grubu, zobrazovat to začalo až bootovací hlášky při přepnutí grafiky během bootování... Mesa 19 to zhoršila - na monitoru při bootování vidím až přihlašovací dialog, grub ani přihlašovací hlášky se mi na něm vůbec nezobrazí (je to ale vidět na HDMI, pokud je ta televize zapnutá).
A naprosto se mi nedaří to přinutit, aby to jako primární monitor už při bootování používalo to DVI-D (což bude asi vlastnost desky).
V syslogu jsou u VGA nějaké chybové hlášky, které jsem našel u starého hlášení nějakého dávno opraveného bugu...
Mám tam poslední Ubuntu MATE LTS a tuhne mi to ve FireFoxu. Pohybuje se kurzor, ale jinak systém nereaguje, když vypnu monitor a pak ho pustím ukazuje, že nemá signál. Až po instalaci jsem upgradoval BIOS a nahrál jsem i nejnovější kernel 5.X, ale zámrzy nezmizely.
Linux Mint MATE se mi nepodařilo nainstalovat, protože jsem měl instalační obrazovku na čtvrtiny a části obrazovky s volbami potřebnými pro pokračování nebyly vidět. Jiné distro jsem zatím nezkoušel.
Jedu (přirozeně) přes iGPU a DisplayPort. HDMI jsem nezkoušel, ale pochybuju, že v tom by mohl být problém.
ASUS RoG STRIX B350-F
AMD Ryzen 3 2200G (RX Vega)
Samsung SSD 970 PRO, M.2 - 512GB
Crucial Ballistix Sport LT Grey 16GB (2x8GB) DDR4 3000
Vidím, že nejsem jediný.
Dívám se na reddit
https://www.reddit.com/r/Amd/comments/99ge0t/ryzen_5_2400g_linux_compati...
a i tam jsem našel podobné zkušenosti, jako máme my. Někdo tam psal, že mu pomohlo v BIOSU vypnout C-stavy, zkusím to.
A zkusím nějaký další update kernelu (zkoušel jsem kde co od 4.17 výš...).
Pokud jde o možnost vypnout v BIOSu C-stavy, tak to řeší problém, kdy počítač zamrzá při nízké zátěži procesoru. https://bugzilla.kernel.org/show_bug.cgi?id=196683
Ale jestliže k zamrzání dochází při aktivním používání VLC či Firefoxu, jak popisujete, tak to téměř jistě s C-stavy nesouvisí a vypadá to na problém s GPU. Spíše by to mohl tedy řešit ten update kernelu, linux-firmware, amdgpu a případně BIOSu. Určitě bych zkusil použít i aktuální verzi jiné distribuce - třeba si na vyzkoušení spustit Manjaro z USB https://manjaro.org/support/firststeps/#making-a-live-system
Ohledně GPU jsou chybová hlášení zde: https://bugs.freedesktop.org/query.cgi když jako produkt zadáte DRI.
Díky moc za info.
Při tom zamrznutí to využití počítače bylo asi relativně nízké, ale asi máte pravdu, že to skutečně vypadá spíš na GPU, i podle těch hlášek v dmesg.
Zkusím se o víkendu ještě podívat na aktualizaci linux-firmware, to by mohl být taky zdroj problémů - v Xubuntu bude asi nějaká verze odpovídající staršímu kernelu a ukuu asi samo aktualizaci nezařídilo.
S těmi C-stavy jsem zatím nezkoušel nic, ale aktualizoval jsem znovu kernel (poslední 4.20) a Mesu (původně ze ppa SWAT, nyní z ppa Oibaf). Tohle trochu pomohlo - aktuálně pády zhruba po 4 dnech občasného provozu, několik pádů po sobě už jsem od té doby nezaznamenal.
Moje distribuce je Xubuntu 18.04 (spravuji několik počítačů a mám na nich stejnou distribuci). Testovat jinou živou distribuci při nízké četnosti pádů moc nepomůže a celou distribuci bych měnil nerad (spravovat několik různých distribucí současně mi připadá jako cesta do dalších potíží).
Dalším hledáním jsem narazil na bug, který prakticky přesně popisuje moje problémy:
https://bugs.freedesktop.org/show_bug.cgi?id=105733
Údajně kernely Ubuntu některé věci přebírají s jistým zpožděním, navíc některá nastavení v nich vůbec nejsou možná (tj. nepodporují dostatečně daný HW). Jedno z doporučení toho bugu bylo:
* použít jiný kernel (např. drm-next-4.21-wip, viz koment 76 https://bugs.freedesktop.org/show_bug.cgi?id=105733)
* pro AMD Vega GPU použít ppa unstable Padoka
sudo add-apt-repository ppa:paulo-miguel-dias/mesa
* vyzkoušet, jestli problém není v RAM (i funkční ram, které s Intele mohla běhat dobře, může mít problémy s AMD).
Změnit ppa a převzít jinou Mesu není problém.
Moc se mi nelíbí variant jít do Dragon kernelu WIP, který není doporučovaný do produkčního prostředí (navíc jsem netušil, že si někdo může udělat byznys na tom, že bude vydávat balíčky s upravenou verzí kernelu). Kompilace kernelu je něco, co se mi ještě nikdy nepovedlo, takže je otázka, jestli by se mi to povedlo s Dragon kernelem.
Je škoda, že Ubuntu kernely a firmware nemají lepší podporu AMD HW...
Pokud jde o Dragon kernel, tak to bych se bál použít. Lidi, kteří za tím stojí, neznám.
Kompilaci vlastního kernelu bych se snažil vyhnout. Deska GIGABYTE a Ryzen 5 2400G je normální kombinace - měla by fungovat s běžným Linuxem.
Xubuntu 18.04, je LTS vydání, což sebou bohužel nese to, že se tam používají relativně staré ovladače. Firmware pro procesory AMD je tam ve verzi z května 2018.
Pokud u Xububntu musíte zůsta, pak by mohlo pomoci alespoň přejít z 18.04 na současné stabilní vydání 19.04, kde firmware je novější (z listopadu 2018).
Jak se v tom bugu poukazuje na problém s pamětí, tak to je třeba zrovna věc, která může být opravena vydáním nové verze AMD mikrokódu. Ten mikrokód se získá buď aktualizací BIOSu, pokud ho výrobce základní desky správně do BIOSu přidal. A nebo může být součástí operačního systému. Xubuntu přebírá mikrokód a linux-firmware z Ubuntu a Ubuntu ho přebírá z Debainu. Takže Ubuntu bionic 18.04LTS ho má ve vrzi z 20180524, tedy z doby, kdy se ta APU poprvé objevila v obchodech!!!
https://packages.ubuntu.com/bionic/amd64/amd64-microcode
Aktuální stabilní vydání Ubuntu disco (19.04) ho má ve verzi 20181128, takže tam už by lecos mohlo být opravené.
https://packages.ubuntu.com/disco/amd64/amd64-microcode
A pro srovnání, rolling distribuce jako Arch nebo openSUSE Tumbleweed používají AMD mikrokód a linux-firmware v aktuálních verzích z dubna 2019, což by tak správně mělo být, protože kernel je vyvíjen a testován ve vztahu k aktuálnímu BIOSu a mikrokódu.
https://www.archlinux.org/packages/core/any/amd-ucode/
https://wiki.archlinux.org/index.php/Microcode
https://software.opensuse.org/package/ucode-amd
Do Xubuntu se tyto verze ovladačů též jednou dostanou, ale bude to prostě až později.
Díky za podrobnou odpověď. Bohužel v tom problém není - aktualizoval jsem jak Bios, tak kernel, tak linux-firmware (u amdgpu mám verzi z konce dubna).
Celkově to pomohlo, ty pády bývaly mnohem častější. Teď jsem ještě zkusil vývojovou mesu z repozitáře padoka (doporučená pro Raven Ridge/Vega) a ubuntu kernel 5.2, ale to samo nepomohlo - během hodiny to zase vytuhlo, zase stejné příznaky - pohybovala se jen myš, všechno ostatní mrtvé.
Zkusil jsem ještě přece jen v biosu vypnout ty C-stavy, uvidím, jestli to bude mít vliv.
Ještě mám nějaké další náměty, co by šlo vyzkoušet:
1. Kromě omezení c-stavů (processor.max_cstate=5) přidat do parametrů kernelu v zavaděči rovněž parametr:
idle=nomwait
https://www.kernel.org/doc/html/v5.0/admin-guide/pm/cpuidle.html
https://bugs.freedesktop.org/show_bug.cgi?id=104817#c8
2. Pustit na cca 10 minut přehrávání libovolného videa v mpv pomocí příkazu:
mpv --no-correct-pts --fps=3 --ao=null some_arbitrary_video.webm
Parametry je vynuceno, aby se video přehrávalo zpomaleně, čímž asi dochází častěji ke střídání menší a větší zátěže GPU. Pokud systém má problém s přecházením mezi jednotlivými frekvencemi GPU, tak tímto testem by se to teoreticky mohlo snáze odhalit. Alespoň někteří uživatelé tedy uvádějí, že jim pak pomohlo přecházení mezi úrovněmi GPU vypnout. To se provede tak, že se jako root zadá třeba příkaz:
echo "low" > /sys/class/drm/card0/device/power_dpm_force_performance_level
tím je vynuceno použití jen nejnižší frekvence GPU (samozřejmě se toto nastavení nehodí pro hraní her).
Nebo lze zapsat tamtéž hodnotu "manual" a zadat, že se mají používat jen některé z frekvencí, například:
echo "1" > /sys/class/drm/card0/device/pp_dpm_mclk
echo "1" > /sys/class/drm/card0/device/pp_dpm_sclk
Tato nastavení se ztratí (vymažou do výchozího nastavení) při restartu systému.
https://bugs.freedesktop.org/show_bug.cgi?id=102322#c37
3. Někteří uvádějí, že jim pomohlo přidat do parametrů kernelu též:
amdgpu.lockup_timeout=0
Ale poněkud mi uniká, proč by to mělo fungovat.
Taky mne napadlo, že by tuhnutí mohlo souviset s použitím dvou monitorů, ale i kdyby to tak bylo, tak se tím bohužel hledání příčiny asi příliš nezužuje.
Zkoušel jsem všechno možné a nakonec to vyřešilo jediné - výměna kernelu na tuto verzi:
https://github.com/M-Bab/linux-kernel-amdgpu-binaries
a Mesu mám:
https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa
Sama ta Mesa nepomohla (zkoušel jsem i https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers), chtělo to až kernel z uvedeného zdroje.
Od výměny kernelu se ten problém s vytuhnutím grafiky (přičemž přes SSH se na počítač dalo připojit) nezopakoval .
Zdá se, že problém nebyl jen v zátěži jader (někdy to vytuhlo i bez zátěže, naopak zátěž problémy nedělala). Samo uspávání problém asi také nedělalo - občas počítač vytuhl po kompletním restartu, jindy až po několika dnech uspávání.
Já mám kernel 5.X a nepomohlo to v žádném ohledu. ;-)
Protože ke kernelu potřebuješ ještě novější X, mesu, libdrm, kernel firmware a podle distra také kernel firmware nonfree a ideálně také novější vaapi, kodeky, ffmpeg, popř. GST sestavený proti novější verzi vaapi....
Pokud jde o verzi DP a HDMI, tak na stránkách výrobce je vedle obrázku leták "Datasheet", kde se uvádí, že DP je 1.4 s maximálním rozlišením "4096x2160@60Hz" a HDMI je 2.0 s maximálním rozlišením "4Kx2K". Alespoň to tak bylo minulý týden, kdy jsem si to stáhl. Bylo tam uvedeno "Preliminary".
https://www.asrockind.com/overview.asp?Model=NUC-R1000
Edit:
Ještě tedy upřesňuji, že uvedeno je to v letáku ohledně desky NUC-R1000, která se montuje do toho iBOX.
Mno jestli bude dostupnost stejná jako u intel modelů, tak to stejně nikde nekoupíte. Když jsem před pár měsíci zjišťoval jestli se dá sehnat něco pasivního od asrocku (mají toho plný web), tak jsem došel ke zjištění, že v celé evropě se dal koupit jen jeden jediný model někde z anglie. U nás na to všichni dodavatelé pěkně z vysoka kašlou......
Nějaké ty rackovité desky jsem občas kupoval v Softcomu, normálně je dodali. Ale nezkoušel jsem tyhle jejich pasivní miniPC.
Omluva za komentář mimo (visel pár minut) - původní text jsem radši celý smazal, poněvadž půlka z toho byla popletená.
Ohledně AsRocku nemám moc dobrý pocit z jejich supportu - ať už se jedná o kancelářské nebo průmyslové věci. Specificky ten jeden box s AMD APU nemá na webu ke stažení vůbec nic, ale obecně k jejich ATOMovým boardům bývají downloady taky dost hubené. Dávám přednost výrobcům a výrobkům, kde lze na webu dohledat aktuální BIOS a je podporován legacy boot (nikoli UEFI-only).
Podobný distribuční model jako AsRock Industrial má zřejmě další TW výrobce: iBase, pro Evropu zastoupení v UK. Taky mají i něco s Ryzenem (a taky pár produktů "Intel CPU + AMD Grafika").
https://www.ibase-europe.com/english/ProductTypeB/Digital-Signage-Player...
https://www.ibase-europe.com/english/ProductTypeB/Digital-Signage-Player...
A stejně jako AsRock nemají k tomu na webu BIOS - přesto mi jejich downloady připadají o střípek lepší.
Nejlepší dostupnost mívají TW výrobci zastoupení v Německu, nebo ještě v Holandsku - zejm. Němci mívají dost věcí skladem. Naopak s britskými distributory je často trochu těžká domluva, díky "splendid isolation" dražší doprava apod.
Taky čekám, kdy se low-power Ryzen masově objeví v lehce průmyslových fanless boxech, kde jeho větší počet video portů najde uplatnění. Zatím to tak nevypadá - většině sortimentu kraluje ATOM několika generací. Přes tu bídu s dostupností Apollo/Gemini Lake a přes známé problémy počátečních revizí Intelova křemíku od BayTrailu výš. Historicky se objevilo pár boxů s AMD grafikami v MXM patici, ale jednalo se vždycky o okrajovou záležitost.
>Po nedávném vydání embedded Ryzenů R1505G a R1606G
Je pravdu, že aj 7 dní je nedávno, ale použil by som výraz minulotýždňovom namesto nedávanom.
TAIPEI, Taiwan
04/16/2019
At the Taiwan Embedded Forum, AMD (NASDAQ: AMD) announced the Ryzen™ embedded product family is growing with the new AMD Ryzen™ Embedded R1000 SoC.
https://www.amd.com/en/press-releases/2019-04-16-amd-expands-embedded-pr...
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.