Wie compiliert man einen einzelnen Kernel Treiber neu?

[nudgegoonies]

Hallo,
ich war Opfer des Backport-Kernel-Desasters. Nach dem Update von 4.3 auf 4.4 stand ich auf einmal ohne Sound da. Der Emu10K1 Treiber und ein paar andere Treiber (diverse Nicht-Sound-Geräte) wurden für den 4.4 Kernel deaktiviert. Ab 4.5 geht laut den beiden Debian Bug Reports wieder alles. Aber den Kernel gibt es ja noch nicht in den Backports. Einer im Bugreport berichtet, dass es bei Fedora ab 4.5 auch wieder geht. Ich habe natürlich zurück auf 4.3 gewechselt und warte bis 4.5 in die Backports kommt. Jetzt aber zum eigentlichen Thema:

Bevor ich wusste, dass der Treiber mit 4.4 nicht funktionieren kann, habe ich versucht für den 4.4 Kernel nur den Emu10K1 Treiber zu compilieren. Die Suchmaschine hat mich auf viele Seiten geschickt, aber ich habe wirklich keine gefunden, die einen Weg beschrieben hat, der bei funktioniert hat. Darum meine Frage. Wie compiliert man grundsätzlich einen einzelnen Treiber für den aktuell installierten Kernel neu (wegen einem Bugfix oder weil das Modul fehlt und in der .config vom Debian Kernel Maintainer deaktiviert war)?

[DeletedUserReAsG]

https://wiki.archlinux.org/index.php/Co ... nel_module (uvm.)?

Die Frage ist eher: ist das Modul im baubaren Zustand in den Sourcen und der Paketebauer hat’s beim Kernelbau deaktiviert, oder ist’s direkt rausgeflogen oder nicht baubar? Ich habe von ’nem Desaster nix mitbekommen ….

[KBDCALLS]

Die fehlen auch schon in Testing. Im Source sind die Treiber aber vorhanden.

[nudgegoonies]

Erst mal danke für die Antworten. Die Anleitung in Arch sieht nochmal anders aus als das, was ich bisher gefunden habe. Ich werde es einmal mit einem anderen Treiber ausprobieren. Aber mit dem Emu10K1 Treiber hat es keinen Zweck. Der braucht Kerneloptionen, die beim Debian-Kernel 4.4 abgeschaltet sind und nicht als Modul compiliert werden können.

OT: Hier ist ein Link zu einem der 6 Bugreports zu dem Thema. Selbst Linus Torvalds selber schreibt dort. Ich denke es sind deshalb so viele Reports, weil auch einige Audigy Karten auf Emu10K1 basieren. Die sind als Hifi Karten weit verbreitet und selbst gebraucht noch ziemlich teuer:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=815787

[KBDCALLS]

Linus hat sich aber auch in dem Bugreport selbst zu Wort gemeldet und meint es liegt an der Kernelkonfig von Debian , ansonsten an nichts anderem.

• If I read this right, this seems to be a Debian kernel configuration
  choice rather than anything else.
  
  Does it work if you just compile your own kernel?

Eventuell mal selber einen Kernel kompilieren. Das Make des Kernels ist ja in der Lage Debianpakete zu erstellen.

Ps: Hab mal gerade mir die Dateiliste des 686 Kernels angesehen. und da sind die Module dabei.

• Code: Alles auswählen

  /lib/modules/4.4.0-1-686/kernel/sound/pci/emu10k1/snd-emu10k1-synth.ko
  /lib/modules/4.4.0-1-686/kernel/sound/pci/emu10k1/snd-emu10k1.ko
  /lib/modules/4.4.0-1-686/kernel/sound/pci/emu10k1/snd-emu10k1x.ko

[nudgegoonies]

Ich bin vorhin auch darauf gestoßen, dass Ubuntu das Problem beim 4.4.0-6 Kernel gefixed hat:
https://bugs.launchpad.net/ubuntu/+sour ... ug/1534647

Interessant ist auch, dass beim Debian Bug das "wont fix" wieder entfernt wurde.

