Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - farbydos2

Stran: [1] 2 3 ... 7
1
Ukázalo se, že chyba je na mé straně. Patrně se v jádře linux-image-6.12.35+deb13-amd64 rozbily některé funkce vfio modulu. Oprava přichází s jádrem  linux-image-6.12.40+deb13-amd64. Upgrade jádra doopravdy problém řeší. GPU fungují v hostovaných systémech opět bez problému.

Zdroj: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109676 a případně dále: https://www.debian.org/releases/trixie/release-notes/issues.cs.html

2
Ahoj, o víkendu jsem standardní cestou aktualizoval server z Debianu Bookworm na Trixie. Slouží mimo jiné jako hostitelský systém pro virtualizaci. Celý ugrade systému proběhl podle očekávání dobře. Problém je ale s GPU Passthrough v KVM. Na serveru jsou hostované 4 CAD stanice s grafickými kartami NVidia (různé generace, nejnovější je Ampere RTX A4000). Ve všech stanicích po aktualizaci hlásí ovladač grafiky nespecifickou chybu 43. Před upgradem fungovaly všechny VM bez problému. Začaly mi docházet nápady; napíši, co jsem zkoušel. Třeba vás něco napadne. Jádro je 6.12.38+deb13-amd64.

Ještě doplním, že jsem prošel fóra Proxmox a návody k Proxmox pro GPU passthrough, kde se diskutovala řešení k chybě 43 ovladačů NVidia. Nenašel jsem žádné funkční řešení.

  • Na serveru je blacklist na nvidia i nouveau ovladače. Pro jiné účely než pro VM grafiky nepotřebuji, takže se dosud používal paušální blacklist ovladačů v /etc/modprobe/.
  • Zkoušel jsem aktualizovat ovladače na stancích. Bez rozdílu.
  • Dmesg nehlásí žádné chyby. Při startu VM přes virt-manager je v dmesg vidět přiřazení vfio modulu k příslušné grafice. Tento stav lze potvrdit i lspci.
  • Pro jistotu jsem vyhradil zvolené grafické adaptéry pro vfio pomocí direktivy v cmdline vfio-pci.ids=<gpu>,...
  • Dále je v grub cmdline podpora iommu: intel_iommu=on iommu=pt. Ze systému lze ověřit, že iommu je aktivní (viz níže).
  • VM s Windows 11 i Windows 10 se chovají identicky. Můžu ještě zkusit Windows Server.
  • Na všech stanicích jsou použity některé volby Hyper-V Enlightenments. Dříve s během GPU neinterferovaly a nepřijde mi, že jde o zdroj problému.
  • Na testovací stanici jsem do definičního xml přidal vendor id, ale nemělo to žádný dopad.
  • Chvilku jsem podezříval, jestli za problémy nemůže během update doinstalovaný balíček firmware-nvidia-graphics. Jeho odebrání nemělo vliv.
  • Samozřejmě jsem zkusil i cold boot serveru.
  • Zvláštní je, že se doopravdy zdá, že došlo ke kvalitativní změně chování grafik v hostovaných systémech bezprostředně po upgrade.
  • Ještě několik specifik VM: používají virtio ovladače pro disková zařízení, net-kvm atp. Skutečnost, že jde o virtualizované stroje nebyla nijak skryta (navíc v kombinaci s enlightenments). Samotná VM nebyla během upgrade Debianu aktualizována.

Pro příklad posílám vybranou část z výpisu lspci -vnn na testovací GPU
Kód: [Vybrat]
82:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM206GL [Quadro M2000] [10de:1430] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Dell Device [1028:1190]
Flags: fast devsel, IRQ 118, NUMA node 1, IOMMU group 4
Memory at c8000000 (32-bit, non-prefetchable) [disabled] [size=16M]
Memory at 3ffe0000000 (64-bit, prefetchable) [disabled] [size=256M]
Memory at 3fff0000000 (64-bit, prefetchable) [disabled] [size=32M]
I/O ports at 8000 [size=128]
Expansion ROM at c9080000 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Legacy Endpoint, IntMsgNum 0
Capabilities: [100] Virtual Channel
Capabilities: [250] Latency Tolerance Reporting
Capabilities: [258] L1 PM Substates
Capabilities: [128] Power Budgeting <?>
Capabilities: [420] Advanced Error Reporting
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
Capabilities: [900] Secondary PCI Express
Kernel driver in use: vfio-pci
Kernel modules: nouveau

