Dotaz: PCIe port bifurcation - zkušenosti

[PetebLazar]

Má někdo praktické zkušenosti s PCIe port bifurcation? Konkrétně mi jde o řešení stavících přímo na schopnostech rozdělení PCIe linek v rámci BIOSu MB.

Na ASRock X399 Taichi mi došly PCIe sloty (2xGK pro HostOS/GuestOS ve slotech 16x, 2x Blackmagic Decklink ve slotech 8x). Tak zvažuji o rozbočení jednoho PCIe 8x slotu na dva PCIe 4x (pro oba Decklinky). V ČR jsem našel toto řešení https://www.lan-shop.cz/delock-89835-237549, možná že v kombinaci s redukcí M.2->PCIe 4x by to kýženého cíle dosáhlo. Zařízení v rozbočených slotech budou využity jen v rámci HostOS,takže případné sdílení IRQ# (pokud) by neměl být problém. Alternativou by možná mohlo být využití zbylého volného M.2 NVMe slotu na MB se zmíněnou M.2_PCIe4x redukcí. Karty Decklink mají udávané TDP 17W, takže by při využití ext. napájení redukce neměl být problém.

RAM 640KB je možná dost pro každého, ale jak se ukazuje 60 PCIe linek nikoli!

Odpovědi

[pc2005]

Jenom postřeh někoho kdo se pohyboval v poslední době okolo PCIe, ale ne přímo na tyhle komponenty:

No jestli jsi si jistý, že ten čipset umí rozdělit x16 port na dva (a více) nezávislých linek, tak to z technického hlediska fungovat bude. Jedině by mohlo vadit PCIe gen3 že by měla průchodů konektorem přes adaptéry, ale zas tolik to není.

Vejde se do to MB mechanicky? (mě přijde, že PCIe karty budou kolmo na ten x16 splitter) Jestli tam ještě bude nějakej flatflexcable/kšanda PCIe prodlužovák (ten slot není otevřený!), tak si u PCIe gen3 nejsem jistý zda se to nebude navzájem rušit, u PCIe x1 gen1 jsem u FFC měl problém s rušením na embedded SoC.

Napájení přes ten disketovkovej molex je OK, ale pokud bys to připojil nějakou PCIe prodlužovačkou, tak by mohl být na konci dost velkej úbytek (ty FFC nebo kšandy nejsou na přenosy napájení moc orientovaný).

MSI přerušení je pohoda. To je vlastně speciální sledovaná adresa, na kterou se zapisuje magic word. Pokud se ten základní port rozdělí na víc nezávislých PCIe zařízení, tak to bude to samý i pro MSI (prostě jako víc nezávislých PCIe karet). Legacy přerušení nevím, tam se posílají emulovaný zpravy typu pin A je aktivovaný, to zpracovává čipset a na PCI byly INT piny ze specifikace sdílený. Ale asi to bude OK.

BTW Ještě se dá asi za 700Kč koupit PCIe switch, ale umí to jenom 4xPCIe x1 gen2.

[PetebLazar]

"No jestli jsi si jistý, že ten čipset umí rozdělit x16 port na dva (a více) nezávislých linek, tak to z technického hlediska fungovat bude."

V to doufám, že nezůstane pouze u nefunkční volby v BIOSu. Každý ze slotů 16x/8x jde volbou rozdělit na 4x4x4x4/4x4x

"Vejde se do to MB mechanicky? (mě přijde, že PCIe karty budou kolmo na ten x16 splitter) Jestli tam ještě bude nějakej flatflexcable/kšanda PCIe prodlužovák (ten slot není otevřený!), tak si u PCIe gen3 nejsem jistý zda se to nebude navzájem rušit, u PCIe x1 gen1 jsem u FFC měl problém s rušením na embedded SoC."

Pravda, již nyní si u PCIE2(8x) vypomáhám pomocí riseru, jelikož ASUS STRIX je 2,5slotový cvalík.

"Jedině by mohlo vadit PCIe gen3 že by měla průchodů konektorem přes adaptéry, ale zas tolik to není."

Ty karty co chci po splitu krmit jsou jen PCIe 4x 2.0, tak tam snad nebude takový tlak na kvalitu přenosu. Již teď jsem snad ten raiser využil krátkodobě pro GK PCI16x3.0 a nevzpomínám na problémy (kdyžtak koupím kvalitnější).

"Napájení přes ten disketovkovej molex je OK, ale pokud bys to připojil nějakou PCIe prodlužovačkou, tak by mohl být na konci dost velkej úbytek (ty FFC nebo kšandy nejsou na přenosy napájení moc orientovaný)."

Ta redukce je snad plně napájena z ext. konektoru, zdrojem je Corsair RM1000, tak snad. Jestli si to bere většinu z těch 17W z 12V tak bych o to strach neměl. Kdyžtak přeměřím teplotu kabeláže.

"MSI přerušení je pohoda. To je vlastně speciální sledovaná adresa, na kterou se zapisuje magic word. Pokud se ten základní port rozdělí na víc nezávislých PCIe zařízení, tak to bude to samý i pro MSI (prostě jako víc nezávislých PCIe karet). Legacy přerušení nevím, tam se posílají emulovaný zpravy typu pin A je aktivovaný, to zpracovává čipset a na PCI byly INT piny ze specifikace sdílený. Ale asi to bude OK"

Obě ty karty budou využívány z HostOSu(Linux) jedním modulem (blackmagic-io), takže se sdílení přerušení až tak nebojím. Úplná selanka to ale není. Tím jak jsem zaplnil všechny sloty tak se mi sdílelo přerušení mezi dvěma v IOMMU separovanýmí zařízeními (jedno v HostOSu druhé v GuestOSu ). Na ACS patch jsem nikdy nenašel odvahu, ani nevím jestli na X399 funguje.

BTW Ještě se dá asi za 700Kč koupit PCIe switch, ale umí to jenom 4xPCIe x1 gen2.

To by asi nestačilo, ty karty při přenosu lossless formátu překračůjí 1GB/s, je radost to ukládat.

[pc2005]

již nyní si u PCIE2(8x) vypomáhám pomocí riseru

Tak ono záleží na kvalitě provedení. Mám nějakej PCI riser, který je tvořený normální šedou kšandou a PCI karty v tom dost vypadávají.

Ta redukce je snad plně napájena z ext. konektoru, zdrojem je Corsair RM1000, tak snad.

Jo jestli máš kartu rovnou v té redukci na M2 tak pohoda. Já myslel kdyby byl v cestě dlouhej pasivní riser (u mikroUSB prodlužek mám obecně problém, že na konci bývá výrazně menší napětí než 5V i při malých odběrech proudu).

jedním modulem (blackmagic-io)

Pro každé samostatné PCIe zařízení (i když budou dvě stejné karty) se volá probe() samostatně (tedy registrace přerušení, paměťových regionů apod).

Jinak moderní PCIe karty mají advanced error reporting feature, kde můžou oznamovat zda dostaly poškozené pakety, takže pokud máš modul v kernelu, tak stačí sledovat dmesg. Ale nemyslím si že to bude dělat problémy.

