Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll.

Diese Geschichte fängt an mit: „Es war einmal eine Grafikkarte“.

„Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll“

Wie Ihr wisst, gibt es von Nvidiatreibern verschiedene Versionsnummern, z.b. 340,390,440. 440 ist der aktuelle Treiber für GTX1050 Karten.

Jetzt wirft dieser Treiber beim Systemboot eine Fehlermeldung wie folgt:

[ 222.363327] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 222.363328] [drm] No driver support for vblank timestamp query.
[ 222.397236] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:05:00.0 on minor 0
[ 222.406533] ————[ cut here ]————
[ 222.406534] refcount_t: underflow; use-after-free.
[ 222.406550] WARNING: CPU: 1 PID: 513 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0
[ 222.406551] Modules linked in: nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(OE) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel nvidia(POE) snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep joydev snd_seq snd_seq_device edac_mce_amd drm_kms_helper snd_pcm kvm_amd snd_timer drm snd kvm ipmi_devintf sp5100_tco irqbypass wmi_bmof ipmi_msghandler k10temp i2c_piix4 soundcore pcspkr gpio_amdpt gpio_generic acpi_cpufreq nfsd binfmt_misc auth_rpcgss nfs_acl lockd grace sunrpc ip_tables dm_crypt hid_logitech_hidpp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ccp r8169 aacraid hid_logitech_dj wmi pinctrl_amd fuse
[ 222.406576] CPU: 1 PID: 513 Comm: plymouthd Tainted: P OE 5.5.10-200.fc31.x86_64 #1
[ 222.406577] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P3.90 12/09/2019
[ 222.406579] RIP: 0010:refcount_warn_saturate+0xa6/0xf0
[ 222.406581] Code: 05 2e 03 2e 01 01 e8 7b 8e bc ff 0f 0b c3 80 3d 1c 03 2e 01 00 75 95 48 c7 c7 18 99 3c 9d c6 05 0c 03 2e 01 01 e8 5c 8e bc ff <0f> 0b c3 80 3d fb 02 2e 01 00 0f 85 72 ff ff ff 48 c7 c7 70 99 3c
[ 222.406582] RSP: 0018:ffffb573c103fcb8 EFLAGS: 00010286
[ 222.406583] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000007
[ 222.406584] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff9416ce859cc0
[ 222.406585] RBP: ffff9416bacbfce8 R08: 0000000000000413 R09: 0000000000000003
[ 222.406585] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9416c70502e8
[ 222.406586] R13: ffff9416c7050000 R14: 0000000000000008 R15: 0000000000000000
[ 222.406588] FS: 00007f07558f3f00(0000) GS:ffff9416ce840000(0000) knlGS:0000000000000000
[ 222.406588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 222.406589] CR2: 00007f0755072052 CR3: 00000004035c6000 CR4: 0000000000340ee0
[ 222.406590] Call Trace:
[ 222.406597] nv_drm_atomic_helper_disable_all+0xec/0x290 [nvidia_drm]
[ 222.406603] nv_drm_master_drop+0x22/0x60 [nvidia_drm]
[ 222.406616] drm_drop_master+0x1e/0x30 [drm]
[ 222.406628] drm_dropmaster_ioctl+0x4c/0x90 [drm]
[ 222.406639] ? drm_setmaster_ioctl+0xb0/0xb0 [drm]
[ 222.406651] drm_ioctl_kernel+0xaa/0xf0 [drm]
[ 222.406663] drm_ioctl+0x208/0x390 [drm]
[ 222.406675] ? drm_setmaster_ioctl+0xb0/0xb0 [drm]
[ 222.406678] ? do_filp_open+0xa5/0x100
[ 222.406681] ? selinux_file_ioctl+0x174/0x220
[ 222.406683] do_vfs_ioctl+0x461/0x6d0
[ 222.406685] ksys_ioctl+0x5e/0x90
[ 222.406686] __x64_sys_ioctl+0x16/0x20
[ 222.406690] do_syscall_64+0x5b/0x1c0
[ 222.406693] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 222.406695] RIP: 0033:0x7f0755bb138b
[ 222.406697] Code: 0f 1e fa 48 8b 05 fd 9a 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d cd 9a 0c 00 f7 d8 64 89 01 48
[ 222.406697] RSP: 002b:00007ffced5fe798 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 222.406699] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0755bb138b
[ 222.406699] RDX: 0000000000000000 RSI: 000000000000641f RDI: 0000000000000009
[ 222.406700] RBP: 000000000000641f R08: 000055b6a6ff1df0 R09: 000055b6a6fa5010
[ 222.406701] R10: 0000000000000000 R11: 0000000000000246 R12: 000055b6a6ff2970
[ 222.406701] R13: 0000000000000009 R14: 0000000000000000 R15: 0000000000000000
[ 222.406703] —[ end trace fa45bb73ed0780f4 ]—
[ 222.411358] kauditd_printk_skb: 45 callbacks suppressed