Kód: [Vybrat]
sudo dmesg | grep -e DMAR -e IOMMU
[    0.008623] ACPI: DMAR 0x000000007BAFE000 0000E8 (v01 DELL   PE_SC3   00000001 DELL 00000001)
[    0.008649] ACPI: Reserving DMAR table memory at [mem 0x7bafe000-0x7bafe0e7]
[    0.032836] DMAR: IOMMU enabled
[    0.100221] DMAR: Host address width 46
[    0.100222] DMAR: DRHD base: 0x000000fbffc000 flags: 0x0
[    0.100229] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap 8d2078c106f0466 ecap f020df
[    0.100232] DMAR: DRHD base: 0x000000c7ffc000 flags: 0x1
[    0.100235] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap 8d2078c106f0466 ecap f020df
[    0.100237] DMAR: RMRR base: 0x0000007ae07000 end: 0x0000007af06fff
[    0.100239] DMAR: ATSR flags: 0x0
[    0.100240] DMAR: ATSR flags: 0x0
[    0.100242] DMAR-IR: IOAPIC id 10 under DRHD base  0xfbffc000 IOMMU 0
[    0.100244] DMAR-IR: IOAPIC id 8 under DRHD base  0xc7ffc000 IOMMU 1
[    0.100245] DMAR-IR: IOAPIC id 9 under DRHD base  0xc7ffc000 IOMMU 1
[    0.100247] DMAR-IR: HPET id 0 under DRHD base 0xc7ffc000
[    0.100248] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit.
[    0.100249] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the BIOS setting.
[    0.100926] DMAR-IR: Enabled IRQ remapping in xapic mode
[    0.478167] DMAR: No SATC found
[    0.478170] DMAR: dmar0: Using Queued invalidation
[    0.478174] DMAR: dmar1: Using Queued invalidation
[    0.488928] DMAR: Intel(R) Virtualization Technology for Directed I/O

3
Distribuce / Re:Konfigurace Samba v Ubuntu
« kdy: 02. 12. 2024, 09:59:41 »
(...)
Jediné, co mě napadá, že by se tam ztrácely multicasty. Ale pak zas proč, UFW firewall má podle předchozích postů vypnutý, ale i kdyby běžel, tak na MDNS i Sambu je tam ve výchozím stavu výjímka. HW filtrace by taky byla vcelku úsilí, pokud člověk nemá nějaký pokročilejší switch. Na obyčejném switchi nebo SOHO routeru je celý LAN segment jedna L2 síť. WiFina je s tím také v jednom bridgi, pokud nepoužiješ nějaký speciální režim hostovské WiFi, co tě komplet odizoluje od zbytku (pak by ale neprocházel ani ping)... nevím.

To je vlastně dost dobrá poznámka. Pro kabelovou síť by to tak mělo fungovat, ale pro přenos multicastu přes WiFi existuje řada optimalizací nebo naopak omezení, které někdy komunikaci rozbíjí. Všechny počítače, na kterých se má sdílet, jsou připojené kabelem? Pokud tu někde informace zazněla, omlouvám se.

Pokud je problém se objevováním počítačů na lokální síti, přikláněl bych se stejně jako předřečníci ke nastavení záložek. Pokud by v nich explicitně figurovaly ip adresy, je pak samozřejmě potřeba zajistit, aby se nemělnily. Případně by mohlo fungovat použití názvu počítačů. Případně lze vyzkoušet, jestli na všechny stanice v síti projde ping <ip adresa> i ping <jméno v síti>.

4
Hardware / Re:NVMe disk v RPi 5 se nezobrazí
« kdy: 10. 07. 2024, 09:12:34 »
Disk bude potřeba připojit pomocí mount (např. mount mount /dev/nvme0n1p2 /mnt/media). Pokud není naformátovaný, bude potřeba ještě připravit tabulku oddílů a vytvořit souborový systém dle požadavků.

5
Sítě / Re:Velmi pomalé DNS po aktivaci WireGuardu
« kdy: 08. 07. 2024, 09:55:51 »
Zkusil bych ještě tipy z: https://wiki.archlinux.org/title/WireGuard#Troubleshooting. Teoreticky může např. NM interagovat s wg... Zkusil bych
  • nastavit, aby se o wg tunel nestarala žádná další služba.
  • potvrdit, že na wg rozhraní neodchází DNS dotazy, když se pouští dig. Podle nastavení by se přes wg tunel neměly klást DNS dotazy: AllowedIPs neobsahuje adresy DNS serverů, pokud se nepletu. Pokud nechcete laborovat s tcpdump, můžete zkusit trochu přívětivější wireshark. Cílem je sledovat rozhraní wg, ne přímo ethernet/wifi. Obecně mi přijde lepší nechávat konfiguraci DNS ve wg, pokud je cílem přidat DNS server dosažitelný přes wg.
  • nechat wg tunel bez konfigurace DNS a postupně DNS servery přidat jiným způsobem. Ideálně s vypnutým i zapnutým wg, což ověří, že jsou z lokální sítě dosažitelné
  • tip, který nesouvisí s DNS: je docela možné, že u wg bude potřeba upravit MTU, podle konektivity. Pokud se používá nějaké tunelování PPPoE, tunelování kvůli IPv6 atp., může to mít vliv i na provoz, který nejde přes wg.