[PetebLazar]

Zkusím to se současným šedým 200mm riser kabelem. Když to bude čínit problémy vezmu ten černý (ten by měl být kvalitnější). Oba z nabídky. http://compuny.cz/--redukce-pci-e.html

Ten volný M.2 NVMe slot na MB zkusím ušetřit pro případný 10Gbps NIC, jakého ty tak mohou dosahovat TDP? U těch 100Gpbs je to prý až 100W.

[pc2005]

jakého ty tak mohou dosahovat TDP

Tak to vůbec nevím, ale PCIe konektory umí max 75W energie (byl u toho ten humbuk když radeon RX480 odebíral trochu víc - i když kvalitní deska samozřejmě zvládne i víc). Pro hodnoty nad těch 75W je obvykle power socket přímo na kartě. Pokud by to šlo některou z těch šedejch prodlužek, tak bych si radši stanovil nižší limit. Teďka se koukám na kšandu 1.27mm (klasická IDE/floppy) a má 28AWG což by mělo dovolit maximální proud 1.4A. V pci-e konektoru je 5x +12V větev, takže by ta kšanda měla přenést až 86W. V PCIe prodlužce ale bude menší rozteč a tedy asi i menší průměr vodičů kšandy.

[dustin]

Tak ono záleží na kvalitě provedení. Mám nějakej PCI riser, který je tvořený normální šedou kšandou a PCI karty v tom dost vypadávají.

Používám podobnou PCI prodlužku a mívá problémy s female paticí - příliš volná, karta v ní musí být úplně rovně, jinak občas ztrácí kontakt.

[PetebLazar]

Počítač (case Corsair 750D) leží na zádech na skříni MB směrem dolu, tak zvažuji, že horní bočnici nahradím custom krytem ze silnějšího plechu, s možností uchycení riserované převodní PCIe16x_4xNVMe karty (tam by asi vzhledem k šířce case byl nutný 300mm kabel). Bude to chtít slušně upevnit a případně zafixovat příchozí/odchozí HDMI kabely do Decklink karet.

[PetebLazar]

Oprava: s MB "na dně" (MB směrem dolu je špatně vyjádřeno).

[pc2005]

Jj přesně tu mám taky.

[PetebLazar]

Karta PCIe16x->4xNVMe bude asi až za tři týdny, tak mi to nedalo a v tom předvánočním (ne]shonu jsem se rozhodl, že zkusím aspoň variantu s volným NVMe slotem na MB a redukcí M.2=>PCI4e. Zatím to vypadá funkčně, uvolněný druhý PCIe8x slot jsem opět obsadil historickou ATI HD5770 (kompatibilní s KVM/QEMU/passthrough pro obsluhu GuestOSu:WinXP). Dočasně vyjmutou PCIe 1x kartu (2xRS-232+LPT) možná časem připojím pomocí PCIe1x_PCIe1x riseru (v prostoru slotu již není k hnutí).

# Výpis zařízení zapojených v M.2,PCIe16x,PCIe8x slotech:
$ lspci |egrep  'VGA|Black|Non-Vol'
08:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961
09:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 5770]
0a:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1)
41:00.0 Multimedia video controller: Blackmagic Design DeckLink Mini Recorder 4K
42:00.0 Non-Volatile memory controller: Device 1987:5007 (rev 01)
43:00.0 Multimedia video controller: Blackmagic Design Intensity Pro 4K
44:00.0 VGA compatible controller: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] (rev a1)

https://www.monitos.cz/tmp/m2_pcie4x.png

Pohled z prostředka MB směrem k záslepkám. Vlevo GTX960 pro GuestOS(Win10), vpravo GTX1080Ti pro HostOS(Xubuntu 18.04 s vanilla kernel 4.19.8), uprostřed je zelená redukce M.2->PCIe4x včetně přívodu napájení osazený Blackmagic Decklink Recorder 4K Pro zbavený záslepky. Šedivý riser kabel osvobozuje PCIe8x z pod 2,5 slotového chlazení STRIXu a osazen je druhým Blackmagic). Dořešit bude nutné upevnění riserovaných slotů. Asi vhodně upravenou novou nočnicí schopnou upevnění konektorů riser kabelů(osazených karet). Pozn. Ten plochý kabel se o ventilátory GK za chodu neopírá.

Z celkem 60ti CPU PCIe linek dostupných v PCIe/NVMe slotech ASRock X399 Taichi je využito 56 (16x,4z8x,16x,8x/4x,4x,4x).

[PetebLazar]

V prostředí Linuxu karta v redukci M2_PCIe4 (BM Mini Recorder 4K) se po nějaké době (jednotky minut při používání) z pohledu blackmagic-io modulu ztratí a není vidět v aplikacích (zachytávací MediaExpress ani konfigurační DesktopVideoSetup). Druhá karta BM Intensity 4K Pro je stále dostupná. Zkusil jsem proto rebootovat do nativních Win10, aby ověřil zda jde o HW či SW problém. Při cca 15 min zkušebního grabování 2160p30 jsem nezaznamenal problém (bez ztraceného snímku), takže asi půjde o SW problém v Linuxu (ovladače, kernel, ..). HW Blackmagic je typicky podporován v business distribucích Linuxu (RHEL/CentOS 7.3) od nichž jsem svou distribucí a svým vanilla kernelem 4.19 asi na hony(léta) vzdálen.

Zkusím generický kernel distribuce (4.15?), zda se chování změní.

[pc2005]

Hoď výpis dmesgu. Je karta vidět pomocí lspci -vvnn?

[PetebLazar]

I když se karta ztratí (z pohledu aplikací), na lspci výpisu zůstává. Zkouším se vrátit na generický kernel distribuci Xubuntu 18.04 (4.15), ta je ze strany BlackMagicuDesign mezi podporovanými. Zkusím koupit pro jistotu ten lepší černý riser kabel (ten šedivák asi není opravdu ideální). Až se karta vytratí doplním výpis z dmegs.

[pc2005]

Pošli prosím tě výpis toho příkazu. Ono i když PCIe zařízení selže, tak ve výpisu občas zůstane, protože ten výpis se generuje částečně z cache v kernelu (závisí na dalších parametrech toho lspci). Kernel obvykle nečeká, že mu někdo vytrhne kartu s přímým přístupem do RAM během používání.

Ten dmesg by to "vytrhnutí"/výpadek kabelu mohl vypsat. Ale může to bejt i nějakej jinek problém nebo soubeh problémů zdanlivě nesousisejících systémů. Bez toho to je jen věštění z křišťálové koule.

[PetebLazar]

Já se tomu nebráním, ale jako na potvoru nechce karta "zmizet". Pouštím vedle ní 3D zátěž jak v HostOSu tak i v GuestOS(GPU passthrough) nejbližší fyzické okolí (s BM kartou sousední GK) a zatím nic.

Takže zatím lspci pro právě grabující kartu. Nejde mi to sem vlozit v zadnem formátovacím tagu, tak aspon externe. https://www.monitos.cz/tmp/bm_recorder_4k_grab.txt

