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.

Wenn sich Grub und Grubby uneins sind

Ihr erinnert Euch noch an den Artikel Fedora 30&31 Bootumstellung führt zu Startproblem? Davon habe ich eine neue Version für Euch 🙂

Wenn sich Grub und Grubby uneins sind

Allen Anfängern rate ich jetzt mal zunächst ein bisschen zu Lesen: Grubby: wie man wieder einen Default Kernel setzen kann damit dürfte klar sein, was Grubby macht. Grub ist der verbreiteste Bootloader für Linux und der liest normalerweise das ein, was Grubby so von sich geschrieben hat. Wenn ich das schon so flapsig schreibe, dann kann das ja eigentlich schon nicht stimmen, tut es auch nicht immer 🙂

Fangen wir mit der Geschichte von vorn an …ää ähm .. ä ..hm… es war mal im Jahr 2019 ein Fedora Releasewechsel von Fedora 29 auf 30, und ein Linux Tablet. Ok,ok, mein Tablet war zwar an der Geschichte beteiligt, aber das hätte jedem PC passieren können, ehrlich 😉 Mit Fedora 30 wurde ja BLS eingeführt und dabei muß jemand an Grub geschraubt und was falsch gemacht haben, denn bis zu dem Upgrade lief das mit dem Setzen des Default Kernels über Grubby noch.

„Ihr wagt es mir zu trotzen, wer seid Ihr Ritter Rosthülle!“

Seit dem Update konnte ich machen was ich wollte, es wurde immer der erste Kernel in Menü als Bootkernel ausgewählt, egal was ich mit Grubby angestellt habe. Zu beachten ist hier, daß immer alle aktuell installierten Kernels im Menü aufgetaucht sind. Nun habe ich ja für den Beitrag zum neuen Surfacekernel Repo einen, wer würde es erraten, neuen Kernel installiert \o/ und prompt bootete der nicht automatisch. Da ich aber sicher gehen wollte, daß der immer startet, habe ich da nochmal alles überprüft.

Die Dateien in /boot/grub2/ waren alle OK. Wenn Grubby gehustet hat, änderten sich die grubenv und die grub.cfg untertänigst und trotzdem blieb es beim ersten Kernel im Menü. Unglaublich. Jetzt kann man glücklicherweise im Grubmenü auf „c“ drücken und kommt in die GrubShell. Wenn man da „set“ aufruft, zeigt er einem die Grubvariablen an, das sind die, die man mit dem Eintrag in der grubenv überschreiben kann. Wenn man sich die grub.cfg ansieht:

if [ -f ${config_directory}/grubenv ]; then
    load_env -f ${config_directory}/grubenv
elif [ -s $prefix/grubenv ]; then
    load_env
fi

erkennt man auch als Uneingeweihter, daß hier die grubenv geladen werden soll. d.b. Schritt Eins vom Bootloader, bevor das Menü überhaupt zusammenbaut wird, ist also die grubenv laden und die passenden Variablen setzen oder überschreiben.

Die GrubShell

Wie bereits erwähnt kann man sich das Ergebnis in der GrubShell ansehen, wenn man „set“ eingibt. Solltet Ihr beim nächsten Boot einfach mal machen und reinsehen. „boot“ oder „reboot“ bringen Euch da wieder raus. Als ich heute (für Euch vor 2 Wochen) in die Variablenliste von „set“ sah, wäre ich fast vom Stuhl gefallen. Da stand allen ernstes ein Kernel 5.2.7 (Fedora 29) als Defaultkernel drin! Den gab es unter /boot/ aber gar nicht mehr und das System hat nur eine Bootplatte. Ich habe ja erwähnt, daß alle Kernel, die hätten im Menü sein sollen, auch im Menü drin waren. Ein Kernel 5.2.7 wäre da aufgefallen.

Jetzt sucht mal auf der Platte nach einem Kernel, den es seit 5 Monaten nicht mehr gibt, viel Spaß dabei! Das muß ja irgendwo drin stehen, also /etc/ durchsucht, /boot/grub2 durchsucht, /usr/ durchsucht, nichts! Kein Kernel, kein Eintrag.. wo zum Geier kommt das her? Grubby schreibt doch jede Änderung des Kernels direkt in die Files, da KANN DOCH GAR KEIN ALTER KERNEL DRINSTEHEN!

