TT-premium s2-6400: "BUG: unable to handle page fault for address X"

  • Hallo zusammen!


    Nachdem mein VDR basierend auf Ubuntu 14.04 nicht mehr startete, dachte ich es sei an der Zeit wieder einen neuen aufzubauen.


    Nach etwas Recherche habe ich begonnen, die Ubuntu 20.04 zu installieren und die Kernelsourcen zu laden.

    Nach dem Patchen der Sourcen konnte ich auch die beiden Kernelmodule "saa716x_ff" und "saa716x_core" zu bauen (wie steht hier) und (wenn die Firmware der Karte noch nich unter /lib/firmware liegt) auch laden.


    Nachdem dann die Firmware unter /lib/firmware abgelegt wurde, crasht es beim Laden des Moduls (syslog-Auszug im Anhang):



    Hat jemand von euch eine Idee wie ich da weiter komme? Danke!


    Mein Umgebung:

    • Asus M3M78-EM mit Phenom II 1045T und 8GB ECC RAM
    • Ubuntu Server 20.04 LTS
    • Linux vdr3 5.4.0-48-generic #52-Ubuntu SMP Thu Sep 10 10:58:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
    • Tuner: TT-premium s2-6400 (1 Stück)
  • Nach dem Patchen der Sourcen konnte ich auch die beiden Kernelmodule "saa716x_ff" und "saa716x_core" zu bauen (wie steht hier)

    Hast Du überall 4.15 aus der Anleitung durch 5.4 für den neuen Kernel ersetzt?

    Nach dem log scheinen die neu gebauten Module nicht zum originalen dvb_core zu passen.


    Gruss,

    S:oren

  • Hallo S:oren, danke für die Antwort, habe noch mal die Kernel-Quellen im ~ gelöscht, neu entpackt, gepacht, übersetzt und siehe da: es geht:


    Und sie da - es funktioniert:

    Danke, S:oren!


    Quote

    Nach dem log scheinen die neu gebauten Module nicht zum originalen dvb_core zu passen.

    Woran sieht man das? Weil die Zugriffsverletzung auftritt?

  • Da hat sich also kuerzlich die Kernelversion geaendert (5.4.0-48-generic -> 5.4.0-51-generic). Da haben vielleicht die heruntergeladenen Sourcen nicht zum laufenden Kernel gepasst.


    Woran sieht man das?

    Die Call-Chain sieht gut aus:

    Oct 13 10:40:32 vdr3 kernel: [ 1126.467809] dvb_create_tsout_entity+0xac/0x180 [dvb_core]

    Oct 13 10:40:32 vdr3 kernel: [ 1126.467835] dvb_register_device+0x1ec/0x5e0 [dvb_core]

    Oct 13 10:40:32 vdr3 kernel: [ 1126.467862] dvb_dmxdev_init+0x10a/0x160 [dvb_core]

    Oct 13 10:40:32 vdr3 kernel: [ 1126.467887] saa716x_dvb_init+0x16f/0x390 [saa716x_core]

    Oct 13 10:40:32 vdr3 kernel: [ 1126.467913] saa716x_ff_pci_probe.cold+0x3b7/0x6b8 [saa716x_ff]


    Dann chrasht es tief im dvb_core:
    Oct 13 10:40:32 vdr3 kernel: [ 1126.467664] ? dvbdmx_remove_frontend+0x20/0x70 [dvb_core]

    Oct 13 10:40:32 vdr3 kernel: [ 1126.467693] ? dvb_dmx_swfilter_raw+0x70/0x70 [dvb_core]

    Oct 13 10:40:32 vdr3 kernel: [ 1126.467719] media_device_register_entity+0x77/0x1d0 [mc]


    Das media_device_register_entity geht anscheinend schief, weil dann ja dvbdmx_remove_frontend kommt (register->remove) und der Crash. Der Core selbst wird nicht kaputt sein, also passen wohl irgendwelche Datenstrukturen nicht zusammen. Moegliche Ursachen sind andere Kernelconfig, andere Header (anderer Patchstand), andere Compilerversion.


    Gruss,

    S:oren

  • Code
    1. Da hat sich also kuerzlich die Kernelversion geaendert (5.4.0-48-generic -> 5.4.0-51-generic). Da haben vielleicht die heruntergeladenen Sourcen nicht zum laufenden Kernel gepasst.

    Die von mir geladenen Kernel-Quellen enthalten schon die 5.4.0-51-generic Signatur, zum Download-Zeitpunkt lief noch der 5.4.0-48-generic Kernel. Auch beim Testen und dem Crash...

  • Ich habe gerade mal etwas mit dem Treiberbau gespielt (aber keine Karte zum Ausprobieren) - vielleicht kann mal jemand mit passender Hardware schauen, ob es genügt die Module aus drivers/media/pci/saa716x/ gezielt bauen zu lassen - das sollte die Build-Zeiten gegenüber dem Ansatz die aktuell vom System geladenen Module mit zu bauen verkürzen und auch Funktionieren, wenn es auf dem Build-System keine passende S2-6400 FF Karte gibt:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    The post was edited 2 times, last by seahawk1986: es muss M= statt -M heißen und Pfad für symvers Datei korrigiert ().

  • Also ich habs mal probiert.


    Zeile 8 habe habe ich angepasst:

    cp /usr/src/linux-headers-5.4.0-51-generic/Module.symvers .


    Zeile 12 wirft einen Fehler: der Schalter "-M"

    Code
    1. vdruser@vdr3:~/linux-saa716x/linux-source-5.4.0$ make KERNELVERSION=5.4.0-51-generic -j6 -M drivers/media/pci/saa716x/ modules
    2. make: invalid option -- 'M'
    3. Usage: make [options] [target] ...
    4. Options:
    5. -b, -m Ignored for compatibility.
    6. ...
    7. ...

    Welche Funktion soll -M einschalten?

    Anbei noch die Ausgaben der make-Befehle

    make_oldconfig.txt

    make_modules_prepare.txt

    make_modules.txt

  • das sollte die Build-Zeiten gegenüber dem Ansatz die aktuell vom System geladenen Module mit zu bauen verkürzen

    In meinem originalen Vorschlag hatte ich ein 'make localyesconfig' drin, damit eben nicht alle Module aus der Originaldistribution mit gebaut werden muessen (wie es in der kopierten Distro-config steht). Dann werden nur eine Hand voll ueberzaehlige Module gebaut (wo es keine y-Option gibt).

    Wenn man dann automatisch die saa716x-Module bauen will, koennte man die 2 oder 4 saa716x-Optionen noch per Skript in die .config eintragen. Das hatte ich so nicht vorgeschlagen, weil es wieder eine zusaetzliche Fehlerquelle ist. Aber gehen sollte es.


    Gruss,

    S:oren

  • Ups, das sollte make KERNELVERSION=5.4.0-51-generic -j6 M=drivers/media/pci/saa716x/ modules heißen, ich habe es im obigen Post angepasst.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Mit dem make-Kommando von Post oberhalb gehts:

    Die erzeugte Module unterscheiden sich von den zuvor von mir manuell erzeugten. Sie lassen sich aber laden:


    Frage:

    Der "/" am Ende des Pfades in M=drivers/media/pci/saa716xkönnte weggelassen werden, oder?
    Bauen der Module und auch das Laden der erzeugten funktioniert dann auch und beim Build wird nicht
    CC [M] drivers/media/pci/saa716x//saa716x_dma.o

    sondern

    CC [M] drivers/media/pci/saa716x/saa716x_dma.o

    ausgegeben.

  • Der "/" am Ende des Pfades in M=drivers/media/pci/saa716xkönnte weggelassen werden, oder?

    Ich denke schon - wenn mehrere Slashes aufeinander folgen, werden die effektiv zu einem einzelnen Pfadtrenner zusammengezogen, so dass das keine funktionalen Auswirkungen haben sollte.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)