[PetebLazar]

Zkusil jsem vynucení chyby osazením jako do slotu M.2=PCIe4x(Recorder), tak do riseru(Intensity).

V tomto pripade je asi i v lspci zrejma:

41:00.0 Multimedia video controller: Blackmagic Design DeckLink Mini Recorder 4K (rev ff) (prog-if ff)
	!!! Unknown header type 7f
	Kernel modules: blackmagic_io

konec dmesg
[  544.026915] dpc 0000:40:01.1:pcie010: DPC unmasked uncorrectable error detected, remove downstream devices
[  544.037718] dpc 0000:40:01.1:pcie010: DPC containment event, status:0x1f09 source:0x0000
[  544.037721] dpc 0000:40:01.1:pcie010: DPC unmasked uncorrectable error detected, remove downstream devices
[  544.048739] dpc 0000:40:01.1:pcie010: DPC containment event, status:0x1f09 source:0x0000
[  544.048742] dpc 0000:40:01.1:pcie010: DPC unmasked uncorrectable error detected, remove downstream devices
[  544.059736] dpc 0000:40:01.1:pcie010: DPC containment event, status:0x1f09 source:0x0000
[  544.059739] dpc 0000:40:01.1:pcie010: DPC unmasked uncorrectable error detected, remove downstream devices
[  544.070879] dpc 0000:40:01.1:pcie010: DPC containment event, status:0x1f09 source:0x0000

Zkusím chování při stejné konfiguraci v nativních Win10.

[PetebLazar]

Ve Windows obě karty úspěšně zachytávaly současně. Tak mne napadlo, čím se vlastně liší Windows a Linux a napadla mj. úrověň podpory powermanagementu. Tak jsem to zkusil v GRUBu zmenit na pcie_aspm.policy=performance a podarilo se asi 25min zachytávání 2160p30 na Recorder(v M.2-PCIe4x) a na konci asi 6min pridaneho zachytavani druhou kartou (Intesity) výstupu z GuestOS:XP. Ale asi dochazi k vzajemnemu ruseni (sedivy nestineny riser kabel vedouci podel karty) jelikoz log je plný chybových hlášení (přenosu na PCIe?). Po skonceni grabovani karta opet zmizela se stejnou chybou. Ten M.2 slot asi nebude to prave orechove.

 2289.703976] dpc 0000:40:01.3:pcie010: DPC containment event, status:0x1f00 source:0x0000
[ 2289.703980] dpc 0000:40:01.1:pcie010: DPC unmasked uncorrectable error detected, remove downstream devices
[ 2289.703981] pcieport 0000:40:01.3: AER: Multiple Corrected error received: id=0000
[ 2289.703996] pcieport 0000:40:01.3: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=400b(Transmitter ID)
[ 2289.704011] pcieport 0000:40:01.3:   device [1022:1453] error status/mask=00001100/00006000
[ 2289.704020] pcieport 0000:40:01.3:    [ 8] RELAY_NUM Rollover    
[ 2289.704025] pcieport 0000:40:01.3:    [12] Replay Timer Timeout  

[frr]

ASPM vypnout úplně a ještě bych zkusil podřadit rychlost/generaci PCI-e v daném slotu, pokud to lze (nejspíš v BIOSu) a pokud bude nižší průchodnost stačit.

Jinak... nemůže v některé konfiguraci docházet k tomu, že se úzkým hrdlem stane propoj mezi PCH a CPU? (PCI-e x4 cca na úrovni gen.2/gen.3) V manuálu k motherboardu by mohl být namalovaný "panák".

[PetebLazar]

Všechny PCIe linky M.2 a PCIe16x/PCIe8x slotů jsou obsluhovány přímo CPU. Z chipsetu je obsluhován pouze PCIe1x 2.0 slot (X399 chipset snad vůbec nemá 3.0, pokud tedy nepočítáme ty ctyři co je jimi spojen s CPU). https://www.cnews.cz/wp-content/uploads/2017/08/Ryzen-Threadripper-AMD-X399-platforma.jpg

Vypnuté ASPM jsem měl dosud. Ta karta co nezlobí jede jako PCIe 1.1 4x (asi zcela jiné nároky na pásmo než 2.0,3.0), ta co zlobí jede PCIe 2.0 2x(holt vyšší takty). Stejné rychlosti dle HWINFO/lspci jsou ve Win i Linuxu. Vezmu ten lepší riser a uvidím. Od Thermaltake stoji 1kKč+, tak asi nejpreve zkusím ten Lian-Li ~500Kč. http://compuny.cz/--redukce-pci-e.html

[pc2005]

Jo to je jasný tohle hlášení. Karta vypadne, AER zahlásí timeout při opakovaní přenosu a Downstream Port Containment (hmm tohle na svý šunce ještě ani nemám) odpojí port, aby zamrzlé přenosy na "sběrnici" nezasekly systém. Další volání lspci (kernel ví, že tam něco bylo, navíc driver si to zaregistroval) pak vrací všude jedničky (0xffff), což je normální hodnota pro neexistující zařízení.

Mohlo by to být rušení, ale to, že to ve windows funguje je divný. Jedině snad že by něco ve windows změnilo nastavení SSC (spread spektrum clocking, zhorší se kvalita signálu, ale sníží vyzařování do okolí), ale to je obvykle nastavení v UEFI. Jestli to v BIOSu máš, tak by bylo zajímavý to přepnout. Pak mají dále PCIe porty různé zpracování TX/RX signálu, některý zařízení mohou volitelně přijímat hodiny z desky nebo si je nezávisle generovat apod. Ale nevím zda se to dá lehko porovnat a nemyslím si, že by to systémy nastavovaly na jinou hodnoty než nejlepší. V linuxu by se to mělo zjistit pře lspci na nejvyšší detaily (čím víc -vvv tím víc adidas). Jinak je nutno porovnat kromě zařízení i bridge, například u mě:

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] (rev cf)

Na host bridge je napojenej 00:01.0 PCI bridge, kterej ovládá signály do grafiky (normálně jde přes setpci do toho PCI bridge přepnout rychlost nebo port odpojit i z shellu - ale je to hack). Některé bridge umí i nastavit sílu signálu (ale to je myslím nestandardizovaná věc).

Nechceš dát do toho adaptéru i jinou kartu ať víme zda je opravdu problém v adaptéru/kabelu?

BTW já bych teda ještě zkusil kabely omotat alobalem a nějakou izolací, je to levnější než novej adaptér, ale je to o ústa, aby to nevyzkratovalo celej počítač.

41:00.0 Multimedia video controller: Blackmagic Design DeckLink Mini Recorder 4K (rev ff) (prog-if ff)

a

[ 544.026915] dpc 0000:40:01.1:pcie010: DPC unmasked uncorrectable error detected, remove downstream devices

V téhle konfiguraci bude 40:1.1 asi bridge pro "Recorder" že?

P.S. Když ty karty prohodíš, která bude vypadávat, ta samá karta, nebo ta samá pozice na PCIe adaptéru?

[PetebLazar]