Von Euch sieht natürlich jeder sofort, daß hier NVIDIA und PLYMOUTH im Spiel sind und das der Nvidiatreiber einen Fehler bei der DRM Initialisierung verursacht. Der Server bootet danach weiter, also erstmal nicht so wichtig. Es folgen die üblichen Dinge: Bugreport bei Fedora ( wegen Plymouth ) und bei RPMFusion ( wegen Nvidia ) erstellen, und komplett entäuscht werden… !

„Da ist kein Bug, gehen Sie weiter!“

Nun kann Fedora da nicht viel machen, wenn der Nvidiatreiber da Mist baut, außer natürlich, es übergibt dem Treiber schon was falsches, da könnte der Treiber dann nicht mehr soviel für den Bug. Das werden wir aber nie erfahren, denn der Bug wurde sofort beerdigt. Nagut, wir haben ja noch den RPMFusionreport.

Sagte ich, wir haben noch einen anderen offenen Bugreport? So kann man sich irren: „Your Bugreport has been closed with „WONT FIX“.Und dann stehen wir mit einem Fehler da, von dem alle Parteien sagen „Nicht mein Problem“. Doch, Eurer Problem! Wessen denn sonst?

Der Bug wurde in der Devliste von Nvidia zwar besprochen, aber es gibt leider keinen finalen Fix dafür:

Devliste: https://forums.developer.nvidia.com/t/bug-nvidia-440-64-kernel-5-5-6-stable-boot-trace-was-nvidia-440-59-kernel-5-5-1-stable-boot-trace/111643

Der derzeitige Stand ist: Geht halt nicht; und DRM geht dann halt auch nicht. Wobei letzteres sollte man eh abschaffen, falls damit das DigitalRightsManagement gemeint ist.

Was mich aber am meisten stört: „ist nicht unser Problem“. Von RPMFusion hätte ich erwartet, daß das offen bleibt, bis das von den Nvidiadevs gefixt wurde, schon um das Problem zu tracken, aber von Scott kann man halt oft nichts anderes erwarten.

Fedora: Kernel 5.4.7 verfügbar

Mit dem Push vom Linux Kernel 5.4.7 ins stabile Repository von Fedora, hat die Nvidia HDMI Audiokrise ein Ende.

Kernel 5.4.7 verfügbar

Wie in dem Beitrag vom Dezember 2019 „Kernel 5.3.16 mit HDMI-Audio Problemen“ beschrieben, gab es ein ein kleines Problem beim korrekten Markieren von NVIDIA Audiogeräten, z.b. Monitoren mit Lautsprechern. Das wurde nicht mehr für die 5.3er Serie des Kernels behoben, obwohl es nur EIN einziger Zeichenwechsel gewesen wäre.

Wie sich damals ja schnell herausgestellt hat, wollte man mit einem Fix eigentlich ein anderes Problem bei Audiogeräten beheben, hat aber mehr kaputt gemacht, also der Fix behoben hatte. Da so ein Kernelbuild auch auf einem schnellen i7 auf SSDs mal locker 1h plus Tests dauern kann,  kann ich schon verstehen, daß man keine eigene Kernelrelease für den an sich trivialen Fix gebaut hat, zumal man einfach auf einen alten Kernel ausweichen konnte.

Es bleibt zu hoffen, daß es nicht nochmal passiert, denn es hat echt in den Ohren geklingelt.

Kernel 5.3.16 mit HDMI-Audio Problemen

Na klingeln Euch auch noch die Ohren? Mir tun die jetzt noch weh! Wer eine NVIDIA Grafikkarte und einen aktuellen 5.3.16 Kernel einsetzt, der sollte jetzt kein HDMI benutzen.

Kernel Regression durch Patch für eine andere Regression

Es ist immer blöd, wenn der Fehlerfix mehr Probleme macht, als er behebt. So geschehen im neuen 5.3.16 Kernel, wenn man eine NVIDIA Karte hat. Wie Takashi Iwai von Suse dazu schreibt:

The commit e38e486d66e2 („ALSA: hda: Modify stream stripe mask only when needed“) tried to address the regression by the unconditional application of the stripe mask, but this caused yet another
regression for the previously working devices. Namely, the patch clears the azx_dev->stripe flag at snd_hdac_stream_clear(), but this may be called multiple times before restarting the stream, so this
ended up with clearance of the flag for the whole time.

Hat da wohl jemand eine Kleinigkeit nicht bedacht aka die falsche Stelle gepatched 😉 Als Resultat fallen einem fast die Ohren ab, weil die Lautstärke des HDMI Streams so derbe übersteuert klingt, daß selbst 2% Lautstärke nur als Lärm bezeichnet werden können. Ich vermute das hier die Audiodaten im falschen Format angeliefert werden, wo alles was leise wäre, extrem laut ist z.b. LE statt BE Sortierung der Bits.

Die Lösung

Natürlich gibt es eine einfach Lösung für das Problem: 5.3.15 booten oder bis zum nächsten Kernelupdate kein HDMI benutzen 😉

Update:

