Så här verifierar du att en integrerad GPU fortfarande är tillgänglig efter en kärnuppdatering
Ett integrerat grafikkort är endast tillgängligt när den nya kärnan upptäcker det, binder rätt drivrutin, skapar renderingsnoder och gör dem tillgängliga för arbetsbelastningen.
Efter en uppdatering av kärnan på en hemmaserver kan en medieapp falla tillbaka till programvara även om reglaget för hårdvaruacceleration fortfarande är aktiverat. Felet kan uppstå vid PCI-detektering, bindning av kärnmodul, inläsning av fast programvara, skapande av DRM-enhet, initiering av VA-API, enhetsbehörigheter, Docker-mappning eller medieserverns FFmpeg-sökväg. Kontrollera dessa lager i ordning och jämför dem med den föregående uppstarten innan du ändrar programinställningarna.
Notera den nya kärnan och bekräfta iGPU:n på PCI-bussen
Notera den körande kärnversionen, tidigare installerade kärnor, startparametrar och tidpunkten för uppdateringen. Lista sedan PCI-enheter i displayklassen med numeriska ID:n samt kärndrivrutinen som för närvarande är bunden till det integrerade grafikkortet.
Om iGPU:n saknas i PCI-uppräkningen bör du kontrollera inställningarna för fast programvara eller BIOS innan du felsöker VA-API. En server kan endast visa ett separat grafikkort när ett alternativ för iGPU eller flera bildskärmar är inaktiverat, vilket visas i ett fall där iGPU:n var dold för Linux.
Jämför enhets-ID:t och den bundna drivrutinen med den senast fungerande uppstarten. På Intel-system är detta vanligtvis i915 eller, i nyare sökvägar som stöds, xe. Använd den drivrutin som faktiskt är avsedd för maskinvaran och distributionen i stället för att tvinga fram ett modulnamn från en annan plattform.
Läs kärnloggarna för initiering av drivrutin och fast programvara
Sök i loggen för den aktuella uppstarten efter grafikkortsdrivrutinen, DRM, GuC- eller HuC-firmware, bildskärmsinitiering, sondfel, tidsgränsöverskridningar och svartlistade moduler. Jämför samma meddelanden från den föregående kärnan om beständiga loggar finns tillgängliga.
Ett fel i mediedrivrutinen kan uppstå även när maskinvaran listas. Ett Intel-problem dokumenterar att VA-API-initiering misslyckades på ett integrerat Xe-LPG-grafikkort efter att den omgivande programvarustacken ändrades, vilket visar att upptäckt maskinvara inte räcker.
Bekräfta att de nödvändiga firmwarepaketen fortfarande finns och att modulen inte blockeras av en ny kärnparameter, svartlistning eller Secure Boot-policy. Installera inte om medieservern förrän värddatorns drivrutin initieras utan fel.
Bekräfta att DRM-renderingsnoden fortfarande finns
Inspektera /dev/dri och notera huvud- och delnummer, ägare, grupper och symboliska målsökvägar för varje kort och renderingsnod. Utgå inte från att iGPU:n alltid kommer att förbli renderD128 när ett annat grafikkort finns.
Hårdvaruacceleration misslyckas när FFmpeg riktas mot en nod som finns men inte längre tillhandahåller en giltig VA-display. En Jellyfin-rapport visar det avgörande felet: ingen VA-display för renderingsenheten.
Koppla renderingsnoden till dess PCI-enhet via sysfs och uppdatera sedan behållarens eller programmets konfiguration endast om nodens identitet faktiskt har ändrats. Undvik breda behörigheter som läge 777; behåll modellen med renderingsgruppen och kontrollera tjänstekontots grupptillhörighet.
Testa VA-API eller Quick Sync på värddatorn före Docker
Kör distributionens VA-API-diagnostik mot den verifierade renderingsnoden och samla in drivrutinsnamn, VA-API-version, profiler för avkodning som stöds, kodningsingångar och funktioner för videobearbetning.
Användardrivrutinen för media måste matcha maskinvarugenerationen och kärnans gränssnitt. Ett löst Linux-fall betonar att kärnans DRM-moduler och användarutrymmets DRI- eller VA-drivrutiner är separata lager. Om de blandas ihop kan fel användardrivrutin bli kvar.
Om VA-API misslyckas på värddatorn ska du jämföra de aktuella mediedrivrutins- och firmwarepaketen med versionerna före uppdateringen. Om VA-API fungerar på värddatorn bör du låta kärnan och drivrutinen vara oförändrade medan du går vidare till behållargränsen.
Verifiera samma enhet och grupper i behållaren
Inspektera den körande behållarens enheter, grupp-ID:n och åtkomst till den valda renderingsnoden. Kör medieserverns medföljande VA-API-diagnostik eller FFmpeg-version inne i behållaren, eftersom framgång på värddatorn inte bevisar att det fungerar i behållaren.
En behållare kan få /dev/dri/renderD128 och ändå misslyckas eftersom processen saknar behörighet till den matchande renderingsgruppen. En rapport om en Jellyfin-behållare visar att enhetsmappning och gruppåtkomst båda måste verifieras.
Jämför numeriska grupp-ID:n på värddatorn och i behållaren och återskapa sedan tjänsten med uttrycklig enhets- och gruppkonfiguration vid behov. ZimaSpace-guiden om att kontrollera hårdvarutranskodning ger nästa bekräftelse på programnivå.
Tvinga fram ett litet kodektest och övervaka de faktiska GPU-motorerna
Använd ett känt fungerande H.264- eller HEVC-exempel och tvinga fram en videotranskodning utan undertexter eller HDR-tonmappning. Notera instrumentpanelens status, FFmpeg-kommandot, transkoderingshastigheten, CPU-användningen och GPU-motorernas aktivitet för avkodning eller kodning.
En medieserver kan rapportera stöd för maskinvara men automatiskt välja fel VA-API-enhet. Ett Jellyfin-problem dokumenterar ett fall där uttryckligt val av enhet ändrade om FFmpeg upptäckte accelereringssökvägen.
Testa avkodning och kodning separat när det är möjligt. Om en kodek misslyckas medan en grundläggande kodek fungerar är iGPU:n tillgänglig, men profilen, firmwarefunktionen, drivrutinssökvägen eller filtret stöds inte. Förklara inte hela grafikkortet som saknat utifrån ett enda avancerat fel i tonmappningen.
Använd den föregående kärnan som en kontrollerad jämförelse
Om PCI-detektering, renderingsnoder eller VA-API på värddatorn endast misslyckas med den nya kärnan ska du starta den föregående installerade kärnan utan att ändra behållaravbilden, medieserverversionen eller användarutrymmets konfiguration.
Ett felsökningsfall för Jellyfin rekommenderar att återgå till föregående kärna som den enklaste skiljemetoden när felet misstänks följa efter en kärnändring. Värdet ligger i en kontrollerad kärnjämförelse, inte i att behandla återgången som en permanent lösning.
Verifieringen är klar när den aktuella kärnan visar iGPU:n på PCI-bussen, binder den avsedda drivrutinen, skapar rätt renderingsnod, initierar VA-API, gör enheten tillgänglig i behållaren och accelererar ett verkligt kodektest. Om endast den föregående kärnan fungerar kan du behålla den som ett tillfälligt startalternativ medan en regression i kärnan, firmware eller mediedrivrutin isoleras.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