Podle lscpi -t 1.3 je Recorder a 1.1 Intesity (ve vypisu vyse byly chyby u obou). Pri prohozeni karet jestli si pamatuji vypadaval prave recorder co jede 2x2.Kanbely jsou jiz objednany, pokud nebudou mit dovolenou.inventuru tak vecer zkusim dalsi kolo pokusu. Nastaveni v UEFI jsem vcera prosel, je tam dve volby snizeni na Gen1/Gen2, ale asi se tykaji vsech linek CPU/X399. Manual k tomu mlci,

[PetebLazar]

Podle lscpi -t 1.3 je Recorder a 1.1 Intesity (ve vypisu vyse byly chyby u obou). Pri prohozeni karet jestli si pamatuji vypadaval prave recorder co jede 2x2.Kanbely jsou jiz objednany, pokud nebudou mit dovolenou/inventuru tak vecer zkusim dalsi kolo pokusu. Nastaveni v UEFI jsem vcera prosel, je tam dve volby snizeni na Gen1/Gen2, ale asi se tykaji vsech linek CPU/X399. Manual k tomu mlci,

[pc2005]

Podle specifikace (stránka 660) by mělo jít přinutit bridge, aby používal jen původní parametry linky (takže 2.5GT/s apod). Tohle se dá nastavit příkazem

setpci -s "bus:slot bridge" "0xXX hex adresa".w

Přičemž pozice bridge se dá zjistit z toho lspci tree a hex adresa je číslo v hranaté závorce (lspci -vvv), například:

	Capabilities: [a0] Express (v1) Root Port (Slot+), MSI 00

Součastí těchto capabilities musí být "Link Control 2"/"LnkCtl2". K hodnotě se přičte offset toho registru 0x30 a setpci by měl vypsat hodnotu. Když se pak změní požadované bity, tak se to pak dá zase zapsat zpět:

0xADDR.w=0xVAL

Předpokládám tedy, že pokud se nastaví nejnižší nibble na hodnotu "1", tak se bude přenášet jen gen1 rychlostí.

Linka se pak musí znovu natrénovat pomocí povelu přes bit 5 na offsetu 0x10 stejné bázové adresy jako má Link control 2 registr (registr se tentokrat jmenuje "link control"/"LnkCtl", stránka 640). Zase klasicky přečíst, změnit bit na "1" a zapsat zpátky.

Samozřejmostí je to, že s kartou nesmí nic pracovat a ani nesmí být načtený driver. Nevím ale co s tím udělá AER a DPC, měly by jít nějak vypnout.

Nebo alternativně: můžeš zkusit na chvíli snížit všechny linky a sledovat zda se to bude stále rušit .

[PetebLazar]

Karta při zachytávání přenáší do CPU ke zpracování uncompressed data, takže při 3840x2160p30 4:2:2 to vypadá na bandwith někde mezi 1-2 GB/s (to by se pouze při PCIe 2x 1.1 nepřeneslo a čtyři linky jsem u BM Recorderu neviděl nikdy aktivní).

U dodavatele to vypadá, že vyřizují objednávky Po-St-Pá, takže možná bude riser zítra (nebo po Novém roce). Další risery na trhu mají dost vysoký konektor(tišták) do slotu, u nich mám obavu o kolizi s chladičem ASUS Strix.

[PetebLazar]

Tak jsem udělal něco, do čeho se mi moc nechtělo. Přeházel jsem pořadí grafik tak, aby se 2,5slotový STRIX ocitl na okraji MB (u PSU). Tím jsem se zbavil závislosti na riseru ze slotu PCIe8x a mohl jej přímo osazovat BM kartami. Chování je stejné, v dmesg se objevují u obou karet stejné chyby. V UEFI je mj. volba vypnutí AER. Tak ho zkusím vypnout jestli to funkci karty nějak ovlivní. S Intensity 4K jde normálně zachytávat 1080p60 bez ztráty frame.

[  153.663536] pcieport 0000:40:01.3: AER: Multiple Corrected error received: 0000:00:00.0
[  153.663562] pcieport 0000:40:01.3: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[  153.663567] pcieport 0000:40:01.3:   device [1022:1453] error status/mask=000010c0/00006000
[  153.663572] pcieport 0000:40:01.3:    [ 6] BadTLP                
[  153.663575] pcieport 0000:40:01.3:    [ 7] BadDLLP               
[  153.663578] pcieport 0000:40:01.3:    [12] Timeout   

Asi je to nějaký bug Tr platformy.

[pc2005]

[  153.663572] pcieport 0000:40:01.3:    [ 6] BadTLP                
[  153.663575] pcieport 0000:40:01.3:    [ 7] BadDLLP           

Jo prostě poškozené pakety...

Ale psal jsi, že ve windows při stejné konfiguraci to nepadalo ne? To by pak nemohlo být hardwarem.

[dustin]

O PCIe nevím skoro nic, ale nemohou windows zapnout nějaký jiný režim (třeba nějak s podporou opravy chyb), který má spolehlivější přenos?

[pc2005]

No na fyzické úrovni moc parametrů není. Jenom rychlost, počet linek, deemfáze, délka trénovací sekvence. A většina toho se nastaví jako univerzální default. Věci jako: SSC, terminátory budou záležitost implementace konkrétního výrobce.

Ještě mě napadá, že windows nemusí podporovat DPC a AER a mít je vypnuté (ty jednotlivé eventy jdou samozřejmě maskovat přes standardní rozhraní), takže to pak v případě chyby nebude odpojovat kartu, ale neodstraní to ten samotný problém poškození dat.

[PetebLazar]

Ano ve Windows mi obě BM karty zachytávaly současně (1080p60 a 2160p30), bez zjevných potíží.

Ta chyba se v konferencích zmiňuje i pro platformu X99. Jedno z vysvětlení je využívání přístupu k PCIe zařízením pomocí memmory mappingu (selhávajícího v té konkrétní situaci) místo tradičního přístupu přes porty. Možná Windows využívají právě ten tradiční. Zkusím odpoledne volbu pci=nommconf kernelu zda se to projeví na chování v Linuxu.

[pc2005]

Pošli link na nějakou konferenci.

Je sice možné, že mmconfig je zabugovanej (holt ACPI), ale to, že nejede by nemělo mít vliv na zachytávání kartou. Hlavně mmconfig je součástí čipsetů už od PCIe (možná dřív) a bez něj nebude mít OS přístup k té novější oblasti (původní PCI měly 256 bajtů konfigurační prostor, PCIe mají 4096B prostor)... vlastně když nad tím přemýšlím, tak by to mohlo pomoct!

Nastavení AER (a asi i DPC) je v tom novějším prostoru a pokud jsem na svým i945 kompu zakázal mmconfig, tak ta volba jaksi nebyla vidět (protože portovej přístup umí jen 256B). A když není vidět, tak ani nejde používat a je disablovanej. A tak se logicky nebude odpojovat karta při chybě.

Akorát se tím teda připravíš o všechny další funkce z 4096B prostoru. Možná i MSI. Zkusil bych to, ale pokud to pojede, tak bych se snažil zakázat přímo jen ten AER a DPC. A zakaž to ideálně i v BIOSu.