Laut Laura Abbot von Red Hat wird der Fehler nicht mehr in der 5.3er Serie behoben, was ich bislang bestätigen kann, denn der 5.3.18 hat die gleiche Macke. Es soll stattdessen gleich der 5.4.0 Kernel gebaut werden. Frau Abbot bemüht sich darum, daß der Patch bereits in 5.4.0 einfliesst.

Der Soundbug ist auch unabhängig von den Treibern, aber das habe ich nicht anders erwartet.

Update: wurde in 5.4.5 gefixt.

Nvidia und das Tearing

Screen Tearing, das Phänomen, daß ein Teil des Monitorbildes schon einen Frame weiter ist, also der andere.

Beispiel:

Es passiert bei Spielen, beim Videos ansehen und auch mal beim Bewegen von Fenstern. Nvidia Grafikkarten sind leider prädestiniert für dieses Problem, weil, und das ist der fiese Teil, Nvidia die Funktion zum Unterdrücken des Tearings standardmäßig abgeschaltet hat.

Aber, Abhilfe ist nah 🙂

 

Erstmal brauchen wir das Nvidia Configtool und wählen dort die Display Configuration aus.

Wir brauchen den Advanced Button.

Jetzt aktivieren wir die Force Composition Pipeline und das Tearing ist Geschichte.

Sollte die Force Composition Pipeline nicht reichen, braucht es die Force Full Composition Pipeline.

Ihr seht die Optionen nicht?

Das hat natürlich Gründe. Zunächst mal braucht es eine minimale Treiberversion 375.26, zum Anderen eine Grafikkarte, die den Modus überhaupt unterstützt. Eine GT840M z.B. hat das nicht, egal welche Treiberversion Ihr habt.

Flatpak ist */()$§*#D3§$

Ich fand ja FlatPak schon im letzten Artikel nicht so prall, wegen der ganzen Platzverschwendung, aber das hier topt es grade :

[marius ~]$ /usr/bin/flatpak info "com.belledonnecommunications.linphone/x86_64/4.1.1"
Ref: app/com.belledonnecommunications.linphone/x86_64/4.1.1
ID: com.belledonnecommunications.linphone
Arch: x86_64
Branch: 4.1.1
Origin: com.belledonnecommunications.linphone-1-origin
Commit: bae79f29ce390b6b28254cba0ae63f1bbb8d9a30f50acce422ce5ef1f1839441
Location: /home/marius/.local/share/flatpak/app/com.belledonnecommunications.linphone/x86_64/4.1.1/bae79f29ce390b6b28254cba0ae63f1bbb8d9a30f50acce422ce5ef1f1839441
Installed size: 315,4 MB
Runtime: org.freedesktop.Platform/x86_64/1.6
[marius ~]$ /usr/bin/flatpak update "com.belledonnecommunications.linphone/x86_64/4.1.1"
Looking for updates...
Fehler: com.belledonnecommunications.linphone/x86_64/4.1.1 not installed
[marius ~]$ /usr/bin/flatpak update app/com.belledonnecommunications.linphone/x86_64/4.1.1
Looking for updates...
Fehler: app/com.belledonnecommunications.linphone/x86_64/4.1.1 not installed

Also, mit der original REF, die die INFO Anweisung ausgibt ODER die auch LIST ausgibt, behauptet Flatpak, die Anwendung wäre nicht installiert. Lustigerweise will er die Starten, was übrigens nicht geht, weil die NVIDIA Treiber aktualisiert worden sind und nun die von Flatpak installierten Treiber zu den Treibern nicht mehr passen:

Installiert ist 384.90 , aber Flatpak hat noch 375 im Einsatz :

[marius]$ flatpak list
Ref Options 
com.belledonnecommunications.linphone/x86_64/4.1.1 user,current
org.freedesktop.Platform.GL.nvidia-375-66/i386/1.4 user,runtime
org.freedesktop.Platform.GL.nvidia-375-66/x86_64/1.4 user,runtime
org.freedesktop.Platform/x86_64/1.6 user,runtime

Das Ende von Lied: LinPhone startet nicht mehr 😀 Natürlich updated flatpak auch nichts, wenn man nur „update“ eingibt, was alles aktualisiert laut Manpage, aber es gibt wohl kein Update dafür 😀

Fazit: Tolle Idee son System im System 😀

Aufruf: Nieder mit den Flatpaks und Snappys dieser Welt. Es lebe DNF ! 😉

PS: Zu DNF kommen wir morgen nochmal 😀

Update: Annahme verweigert

Der Red Hat Bugbetreuer hat die Meldung, daß die installierten Flatpakapps nicht gefunden werden, wenn man sie namentlich angibt, als „Kein Bug“/“Kein Supportforum“ abgetan. Also entweder der weiß mehr als wir zu dem Thema, oder er hat leider keine Vorstellung davon, was ein Bug in Flatpak sein könnte 🙂

Mal sehen was per Github vom Projektmaintainer kommt :  https://github.com/flatpak/flatpak/issues/1139