Beim Ubuntu Report steht, dass es am neuen Parameter CONFIG_ZONE_DEVICE liegt bzw. am fehlenden CONFIG_ZONE_DMA. Die schließen sich gegenseitig aus. Ich probiere es mal mit Deinem Tip und pass die CONFIG an. 32 BIT kann es eigentlich gar nicht betreffen, weil es dabei um DMA Transfers innerhalb der 4GB geht, bzw. um das double-buffering wenn sie außerhalb der 4GB liegen. Und da ist bei 32 BIT ja eh Schluss.

Oh Mann. Das letzte mal habe ich den Kernel auch wegen dem EMU10K1 Treiber neu compiliert und gehofft es nie wieder tun zu müssen. Die Hardware hat einen Bug und kann DMA Transfers nur innerhalb von 2GB und CONFIG_ZONE_DMA war global auf 4GB gestellt. Das wurde irgendwann gefixed, dass die Geräte selber den Bereich angeben konnten, innerhalb dessen sie es können.

[KBDCALLS]

Offen gestanden frage ich mich manchmal was so mancher Maintainer raucht. Wäre übrigens mal interessant die Kernelkonfigs zu vergleichen. Von Ubuntu und Debian.

[nudgegoonies]

Oder sie sind seit Jahren im Urlaub und kriege nicht mit, dass man ihnen schon einen Patch für eine neuere Version im Bugreport geliefert hat. Naja, anderes Paket, andere Geschichte.

Es ist mir zu spät noch mal alle Bugreports noch mal durchzulesen und zu diffen. Compilierung läuft und morgen werden wir sehen. Danke Dir

[nudgegoonies]

Fast vergessen hier zu schreiben, es läuft wieder. Es war nur die eine Option nötig. CONFIG_ZONE_DMA=y. Ich habe die config vom installierten 4.4.6 in den entpackten kernel als .config kopiert und make oldconfig eingegeben. Und dann fragte er mich nach all den 15,16 oder 17 Treibern, die das brauchen.

[rendegast]

Code: Alles auswählen

ii  linux-image-3.16.0-4-amd64                                  3.16.7-ckt20-1+deb8u4                amd64
ii  linux-image-4.3.0-0.bpo.1-amd64                             4.3.5-1~bpo8+1                       amd64
ii  linux-image-4.4.0-0.bpo.1-amd64                             4.4.6-1~bpo8+1                       amd64
ii  linux-image-4.5.0-trunk-amd64                               4.5-1~exp1                           amd64


# grep -i ZONE_ /boot/config-*
/boot/config-3.16.0-4-amd64:CONFIG_ZONE_DMA32=y
/boot/config-3.16.0-4-amd64:CONFIG_ZONE_DMA=y
/boot/config-3.16.0-4-amd64:CONFIG_ZONE_DMA_FLAG=1

/boot/config-4.3.0-0.bpo.1-amd64:CONFIG_ZONE_DMA32=y
/boot/config-4.3.0-0.bpo.1-amd64:CONFIG_ZONE_DMA=y
/boot/config-4.3.0-0.bpo.1-amd64:CONFIG_ZONE_DMA_FLAG=1

/boot/config-4.4.0-0.bpo.1-amd64:CONFIG_ZONE_DMA32=y
/boot/config-4.4.0-0.bpo.1-amd64:# CONFIG_ZONE_DMA is not set
/boot/config-4.4.0-0.bpo.1-amd64:CONFIG_ZONE_DMA_FLAG=0
/boot/config-4.4.0-0.bpo.1-amd64:CONFIG_ZONE_DEVICE=y

/boot/config-4.5.0-trunk-amd64:CONFIG_ZONE_DMA32=y
/boot/config-4.5.0-trunk-amd64:# CONFIG_ZONE_DMA is not set
/boot/config-4.5.0-trunk-amd64:CONFIG_ZONE_DMA_FLAG=0
/boot/config-4.5.0-trunk-amd64:CONFIG_ZONE_DEVICE=y

dito auch die rt-Kernel.
(die bei redhat wohl (noch?) mit dem älteren Verhalten eingestellt sind)

Ist das nicht auch ein Sicherheitsding, nicht nur evolutionär,
sodaß die Distributions-Maintainer erstmal gekniffen sind?

[KBDCALLS]

Anscheinend ist das mehr für Server gedacht.

• http://wiki.hetzner.de/index.php/Kernel ... o_Linux%29

Das ist ne Konfig für Kernel 2.6.39