P.S. Je to jen zametení pod koberec, ty chyby přenosu, pokud tam opravdu jsou, se tím neodstraní.

[PetebLazar]

Dodavatel riseru oznámil na stránkách uzavření do 6.1.2019 pro nemoc, takže budu zkoušet neriserované varianty.

AER jsem již zkoušel individuálně zakázat, bez pozitivního výsledku.

Také zkusím zrušit IOMMU/VFIO u dvou z tří osazených GK, abych vyloučil jeho vliv. Ve Windows neni IOMMU aktivní.

Zkusím ve slotu nějakou jinou kartu, abych vyloučil fyzickou chybu (konektor).

Odkazy s vyskytem chyb v hlaseni https://patchwork.kernel.org/patch/10112467/ https://forum.level1techs.com/t/threadripper-pcie-bus-errors/118977 https://ahelpme.com/tag/pcie-bus-error/ https://patchwork.kernel.org/patch/10058853/

[pc2005]

Ta oprava DPC přerušení by už měla bejt tak rok v kernelu, od verze 4.16. Ale jo obojí bych to zakázal, DPC je nová součást PCIe (abych pravdu řekl, tak jsem doteď nevěděl že existuje) a není vyžadovaná.

[pc2005]

Kdyžtak zkus boot s parametry "pci=noaer" (nevím zda se sdružuje nebo přepisuje víc záznamů pro pci=, kdyžtak oddělit čárkou) a možná "pcie_ports=compat".

[PetebLazar]

Nejlepších výsledků v Linuxu dosahuji s parametrem kernelu pcie_aspm=off. Hlášení v dmesg zmizí, karta je viditelná pro programy. Při zachytávání 2160p30 jsem dosáhl těchto výsledků:

Grabováno vždy cca 13 minut z výstupu GK.

Linux: cíl SSD A-DATA S900 (ztráta cca 106 snímků z cca 23000)

Linux: cíl NVMe Corsair MP500 (ztráta cca 66 snímků z cca 23000)

Windows: cíl NVMe Samsung EVO 960 (ztráta 0 snímků z cca 23000)

Ztracený snímek se projeví tím, že je do videa vložen černý obraz. Analýza ztracených snímků je prováděna konverzí zachyceného AVI do jednotlivých .jpg a spočítání velmi malých snímků (regulérní obraz cca 300KB, černý snímek 60kB).

Na Windows grabovací karta ukazuje 2160p30 při výstupu 2160p30, Linuxu je to 2160p29,97 při výstupu 2160p30. Tak si říkám zda ke ztrátě nemůže dojít v rozdílném časování/očekávání. Pokusy jsem prováděl ve vanilla 4.19.12, ještě to zkusím ještě v generic 4.15.

[dustin]

Ty rozdílné frekvence budou asi dost zásadní důvod, windowsí driver tu kartu zřejmě nakonfiguruje trochu jinak.

[pc2005]

Jo časování by taky mohlo dělat problém.

[PetebLazar]

Tak jsem zkusil výstup z NTB (HDMI 1.4), takže zvládne 2160p30 (výstup z RGB změnen na YCbCr), MediaExpress v Linuxu stejně vidí vstup jako 2160p29,98.

Teď zkouším jinou cestu. Pro Blackmagic Davinci Resolve 15.2 existuje instalační médium včetně CentOS7.3 (na něm a na RHEL7.3 jsou BM produkty asi primárně na Linux platformě podprovány). To médium je mírně agresivní, požaduje odpojení všech storage, kromě té na kterou se má instalovat. To se snadněji napíše, než prakticky provede při osazení 3xSSD,2xHDD,2xNVMe.

Tak po zhlédnutí varování jsem raději instalaci spustil v rámci VirtualBoxu 6.0 a až se dokončí převedu .vdi na .img a ten ddckem plácnu na vyhrazený SSD. Z něj by pak nemělo být problém do CentOS7.3_Davinci nabootovat. Druhou otázkou je co Tr/X399 předvede na tak historickém kernelu/distribuci.

[dustin]

Není na ten hardware/driver nějaký specializovaný mailinglist? Někdo ten hw musí znát.

[PetebLazar]

Už vstup na jejich stránky působí na bežného člověka (asi i entusiastu) relativně zastrašujícím dojmem (a to ještě neviděl ceny). https://www.blackmagicdesign.com/products/davinciresolve/ Jestli jsem to správně pochopil, tak své produkty orientované na profesionální sféru podporují dlouhodobě na Windows a MacOS. Relativně nedávno k tomu přidali i Linux (jejich DaVinci Resolve je po registraci zdarma) a s ohledem na jejich typického zákazníka dává orientantace na RHEL(CentOS) vcelku smysl. Většinou půjde o specializovaná pracoviště, která s ohledem na míru investic asi budou provádět jedinou činnost (postprodukci atd). Využití mimo tento rámec by asi bylo mrháním investic, takže nějaké případné omezení plynoucí z použití starších enterprise distribucí nebude problém. Jak Davinci Resolve(Studio) je close source (moduly se překládájí při instalaci), ale pokud budou funkčními říkám si proč ne. Mají své fórum, ale tam je zatím Linux-oriented příspěvků relativně málo (gró uživatelů je na jiných platformách).

[dustin]

A ptal ses na tom fóru? Klidně v linuxovém driveru mohou mít chybu.

[PetebLazar]

To bych se musel registrovat a nebyl by to takovy challenge! Oni si asi budou urovne podpory vedomi, posledni dve verze SW jsou prvni, kde se objevilo mezi overovanymi distro Ubuntu 18.04. Mozna ted, kdyz jsem si overil funkcnost HW v CentOSu tam neco sesmolim.

Ad RTFM) v ReadMe.txt,ktere je u ovladacu (obecne pro vice HW) zminuji volbu pcie_aspm=off nutnou pro nektere PCIe1x karty.

Tento prispevek pisi z CentOS7.3, ve kterem probehlo cca 20 minut zachytavani 2160p30 bez znatelneho vypadku (na pozadi se OS pritom aktualizuje a to vse bez jakychkoli hlasek v dmesg), uvidim jestli to prezilo update. Tak asi neco na te deklarovane podpore RHEL/CentOS preci jen bude.

[PetebLazar]

Dalsi zajimavy poznatek. Po update CentOS 7.3 z puvodniho jadra vmlinuz-3.10.0-514.el7.x86_64 na aktualni vmlinuz-3.10.0-957.1.3.el7.x86_64 se zacaly v dmesg objevovat stejna hlaseni o chybach. Vypada to na vliv nejake backportovane funkcionality/zmeny (spolecne s dnesnim kernelem). Vyzkousim vliv pcie_aspm=off na aktualizovany kernel.

[PetebLazar]

Jakmile se CentOS 7.3 zaktualizuje o dosazenou funkcnost se prijde, nelze prelozit jeden z modulu (blackmagic-io). Pry to ma byt napraveno v dalsich verzich ovladacu. https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=83771