Wenn A und B nicht das Gleiche sind!

Stands auch nicht. Die Lösung für das Problem war dann weniger spannend als die Suche danach 🙂 Grubby änderte die Dateien in /boot/grub2, aber Grub lud nicht /boot/grub2 sondern /boot/EFI/efi/fedora/ und da standen uralte Fedora 29 Sachen in den Dateien. Das ist so eine „Links weiß nicht was Rechts tun“ Geschichte. Die Lösung für das Problem ist dann ganz einfach, man nimmt einfach zwei Symbolische Links und verknüpft die beiden Orte, so daß es nur noch eine Datei mit dem Inhalt gibt, und nicht mehr zwei verschiedene.

Da Grubby alle aktuellen Anpassungen nach /boot/grub2/ schreibt, aber Grub aus /boot/EFI/efi/fedora/ liest und zu allem Überfluß /boot/ zu „/“ wird, wenn man der Bootloader ist, muß man ein klein bisschen kreativ werden, um den korrekt Pfad für den Link abzuleiten. Folgende Anweisungen können das für Euch direkt lösen:

mv /boot/grub2/grubenv /boot/EFI/efi/fedora/grubenv
mv /boot/grub2/grub.cfg /boot/EFI/efi/fedora/grub.cfg
cd /boot/grub2
ln -s ../EFI/efi/fedora/grubenv
ln -s ../EFI/efi/fedora/grub.cfg

Kurz erklärt

„mv“ steht für „move“ und verschiebt Dateien von A nach B. Wenn B vorhanden, wird es überschrieben, man muß B also nicht vorher löschen.
„ln -s {Pfad/Dateiname}“  legt den symbolischen (-s) Link von {Pfad/Dateiname} als „Dateiname“ im Filesystem an. Sollen Ziel und Quelle des Links gleich heißen muß man da nichts weiter angeben. Üblich wäre aber z.B. „ln -s pfad1/datei1 pfad2/datei2“ . In den Anweisungen oben haben wir einen relativen Pfad ../EFI/efi/fedora benutzt, weil /boot/EFI/efi/fedora nicht geht, da es /boot/ in der Bootparition nicht gibt, denn die wird während des Bootens erst später unter /boot/ eingehängt. Der Bootloader hantiert also direkt im /boot/ rum, weswegen in seinem Kontext „/boot/“ = „/“ ist. Das Root = / ist hätte man riskieren können, aber da Grub nicht von /boot/grub2 lädt, könnte da ja noch viel mehr anders sein, als mir jetzt bekannt ist. Daher war der relative Link hier sicherer als „ln -s /EFI/efi/fedora/grubenv“ zu benutzen.

Für Anfänger: Ein symbolischer Link ist eigentlich nur eine kleine Textdatei, wo das Ziel ( hier ../EFI/efi/fedora/grubenv ) drinsteht. Das Filesystem merkt das, und folgt dann dem Pfad zum eigentlichen Ziel. Symbolische Links kann man quer über alle eingehängten Partitionen benutzen. „Hardlinks“, die sich hier auch angeboten hätten, kann man nur innerhalb einer Partition benutzen, dafür haben die andere Vorteile.

Bugreport ist raus, mal sehen wann die Beule am Kopf der GrubDevs vom gegen die Wand schlagen wieder abgeschwollen ist 🙂

Linux: Surface Tablets und Laptops mit eigenem Kernel-Repo

„Du saga mal, Du hascht doch des Suuhrfaze, gibtsch da scho wos njeues pführ?“ hallte es aus dem mitfünfziger Herrn am Tisch gegenüber. Freundlich, aber bestimmt, machte Ihm mein Sitznachbar darauf aufmerksam, daß er kurz hinter Kiel wäre und folglich kaum zu verstehen sei. Dies schien den Herrn genauso wenig zu stören, wie der Umstand, daß mein Sitznachbar eher andigital veranlagt ist und es sich bei dem Gerät vielmehr um eine kurz Präsentationsleihgabe meinerseits handelte.