6
Server / Re:Napadený server
« kdy: 31. 05. 2024, 12:14:37 »
Jak již předřečníci zmínili, jde o těžkou disciplínu. Ještě se můžete podívat na ss:https://www.root.cz/clanky/uvod-do-prikazu-ss-zjistete-podrobnosti-o-sitovych-rozhranich/

Ideální by bylo zkusit server nějak omezit v přístupu do dalších sítí, aby se infekce případně nemohla šířit dál. Samozřejmě vyměnit hesla, klíče atp.

7
Server / Re:Vypnutí serveru na dvou UPS
« kdy: 16. 02. 2024, 12:03:17 »
Teoreticky by šlo vnést do systému trochu determinismu. Předpokládám, že napájecí zdroje serveru jsou v redundantní konfiguraci. Nechť je dále inteligentnější/s debianem komunikativnější UPS označena UPS A a druhá UPS B. Pak by šlo nastavit, že server preferuje napájení ze zdroje UPS B a failover jde na UPS A. Logiku UPS B není třeba vůbec řešit a můžete ji klidně nechat odpojit zátěž natvrdo bez ohlášení po sériovce. Druhá UPS pak bude v debianu pod dohledem a podle klesající kapacity UPS A se server vypne.

Kdybych se spletl a zdroje nebyly v redundantní konfiguraci, bude potřeba sledovat obě UPS a podle slabší vypnout.

8
Sítě / Re:Jak nastavit priority DSCP u switche MikroTik
« kdy: 15. 01. 2024, 14:07:49 »
Důležitý technický detail: klasické Dante používá starší standard PTP, ale AES67 a cokoliv se suity SMPTE2110 potřebuje PTPv2 (IEEE1588-2008). PTPv2 má předepsanou hierarchii, kde vystupují grandmasteři, transparent clock, boundary clock a ordinary clock, a dále bývá dle konkrétních požadavků aplikace vyhrazen specifický profil a případně doména, volba unicast/multicast... Tak je tomu i v případě AES67. Pokud by navíc byl požadavek udržovat přesnou synchronizaci s okolními technologiemi (například pro AV aplikace dle SMPTE2059), záleží na výběru sdíleného časového údaje (například TAI vs UTC). Pro korektní funkci PTPv2 je potřeba opora v hardware a celá hierarchie je navržena pro velkoformátové škálování realtime (distribuovaných) systémů a aplikací. Mikrotik má jen několik vybraných prvků, kde je implementována podpora PTPv2, Cisco podporuje PTPv2 v ve vyšších řadách Catalyst (konkrétně 9300 a vyšší), v novějších Nexusech a v několika industry řadách. Podporu PTP mají také switche Juniper, Arista nebo z levnějších Huawei (tuším, že se jedná o řady S*800).

Naproti tomu časování dante má větší laxitu a vystačí si s komoditnějšími prvky. Proto se relativně snadno implementuje na levnějších síťových prvcích. I zde je ale potřeba vybrat zdroj hodin a spotřebitele časového údaje pro synchronizaci.