Na sve distribuci Xubuntu 18.04 vyzkousim opacny pristup, jit naproti ovladacum downgradem kernelu.

[pc2005]

Vždycky můžeš zkusit git bisection, ale trvá to teda pěkně dlouho.

[PetebLazar]

Git-bisect, to uz je prilis vyssi divci. Navic si to ani nedovedu predstavit mezi 3.10 a 4.19.12.

S downgradem kernelu jsem neuspel, mozna jsou do poslednich LTS verzi na kernel.org backportovane nejake zmeny/features.

Na drive zminenem CentOS 7.3 (DaVinci edice) jsem docilil bezchybneho zachytavani 2160p30 a 1080p obema kartami (Intesity v PCIe8x, Recorder v M.2). Chyby na sbernici se vyskytovaly, ale spise s odstupem desitek sekund nez rychlosti 100/s.

Zdrojem pro vstup 2160p byl dalsi vystup GK, 1080p jsem nakrmil externe z r-PI 3B+. Vice asi rekne screenshot porizeny pri snimani. Vypsal jsem lspci pro obe karty, chci jej srovnat s lspci v Xubuntu 18.04 (zda se karty lisi rezimem/nastavenim).

Screenshot 12MB

Pozn. Pokus vyse probehl bez pcie_aspm=off v GRUBu!

[PetebLazar]

Včera se mi pokusy (volby v UEFI) podařilo počítač dostat až do stavu, kdy nereagoval ani na pokus o vstup do BIOSu/UEFI. Pomohlo tlačítko vymazání CMOS. Asi je nejvyšší čas s pokusy přestat.

Zjištění:

Nepotrdila se doměnka, že problém může spočívat v rozdílném časování (při posledním testu pod CentOS kombinace GK:2160p30 a BM:2160p29,87 nevypadl ani jediný ze 120000 snimků).

Jak Windows 10 tak CentOS 7.3 (původní neupdatovaný kernel) jsou schopny spolehlivé práce s oběma BM kartami současně (chybová hlášení jsou v dmesg X000x méně).

Současné kernely toho schopny nejsou, určité parametry (noaer,nommconf,pcie_aspm,nomsi) kernelu sice zabrání zobrazování hlášek v dmesg, ale funkčnost nezajistí.

Doměnky:

Funkčnost staršího kernelu by evokovala použití starších přístupů (případně ignorování specifik relativně čerstvé architektury TR/X399).

HW (PCIe controller, PCIe karta, redukce) či jeho obsluha produkuje chyby s nimiž se moderní kernel nevypořádá.

Závěr/řešení:

Přechod z aktuálního Xubuntu 18.04 na CentOS 7.3 s ohledem na požadavek rozpětí funkčnosti HostOSu není proveditelný.

Doufat ve změnu chování při využití bifurcation PCIe8x na PCIe4x+PCIe4x?

Čekat na vyřešení problémů v kernelu/BIOSu/SW/ovladačích?

Přesunout funkčnost zachytávání na zcela jiný stroj s vhodným OS/SW?

Nahradit PCIe Recorder 4K vhodnou USB (UVC) náhradou (možná Elgato Cam Link 4K až se objeví v ČR)?

Děkuji všem zúčastěným za jejich příspěvky k tématu.

Minimum chybových hlášek v dmesg přeje (kromě těch nepodstatných věcí jako zdraví, štěstí a úspěch) v roce 2019 PetebLazar

[pc2005]

Včera se mi pokusy (volby v UEFI) podařilo počítač dostat až do stavu, kdy nereagoval ani na pokus o vstup do BIOSu/UEFI. Pomohlo tlačítko vymazání CMOS. Asi je nejvyšší čas s pokusy přestat.

To je normální .

Přechod z aktuálního Xubuntu 18.04 na CentOS 7.3 s ohledem na požadavek rozpětí funkčnosti HostOSu není proveditelný.

Jsou k dispozici i verze jader mezi 3.10 a dneškem? Tipoval bych, že tak 4.10 ještě podporu threadripperu neměl. Okolo kernelu 4.14 se myslím objevil meltdown a spectre.

Doufat ve změnu chování při využití bifurcation PCIe8x na PCIe4x+PCIe4x?

Teďka tam není riser a všechny karty jsou na minimálně x4?

Čekat na vyřešení problémů v kernelu/BIOSu/SW/ovladačích?

Teď tam je nejnovější UEFI?

Přesunout funkčnost zachytávání na zcela jiný stroj s vhodným OS/SW?

Jestli to je fakt problém desky/TR, tak by to mělo jít reklamovat, třeba máš prostě jen vadný kus. Nepředpokládám, že výstupní kontrola testuje takhle komplexní použití .

No hlavně bych ten problém nahlásil na fóru výrobce těch karet a možná se poptal i v nějaké diskuzi o kernelu jestli neví nějaké problémy s TR.

Minimum chybových hlášek v dmesg přeje (kromě těch nepodstatných věcí jako zdraví, štěstí a úspěch) v roce 2019 PetebLazar

Přeju taky, hodně nagrabovaných videí bez výpadků .

[PetebLazar]

To je normální To jo, ale když je tlačítko spolehlivě zakryto 2,5slotovou GK tak to otráví.

Jsou k dispozici i verze jader mezi 3.10 a dneškem? Nevím zda je někde detalni mirror archivu kernelu CentOSu, ale níže než CentOS 7.5 (6/2018) jsou verze jiz deprecated. Pokud by byla jemnejsi rada mohly by se metodou puleni intervalu najit dve verze mezi nimiz by to prestalo fungovat (z changelogu/src pak by se slo asi neceho dopatrat).

Teďka tam není riser a všechny karty jsou na minimálně x4? Teď je Recorder 4K v NVMe-PCIe4x redukci a Intensity 4K v PCIe8x slotu (bez riser kabelu). Ten Recorder má mít TDP jen 7W a vede k němu jen 1x HDMI(SDI nevyužívám) tak jsem mu dal M.2. Ta Intensity může sloužit i jako náhled (má dva HDMI a Canon na analog in/out a TDP 17W) té je lépe v PCIe slotu.

Teď tam je nejnovější UEFI? Ano je tam poslední dostupná verze ze stránek výrobce.

Jestli to je fakt problém desky/TR, tak by to mělo jít reklamovat, třeba máš prostě jen vadný kus. Ta chyba se ukazuje napříč X399 platformou u různých výrobců, takže bych to na nahodilou chybu neviděl (spíše systematickou). Když se holt věci využívají na hranici specifikací problémy vyplavou.

P.S. Jsou nějaké rozdíly v lspci -vvv na 3.10 vs na aktuálním jádru? Tady jsou výpisy z CentOSu(bez par. v GRUBu) a Xubuntu (s pci=nommconf). Rozdíly tam jsou. https://www.monitos.cz/tmp/BM_info.tar.gz

Vypadá to, že obě karty mají stejný MSI vektor. Nevyplývá z těch výpisů, že MSI je v Xubuntu vypnuto (důsledek parm. v GRUBu)?