Nachdem die beiden Fischköpfe ( wir… vermutlich ) kurz getuschelt hatten, übersetzte eine junge Dame (Bezeichnung Anna-Luisa o7) für uns (daher auch die grobe Entschlüsselung oben) und es entstand eine schöne , wenn auch sehr kurze, Unterhaltung zum Thema: Linux auf einem Surface Pro 4.

Surface Tablets und Laptops mit eigenem Kernel-Repo

„Ja, da gibts was njeues.. ehm.. neues“ und für Euch schalte ich das Gespräch mal auf Allwissenden Erzähler um, sonst darf ich mich in Bayern gar nimmer sehen lassen. Also, Ja Leute, es gibt eine nicht mehr ganz taufrische Entwicklung, die teils sehr erfreulich, weil unheimlich praktisch ist, andererseits leider nicht so ganz funktioniert. Letzterer Teil wird derzeit noch untersucht.

Seit einige Monaten gibt es im Github einen eigenen Prebuild-Kernel für Arch, Debian und Fedora. Den richtet Ihr Euch so für Fedora ein:

  1. Das Repo hinzufügen:

sudo dnf config-manager --add-repo=https://pkg.surfacelinux.com/fedora/linux-surface.repo

2. Den Kernel  installieren:

sudo dnf install kernel-surface surface-firmware surface-secureboot
sudo dnf install --allowerasing libwacom-surface

3. Letztere Anweisung ist eher optional, falls man mit Wacom Probleme hat., was auch die Stifteingabe betrifft.

Surface rebooten, den neuen Kernel auswählen und jetzt kommt es drauf an, ob Ihr ein SP4/SB1 habt oder ein anderes Surfacegerät Euer eigen nennt, denn bei mir (SP4) bootet der Kernel zwar sauber, aber IPTS ist nicht da, was man allerdings für Touchbedienung braucht.  So bin ich kaum einen Schritt weiter als mit dem Kernel von Fedora selbst. Ein Problem an dem derzeit gearbeitet wird.

Und da ist auch schon die Lösung … ( sowas von genial den Artikel schon Tage im Voraus zu schreiben 😀 ) … dem mangelnden Touchsupport kann man so begegnen:

[root@surface]# rmmod ipts
[root@surface]# insmod /lib/modules/5.5.8-1.surface.fc30.x86_64/kernel/drivers/input/touchscreen/ipts/ipts.ko.xz singletouch=y

Was man dann so verewigt:

echo „options ipts singletouch=y“ > /etc/modprobe.d/ipts.conf

Man muß aber wissen, das dann der Stiftsupport abgeschaltet ist. Außerdem ist im 5.5er Kernel die Multitouch-Support komischerweise abgeschaltet, wer das braucht, muß den LTS Kernel 4.19 installieren. Ob das bei einem aktuellen Fedora 30/31/32 eine gute Idee ist, mag ich nicht entscheiden wollen. Allerdings hatte der 5.3er noch Multitouch dabei. Da frage ich mich jetzt, wieso das abgeschaltet wurde.

Weniger Energieverbrauch .. vielleicht

Eine andere Sache, die noch untersucht werden muß, ist der anscheinend geringere Stromverbrauch des 5.5.8 Kernels auf dem Surface Pro 4. zunächst sah es eher nach einem Batteryauslesebug aus, weil das Gerät lange auf 100% blieb, aber mittlerweile könnnte auch ein leichter Einspareffekt vorhanden sein. Ich hab das SP4 noch nicht lange genug im Referenzkernel laufen lassen, um da einen Vergleich zu haben. Ich schau nachher mal.

Kameras gehen immer noch nicht

Tja, schlechte Nachrichten für die NSA, die Kameras der Surface Pro 4+ funktionieren immer noch nicht unter Linux, was an sich jetzt schade für reguläre Kameranutzer ist. Dafür soll das Wifi jetzt im 5G Betrieb stabiler sein, was ja auch nicht ganz unpraktisch ist.

Die Sache mit dem Secure Boot

