Een geïntegreerde GPU controleren nadat de kernel is bijgewerkt
Een geïntegreerde GPU blijft alleen beschikbaar wanneer de nieuwe kernel deze detecteert, het juiste stuurprogramma koppelt, rendernodes aanmaakt en deze beschikbaar stelt voor de workload.
Na een kernelupdate op een thuisserver kan een media-app terugvallen op software, ook al blijft de schakelaar voor hardwareversnelling ingeschakeld. De fout kan optreden bij PCI-detectie, het koppelen van de kernelmodule, het laden van firmware, het aanmaken van DRM-apparaten, de initialisatie van VA-API, apparaatmachtigingen, de Docker-koppeling of het FFmpeg-pad van de mediaserver. Controleer deze lagen in deze volgorde en vergelijk ze met de vorige boot voordat je applicatie-instellingen wijzigt.
Noteer de nieuwe kernel en bevestig de iGPU op de PCI-bus
Noteer de versie van de actieve kernel, eerder geïnstalleerde kernels, opstartparameters en het tijdstip van de update. Geef vervolgens PCI-apparaten van de beeldschermklasse weer met numerieke ID's en het kernelstuurprogramma dat momenteel aan de geïntegreerde GPU is gekoppeld.
Als de iGPU niet in de PCI-enumeratie voorkomt, controleer dan eerst de firmware- of BIOS-instellingen voordat je VA-API debugt. Een server kan alleen een afzonderlijke GPU beschikbaar stellen wanneer een iGPU- of multimonitoroptie is uitgeschakeld, zoals blijkt uit een geval waarin de iGPU verborgen was voor Linux.
Vergelijk de apparaat-ID en het gekoppelde stuurprogramma met de laatst bekende goed werkende boot. Voor Intel-systemen is dit meestal i915 of, bij ondersteunde nieuwere paden, xe; gebruik het stuurprogramma dat daadwerkelijk voor de hardware en distributie bedoeld is, in plaats van een modulenaam van een ander platform te forceren.
Lees kernel-logboeken voor de initialisatie van stuurprogramma en firmware
Zoek in het logboek van de huidige boot naar het GPU-stuurprogramma, DRM, GuC- of HuC-firmware, beeldscherminitialisatie, probe-fouten, time-outs en moduleblokkeringen. Vergelijk dezelfde meldingen met die van de vorige kernel als permanente logboeken beschikbaar zijn.
Een fout in het mediastuurprogramma kan optreden, zelfs wanneer de hardware wordt vermeld. Een Intel-issue documenteert dat VA-API-initialisatie mislukte op een geïntegreerde Xe-LPG-GPU nadat de omliggende softwarestack was gewijzigd. Dit laat zien dat gedetecteerde hardware niet voldoende is.
Bevestig dat de vereiste firmwarepakketten nog aanwezig zijn en dat de module niet wordt geblokkeerd door een nieuwe kernelparameter, blacklist of Secure-Bootbeleid. Installeer de mediaserver niet opnieuw voordat het hoststuurprogramma zonder fouten is geïnitialiseerd.
Bevestig dat de DRM-rendernode nog bestaat
Inspecteer /dev/dri en noteer de major- en minornummers, eigenaren, groepen en symbolische verwijzingen voor elke kaart en rendernode. Ga er niet van uit dat de iGPU altijd renderD128 blijft wanneer er een andere GPU aanwezig is.
Hardwareversnelling werkt niet wanneer FFmpeg naar een node verwijst die wel bestaat, maar niet langer een geldige VA-display biedt. Een Jellyfin-rapport toont de doorslaggevende fout: geen VA-display voor het renderapparaat.
Koppel de rendernode via sysfs terug aan het PCI-apparaat en werk de container- of applicatieconfiguratie alleen bij als de identiteit van de node daadwerkelijk is gewijzigd. Vermijd brede machtigingen zoals modus 777; behoud het model met de rendergroep en controleer of het serviceaccount lid is van die groep.
Test VA-API of Quick Sync op de host voordat je Docker controleert
Voer de VA-API-diagnostiek van de distributie uit tegen de geverifieerde rendernode en leg de naam van het stuurprogramma, de VA-API-versie, ondersteunde decodeprofielen, encode-ingangspunten en videobewerkingsmogelijkheden vast.
Het mediastuurprogramma voor gebruikersruimte moet overeenkomen met de hardwaregeneratie en de kernelinterface. Een opgeloste Linux-kwestie benadrukt dat DRM-kernelmodules en DRI- of VA-stuurprogramma's voor gebruikersruimte afzonderlijke lagen zijn; als je die door elkaar haalt, kan het verkeerde stuurprogramma voor gebruikersruimte actief blijven.
Als VA-API op de host mislukt, vergelijk dan de huidige mediastuurprogramma- en firmwarepakketten met de versies van vóór de update. Als VA-API op de host wel werkt, laat de kernel en het stuurprogramma ongewijzigd terwijl je de containergrens controleert.
Controleer hetzelfde apparaat en dezelfde groepen in de container
Inspecteer de apparaten, groeps-ID's en toegang tot de gekozen rendernode van de actieve container. Voer de meegeleverde VA-API-diagnostiek of FFmpeg-build van de mediaserver in de container uit, want succes op de host bewijst niet dat het in de container werkt.
Een container kan /dev/dri/renderD128 ontvangen en toch mislukken omdat het proces niet over de bijbehorende machtiging van de rendergroep beschikt. Een rapport over een Jellyfin-container laat zien dat zowel apparaatkoppeling en groepstoegang moeten worden gecontroleerd.
Vergelijk de numerieke groeps-ID's op de host en in de container en maak de service indien nodig opnieuw aan met expliciete apparaat- en groepsconfiguratie. De ZimaSpace-handleiding voor het controleren van hardwaretranscodering biedt het volgende bewijs op applicatieniveau.
Forceer een kleine code getest en bekijk de daadwerkelijke GPU-engines
Gebruik één bekend werkend H.264- of HEVC-voorbeeld en forceer een videotranscodering zonder ondertiteling of HDR-tonemapping. Leg de dashboardstatus, de FFmpeg-opdracht, de transcoderingssnelheid, het CPU-gebruik en de activiteit van de GPU-decodeer- of encode-engine vast.
Een mediaserver kan hardwareondersteuning melden, maar automatisch het verkeerde VA-API-apparaat selecteren. Een Jellyfin-issue documenteert een geval waarin expliciete apparaatselectie bepaalde of FFmpeg het versnellingspad detecteerde.
Test decodering en codering indien mogelijk afzonderlijk. Als één codec mislukt terwijl een basiscodec wel werkt, is de iGPU beschikbaar, maar wordt dat profiel, die firmwarefunctie, dat stuurprogrammapad of die filter niet ondersteund. Markeer niet de volledige GPU als ontbrekend op basis van één geavanceerde tonemappingfout.
Gebruik de vorige kernel als gecontroleerde vergelijking
Als PCI-detectie, rendernodes of VA-API op de host alleen met de nieuwe kernel mislukken, start dan de vorige geïnstalleerde kernel op zonder de containerimage, mediaserverversie of gebruikersruimteconfiguratie te wijzigen.
Een Jellyfin-probleemoplossingsgeval raadt terugkeren naar de vorige kernel aan als de eenvoudigste manier om onderscheid te maken wanneer wordt vermoed dat de fout na een kernelwijziging is ontstaan. De waarde zit in een gecontroleerde kernelvergelijking, niet in het behandelen van terugdraaien als permanente oplossing.
De controle is voltooid wanneer de huidige kernel de iGPU op PCI toont, het bedoelde stuurprogramma koppelt, de juiste rendernode aanmaakt, VA-API initialiseert, het apparaat in de container beschikbaar stelt en een echte codectest versnelt. Als alleen de vorige kernel slaagt, houd deze dan als tijdelijke opstartoptie beschikbaar terwijl je de regressie in de kernel, firmware of het mediastuurprogramma isoleert.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Kan Plex een GPU delen met een andere Docker-container?
Plex en een andere container kunnen vaak dezelfde GPU gebruiken, maar je moet de driverondersteuning, apparaattoewijzing, belasting van de video-engine, het geheugengebruik en het...
Hoe je kunt bepalen of een Plex-fout door de client of de server wordt veroorzaakt
Reproduceer hetzelfde item op een andere client, vergelijk het sessiepad en verzamel pas serverbewijs nadat de scope heeft uitgewezen waar de fout daadwerkelijk zit.
Plex-cache en tijdelijke opslag voor transcodering configureren
Bescherm de permanente Plex-status door tijdelijke transcodebestanden op geschikte lokale opslag te plaatsen en controleer vervolgens het opruimen, de beschikbare ruimte en het gedrag...