Zajímavý Intensity pro 4K umí jen PCIe gen1? Je to možné. Žádné pokročilé metody komprese on-board si vědom nejsem, vzhledem k zátěži CPU bych tipoval, že M-Jpeg a ost. se encodují až v rámci CPU.

P.S. Tohle téma již přešlapuje na místě a tak mne napadá založení dalšího "Zkušenosti se sdílením(přepínáním) passthrough device mezi HostOS a GuestOS". Nejspíš asi opět sem do HW sekce, ne? Co si vzpomínám, tak v době pci_stub to vcelku šlo, nevím jaká je dnes situace s vfio_pci. Dosud jsem byl smířený s vyhrazením silnější karty pro GuestOS(Win10), ale v současné době se Steam/Proton + Davinci Resolve bych pro mi měl spoustu práce v HostOSu(Linuxu). Druhá Geforce (GTX960) je dnes již na 3D relativně slabá. Mám sice i GuestOS(Xubuntu), ale provozovat pod Linuxem virtuálně Linux s hlavní funkcí Steam/Proton(DX11->VK) by již mohlo zavánět rozmarem.

[LarryL]

Čau, na desktopu je přehazování passthrough device mezi HostOS a GuestOS celkem easy. Alespoň tedy v mém případě Intelu a Nvidie. Někde jsem o tom psal kratičký příspěvek na rootu, ale otázka je, jak to bude u tebe, protože ty máš pořád nějaké problémy. Myslím to v legraci Mít nabušený počítač grabovacíma kartama, jako máš ty, už je jiný level než jen přehazovat jednu GPU. Každopádně jak to tak čtu v různých diskuzích včetně této tvojí, tak začínám mít z Ryzenů a Threadripperů pro passthrough trochu strach. Pořád se někde dočítám o sekání/latenci - poslední třeba zde https://www.reddit.com/r/VFIO/comments/a9jsap/dpc_latency_spikeshigh_latency_in_windows_10_vm/

Chtěl jsem v budoucnu vyhodit Intel a koupit Ryzen, ale možná chce AMD ještě nějaký čas, aby dozrálo.

Zkus prozkoumat tento bug https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1771238 . Týká se sice KVM, ale nápadně to připomíná tvoje popisované problémy "DPC unmasked uncorrectable error detected, remove downstream devices". Je tam i vyjádření Alexe Williamsona.

Já jsem tuhle diskuzi jen zběžně přeletěl, takže sorry jestli řeknu kravinu, ale chápu to tak, že "Downstream Port Containment" je volitelná funkce HW, která kontroluje neopravitelné chyby na PCIE. Tato funkce má svůj ovladač, který v případě neopravitelných chyb odpojí dané zařízení. A podle té rady Alexe to chápu tak, že ovladač(modul) DPC se může pro konkrétní zařízení vypnout což by možná tvůj problém vyřešilo.

Ještě jednou sorry jestli jsem v lehké silvestrovské opilosti napsal kravinu. Vše dobré do Nového roku.

[pc2005]

Tady jsou výpisy z CentOSu(bez par. v GRUBu) a Xubuntu (s pci=nommconf). Rozdíly tam jsou. https://www.monitos.cz/tmp/BM_info.tar.gz

Buď u xubuntu výpisu umřela "Blackmagic Design DeckLink Mini Recorder 4K" už před vypsáním jejího infa, nebo je její inicializace zabugovaná (nepoužívá MSI, má vypnuté reakce na IO/MEM requesty, prostě defaultní hodnoty po power downu, vlastně i "MaxPayload 128 bytes" je myslím defaultní hodnota, v centosu je 512). U druhé karty "Blackmagic Design Intensity Pro 4K" je v xubuntu povolený ASPM (v centosu je vypnutý).

pci=nommconf

Device Serial Number 00-00-00-01-01-00-0a-35

Zajímavý, že obě karty mají stejné sériové číslo, aby to nedělalo problém v driveru/udevu, nommconf ale to číslo v xubuntu "skryje" (vidí jen centos). Jiné věci při nommconf nemají pro samotné karty význam (ale mohou mít význam/měnit nastavení u bridgů nebo root complexu, nevím není log).

Nevyplývá z těch výpisů, že MSI je v Xubuntu vypnuto (důsledek parm. v GRUBu)

Ta fotka byla z centosu ne? Tam se MSI používá ("MSI: Enable+").

a tak mne napadá založení dalšího

No jestli chceš, ale pokud budou ty karty v xubuntu vypadávat, tak nemá IMO smysl nad tím stavět komplikovanější nadstavbu. Jinak s passthrough PCI nemám zkušenosti, žádný můj hardware to nepodporuje (jestli to je VT-d).

[PetebLazar]

Ano, screenshot je z CentOS 7.3.

Zatím to dám k ledu, až se v lednu objeví ta PCIe16x=4xNVMe karta tak zkusim obe pripojene na ten PCIe8x slot.

Zkoušel jsem volby Gen1/Gen2 u PCIe v UEFI, ale nevypadalo to že by se tim Linux řídil. Některé GK jely stále 8GT/s.

Díky za odpovědi.

[PetebLazar]

Ještě mne napadla jeden důvod, vzhledem k tomu že karta zmizí až po čase (teplotní závislost). Přeci jen obklopena GK to asi nemá lehké. Umístil jsem nad BM karty rychlé 2x70mm, ale pozitivního výsledku. Nakonec ve Windows a CentOSu to beželo stabilně a tam teplotní poměry asi nebudou moc odlišné.

[PetebLazar]

V průběhu ledna dorazila PCIe16x=>4xNVMe karta, ale k pokusům jsem se dostal až nyní. Bohužel její připojení přes riser kabel (a ani přímo) a doplnění o adaptér NVMe=>PCIe4x slot nevedlo k úspěchu. Karta Blackmagic PCIe4x vložená do redukce PCIe4x->NVMe (pomocné napájení zajiště přes floppy 4pin) se v lspci neobjevila. Při zapojení BM karty přímo do riser 16x=16x kabelu ano. Pokusy vzhledem k potenciálnímu riziku proběhly na obětovatelném PCm (socket FM2?). Holt někdy vyfukováním tabákového kouře do výlevky umyvadla zlato nevznikne.

[pc2005]

Ten socket FM2 umí tu bifurkaci taky?

[PetebLazar]

Podle voleb co jsem našel to neumí. Prvotně jsem testoval jen ten první NVMe slot na kartě (v PCIe 4x slotu zmíněného MB). Při zapojení pouze ve daném slotu pouze přes riser kabel byla BM karta v lspci vidět.

[pc2005]

Jo tak to nebude umět, bez bifurkace pojede jen ten první slot. Ale ve stroji s bifurkací by to mělo jet OK.

[PetebLazar]

Jak jsem psal vyse, BM karta videt nebyla. Nekdy vyzkousim v te karte samotne NVMe az se mi nejake volne dostane do ruky (pro nez je nakonec urcena). Nejspis je tech redukci uz prilis. Ale co, prijdou nove EPYCy/TRy a tak se prinejhorsim IO zatez rozdeli mezi vice stroju. Diky za pomoc a podporu.

[pc2005]

Screenshot 12MB