Nachdem ersten Boot, kommt im Bootprozess eine mördermäßig wichtige Einblendung, die einem bei der Installation auch mitgeteilt wird, allerdings steht im Installationshinweis, daß man, WENN MAN danach gefragt wird, ein Password eingeben soll um den signierten Kernel, bzw. dessen Signatur, ins Bios zu bekommen um dann Secure Boot nutzen können. Tja, was soll ich sagen, die Abfrage kam so nicht, denn dazu muß man während ein Timer runterzählt auf eine Taste drücken, sonst wird man auch nicht nach dem Passwort gefragt 🙂

Da ich da noch unsignierte Kernels zum Testen liegen habe, kann ich SecureBoot eh nicht einschalten, insofern ist mir das auch egal 😉 Wenn der neue Kernel natürlich dauerhaft funktioniert, dann kann man das später immer noch mit Hilfe des mokutil erledigen.

Der TypeCover Bug

Zwar prellt das TypeCover nicht mehr, aber dafür funktioniert es auch nicht mehr, wenn man es abzieht und wieder dran steckt. Was ein Problem darstellt, da man das Surface Pro 4 neu booten muß.

Ihr seht, da werden noch einige Fixe nötig werden, bis das stabil läuft.

Kernel <= 5.5.9 mit USB Bug

Besonders für alle Fans von  Surface Pro Linux-Tablets habe ich eine schlechte Nachricht im Bezug auf den Kernel 5.5.8: einige USB Geräte werden nur beim Booten erkannt, später aber nicht mehr.

Kernel <= 5.5.9 mit USB Bug

Die Liste der betroffenen Geräte dürfte bislang eher übersichtlich sein, da z.B. meine USB Maus oder mein USB Gigabit LAN Adapter  von dem Problem nicht betroffen sind. Über die Ursache ist bislang auch noch nichts bekannt, was aber nicht verwundert, da wir das erst heute Vormittag verifiziert bekommen haben.

Was ist denn überhaupt los?

Wenn man das Gerät mit Kernel 5.5.x bootet, wird das Microsoft eigene TypeCover, das ist die Tastatur und das Mauspad, welches auch als Deckel dient, korrekt als USB Device erkannt und funktioniert entsprechend. Allerdings nur so lange, bis jemand das TypeCover abzieht und wieder dransteckt. Dann funktioniert es nicht mehr.  Dabei ist es egal aus welcher Quelle man den Kernel hat, ob er direkt von Fedora oder selbst gebaut ist.

Wie wirkt sich das aus?

Die Ursache dafür, daß das TypeCover nach dem Einstecken an das Gerät nicht mehr funktioniert ist, daß es überhaupt nie vom USB BUS abgemeldet wurde. Das manifestiert sich darin, daß man mit „lsusb“ das Gerät noch sieht, auch wenn es bereits am anderen Ende der Wohnung liegt. Folglich wir es beim Einstecken nicht initialisiert und kann so seinen Job nicht tun.

Gegenmaßnahmen

Wie schnell so einn Satz wie „Derzeit hilft nur ein Reboot.“ obsolete wird. Der Einsatz von Kernel 5.5.9-200 (Upstreambuild) oder 5.4.19 bzw. jedes anderen 5.4er Kernel ohne Sicherheitslücke löst das Problem auch, weil es da nicht auftritt. Somit wurde auch indirekt bestätigt, daß es nur am Kernelcode liegt und nicht an der Installation oder irgendwelchen UDEV Tricks, die sind bei allen Kernels gleich, weswegen man die aus der Gleichung streichen kann.

Der Nachteil beim 5.4.x Kernel ist allerdings, daß er zu viel Strom verbraucht. Es wurden im Leerlauf 12 W gemessen, wo mit einem für Surface gebaute Kernel nur ~5 W verbraucht werden. Das sich das echt fies auf die Laufzeit auswirkt, dürfte jedem klar sein.

Die derzeit im Test befindliche 5.5.9-100 von Fedora löst das Problem noch NICHT.

Update ( 11:55 Uhr )

Wie das so mit Eilmeldungen ist, der Patch in 5.5.9-2 ist nicht stabil. Ein einem Boot funktioniert USB wieder, im anderen nicht. Ich halte Euch auf dem Laufenden, wenn ich was neues erfahre.

 

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.