Obecně platí, že kriticky časované aplikace by měly být korektně segmentovány od nekritických. Pokud se Vám podaří rozběhnout mezi prvky audiosítě správné časování, můžete se zamyslet, zda je potřeba navrhnout dante síť v tomtéž segmentu jako síť pro odesílání mailů a internet. Fronty a DSCP lze pak nastavit podle možností switchů a provozu. Zjednodušeně jde o nástroj, jak pomoci síťovým prvkům rozhodnout, která data mají přednost (potenciálně na úkor jiných). Můžete volit DSCP dle doporučení (například https://en.wikipedia.org/wiki/Differentiated_services nebo dle doporučení pro Dante), ale precizní třídění provozu dle priorit stejně přijde na řadu až ve chvíli, kdy další priority nastavíte a přes prvky v síti začne takto rozmanitý provoz proudit.

9
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 04. 01. 2024, 15:35:01 »
Lenze pre ukladanie grosov urcite float ani double pouzit nechcete, pri dost vysokych cislach sa vam zacnu stracat haliere, koruny, desiatky korun. Je to dane tym ze vo float je cislo ulozene ako mantisa, ktora ma urcitu maximalnu velkost nasobenu exponentom.
Cize pouzijete na jednoduchsich DB decimal (ktory je ulozeny podobne ako BCD) alebo pouzijete typ premenu ktory je ulozeny ako integer s tym ze pri vypoctoch sa transparentne deli podielom platnym pre danu menu (napr 100 pre euro).

Ak nechceme zbytocne komplikovat vypocty tak ukladame cenu a zaklad DPH dopocitavane, a ziadne dodatocne vypocty ani zaokruhlenia nie su potrebne, pretoze zaklad z ceny vieme vypocitat presne, kdezto cenu zo zakladu nie. To ze je to fakt som ukazal na priklade a v predoslom prispevku som aj vysvetlil preco to tak je.
Float má nevýhody, o kterých jsem psal. Ale nemám pocit, že by je typ decimal(x, y) řešil. Obecně může záležet na pořadí operací i u decimal. Pokud navíc data prezentujete zaokrouhlená, musíte se rozhodnout, jestli se budete držet prezentované přesnosti (haléř, setina haléře atp.), nebo budete interně používat vyšší přesnost a pak nebudou dokonale odpovídat prezentované mezivýsledky s výsledky spočtenými.

Jen si představte, že na položku za 0,0007 korony dá někdo akční nabídku tři za cenu dvou. A pak se na faktuře těchto položek objeví desetitisíce. S typem decimal(x, 4) bude výsledek záviset na pořadí operací a uplatnění slevy. A je úplně jedno, jestli počítáte DPH z daňového základu, nebo postupujete naopak. Jiní tu citovali pasáže o povinných údajích na fakturách; většinou je zvykem vycházet z nutných údajů a pak dle okolností doplnit nepovinné: Occamova břitva...

10
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 03. 01. 2024, 22:58:39 »
Způsob uložení toho či onoho je jen jedním z mnoha aspektů, který se řeší při návrhu architektury systému.

Ale ani zdaleka ne jediným.  A dost často se vyplatí použít jeden rovnák na ohýbak na místě A, než tři rovnáky na místech B, C a D.

Ale to byste jako superznalý expert měl dávno vědět.
Ak dokazete s presnej ulozenej ceny dopocitat presny zaklad, tak aky rovnak na miestach B, C, D potrebujete. Ten zaklad sice dopocitavate ale na chlp sedi stym ako by ste ho ukladal. Kdezto cena dopocitana zo zakladu sa rozchadza stym ako by ste ju mal ulozenu.

Co ve Vaší terminilogii znamená rovnák? Pokud se jako základ pro výpočty použije datový typ float nebo nějaký odvozený, budou operace násobení a sčítání komutativní, ale obecně ne asociativní a distributivní. Poslední dvě vlastnosti jsou splněny jen do jisté odchylky. Všechny tři vlastnosti mohou být při účetních operacích potřeba. Když k tomu přidáme požadavek, že pro reálnou měnu je vhodné prezentovat data s konečnou docela malou přesností a v hezké podobě, nemůžeme problém nikdy vyřešit. Můžeme se snažit eliminovat důsledky, počítat interně s vyšší přesností, vybírat precizně pořadí operací, ale boj je to marný. Obecně je špatný nápad problém zhoršovat nadbytečným zaokrouhlovánám mezivýpočtů. Výsledky mezivýpočtů ale na fakturách mohou vystupovat a není v mé moci říci, jestli je lepší pracovat se zaokrouhlenými hodnotami dle prezentované formy, nebo držet pro výpočty přesněji, ale nepatrně odchýlené od vytištěných hodnot.

Pár příkladů je i na wiki: https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems

11
Bazar / Re:Prodám serverová CPU
« kdy: 22. 10. 2023, 10:27:37 »
E5 2678V3 je stále k prodeji

12
Bazar / Re:Prodám serverová CPU
« kdy: 10. 10. 2023, 00:08:01 »
Cenu samozřejmě můžete nabídnout. Původní cena byla 2/3 nabídky z Czechserver. Za 700 Kč mohu CPU nechat, chcete-li.

13
Bazar / Prodám panel AUO B140RW02 V0 (Thinkpad t430)
« kdy: 08. 10. 2023, 14:54:49 »
Prodám panel AUO B140RW02 V0 pro Thinkpad t430 apod. Jde o lesklou variantu 1600x900. Použit byl jen krátce během čekání na matný FHD panel. Cena dohodou, případně vyměním za balení kávy.

14
Bazar / Re:Prodám serverová CPU
« kdy: 08. 10. 2023, 13:59:31 »
Snižuji cenu:
Intel Xeon E5-2676 v3 (12-Core 2.40 GHz): 1 000,- Kč,
Intel Xeon E5-2697 v2 (12-Core 2.70 GHz): 800,- Kč-

15
Bazar / Prodám serverová CPU
« kdy: 18. 09. 2023, 21:54:45 »
Nabízím k prodeji:
  • Intel Xeon E5-2676 v3 (12-Core 2.40 GHz): 1 500,- Kč,
  • Intel Xeon E5-2697 v2 (12-Core 2.70 GHz): 1 200,- Kč-
Dohoda možná. Předání ideálně v Praze.

Stran: [1] 2 3 ... 7