Zajímavý Intensity pro 4K umí jen PCIe gen1? To znamená, že na x2 slotu nebude stíhat 4K raw YUV (nebo to karta rovnou enkóduje do mpeg/h26x ?).

Vypadá to, že obě karty mají stejný MSI vektor. To mě přijde divný. U MSI máš k dispozici 65536 identifikačních hodnot a ještě různé adresy, na které se ty hodnoty zapisujou. Není důvod, aby se MSI sdílelo a obzvlášť u zařízení s tak velkým datovým tokem. Hoď sem výpis /proc/interrupts.

Proč je v dmesgu tolik hlášek od iwlwifi, že linka není ready?

Hmm kernel 3.10 je fakt starej. A změn do dneška bylo fakt dost hodně. I když asi by stačilo omezit bisect jen na PCI/irq/bios kód.

[pc2005]

P.S. Jsou nějaké rozdíly v lspci -vvv na 3.10 vs na aktuálním jádru? Například ty adresy MSI, ale i flagy, jak je ten PCIe port nastavenej. (Porovnání dumpnutejch texťáků třeba meld.)

[pc2005]

Tak mě napadá, jakej je bitrate toho 2160p30? Budou to ty SSD vůbec stíhat? Raw YUV bude mít IMO tak 500MBps, což bych u něčeho, co se jmenuje A-DATA moc neočekával. U toho SSD to bude dost možná na hranici rychlosti SATA gen3. Navíc bych se nedivil, kdyby ten SATA řadič byl připojen něčím jako PCIe x1 gen2 (nebo x2 gen1), což by taky +- odpovídalo. Ten corsair by to stíhat měl, pokud teda jede na plných PCIe x4 gen3. Ale pokud měření přes dd bude vypisovat víc, tak je chyba asi jinde no.

Druhá možnost je samozřejmě ta, že se PCIe host/device snaží o nějakej replay transakce a sežere mu to bandwidth.

Takže když jsi vypnul AER a DPC, tak to chyby do logu nepsalo, ale snímky vypadávaly že? U "pcie_aspm=off" je AER nebo DPC zapnutý? Pokud jo, tak by se ty replaye měly hlásit.

[PetebLazar]

Na disk při 2160p30 jde .avi (M-Jpeg) tj. cca 50MB/s, S tím by snad nemělo mít problém žádné SSD (ani ty nepovedené). SATA je součástí chipsetu X399 (připojeným přes PCIe4x3.0 k CPU). Přikláněl bych se k druhé zmíněné variantě, uprostřed delšího přenosu dojde k chybě a na opakování není čas(data). AER v UEFI je, DPC jsem nenašel. Zkusím tu variantu jen s vypnutým AER.

[PetebLazar]

S vypnutým AES jsou chyby zpět, zachytávání trvale vypadává. Zkusil jsem si odskočit do Win10, tam to běží OK (za 20 minut zachytávání ani jediný ztracený snímek). Zkusím nakrmit v Linuxu kartu HDMI z jiného zdroje mtb Intel GPU/Win10 (třeba bude časování lepší).

[frr]

IOporty? Specifikum platformy x86, obecně delší dobu "deprecated". Obecně pokud nějaký hardware na PCI umí PIO i MMIO, tak mi vždycky fungovalo buď oboje nebo nic. Kromě toho přenosy těch gigabajtů za sekundu pojedou zcela jistě přes DMA, což podle mého znamená přímo do RAM hostitelského stroje, bez nějakého mapovaného "okna" na periferii (ať už MMIO nebo PIO) pro samotný payload. Tzn. mapovaná do MMIO/PIO oken bude především konfigurace (nad rámec PCI config space).

Že nějaké faktické chyby nebudou pod Windows vidět, to mě nepřekvapuje. Proto používám k testování hardwaru raději Linux.

Ten nápad s vypnutím IOMMU určitě stojí za vyzkoušení, ale pokud se IOMMU přenosy netýkají přímo těchto speciálních periferií, tak jsem trochu skeptický, že by to mělo vliv.

[frr]

Ještě obecně pokud zápasíte s nedostatkem slotů, tak kromě nějaké mlsnější ATX desky třeba od Supermicra se dá pořídit taky PICMG 1.3 sestava se zajímavým počtem slotů. Napadá mě tenhle backplane (v manuálu je blokové schéma) a do něj třeba PCA-7129 nebo PCA-7131 CPU karta. Asi bych úplně nehrotil v tomhle formátu dual Xeon E5, prostorově a tepelně to není moc důstojné. Ano je to s vysokohorskou přirážkou, protože "industrial".[/reklama]

[PetebLazar]

Jestli by nevyšlo levněji vzít tohle kombo.

https://www.smicro.cz/supermicro-h11ssl-i-b-16891.html

https://www.alza.cz/amd-epyc-7301-levne-d5441317.htm?o=1

[frr]

Určitě vyšlo. Já měl jenom pocit, že zápasíte s nedostatkem PCI-e slotů. Proto jsem zmínil PICMG sestavy.

(A jak jsem pochopil z jiné větve této debaty, problém s výpadky frejmů je možná někde jinde, než v PCIe sběrnici.)

Každopádně palec nahoru za výživnou debatu.

[pc2005]

IOporty? Specifikum platformy x86, obecně delší dobu "deprecated".

Ono to bylo dost zmatečně popsané. Tím se (nejspíš) myslel přístup na PCI config space. Původně to bylo přes IOport 0xCF8, ale pak přestaly stačit registry a tak se to šouplo jako paměťově mapovaný registr, jehož adresu předává ACPI a je obvykle něco jako 0xff123400. Tím že se přikáže používat pomocí "pci=nommconf" jen původní mechanismus přes IOport 0xCF8, tak se OS nedostane ke funkci AER a DPC a nepoužívá je.

[dustin]

Zajímavá diskuse, málokdy se člověk setkává s takto low-level znalostmi. Díky všem za poučení!

[pc2005]

No protože jsem se v tom celý podzim vrtal

[frr]

I já děkuji za podrobnosti v kostce

[PetebLazar]

Pokud je Recorder 4K v riserovanem slotu 8x, daří se bezchybně zachytávat 2160p30(maximum karty). V redukci M.2_PCIe4x to hlásí jen využití dvou PCIe linek a karta se po čase ztratí (zajímavé, že ve Windows to fungovalo spolehlivě dle HWINFO se dvěma linkami i v M2 slotu s druhou BM v riseru). Jediná vědomá změna kde zlepšení chování Recorder 4K v Linuxu bylo vypnutí irqpoll v kernelu. Uvidíme zda při splitované 8x se chování změní. Hezké svátky všem.

[PetebLazar]

Zapoměl jsem připojit screenshot BIOSu, ukázka voleb u jednoho z PCIe8x. http://www.monitos.cz/tmp/x399_taichi_bios_3.2_pcie_bifurcation.png

Předchozí verze BIOSu 2.0 co jsem používal to rozdělení měla snad jen pro jeden PCIe16x slot (nyní pro všechny 16x,8x), tak snad to má reálný (funkční) základ.