easyVDR5 TT-S2 6400 Problem mit der Hardwareerkennung

  • Hallo,

    ich verwende seit Anfang 2020 meine TT-S2 6400 ohne Probleme mit EasyVDR5. Die Module muss man selber kompilieren. Im Laufe der Zeit habe ich mir ein kleines Skript dafür gemacht, weil die Module bei einem Kernelupdate immer wieder kompiliert werden müssen. Damit das nicht immer wieder gemacht werden muss setzt das Skript nicht nur den Kernel sondern auch die dazu gehörigen Sourcen auf Hold. Damit bleibt immer alles was dazugehört auf dem gleichen Stand.

    Hier das Skript "compile_dvb.zip" compile_dvb.zip

    Es ist nur rudimentär, Jeder Schritt wird einzeln abgefragt, damit kann man jederzeit abbrechen und wieder einsteigen. Kann man sicherlich auch besser machen.


    Problem war aber schon von Anfang an bei easyVDR5:

    nach einer Erstinstalltion vom USB-Stick wird die TT-S2 6400 erkannt, aber ohne Treiber halt. Dies wurde später dann getan und funktionierte dann auch. Dabei wurde aber auch ein Kernelupdate mit den passenden Sourcen von mir geladen. Alles OK soweit. Wenn man dann aber eine erneute Hardwareerkennung im Setup auslöste wurde die TT-S2 6400 nicht mehr erkannt. Es kam "unbekanntes DVB Device". Ebenso wurde der IR-Empfänger nicht mehr erkannt. Grund: lspci bringt eine andere Hardware-ID aus als in der Datenbank hinterlegt ist:

    Bei mir ist es 1131:0000

    Ich habe die Datenbank ergänzt (neu: fett und unterstrichen):

    /usr/share/easyvdr/setup/hw-detect/hw-lib/20_video_in_hw

    ->

    # FF-HD-Karte

    hw_name[5]="FF-HD TT-6400"

    hw_ident[5]="1131:7160 \

    13c2:3009 13c2:300a 1131:0000"

    det_method[5]="chk_lspci3"

    ins_method[5]="inst_write-info"

    paraset_a[5]="FF-HD-Karte(TT6400)"

    paraset_b[5]="STD_DRV_NO"

    paraset_c[5]="<empty_value>"

    paraset_d[5]="<empty_value>"

    paraset_e[5]="<empty_value>"


    /usr/share/easyvdr/setup/hw-detect/hw-lib/40_remote_control_receiver

    ->

    # FF-HD-Karte

    hw_name[20]="IR der TT-6400 Karte"

    hw_ident[20]="1131:7160 \

    13c2:3009 13c2:300a 1131:0000"

    det_method[20]="chk_lspci3"

    ins_method[20]="inst_lirc"

    paraset_a[20]="ID_TXT"

    paraset_b[20]="dev_input"

    paraset_c[20]="Event"

    paraset_d[20]="TT6400 DVB IR receiver"

    paraset_e[20]="TT6400 DVB IR receiver"


    Ich habe das analysiert mit der Routine chk_lspci3 aus der Datei chk_lib und dies an der Konsole überprüft:

    chk_lspci3()

    {

    PCI_ID_ARRAY=($@)

    ELEMENT_COUNT=${#PCI_ID_ARRAY[*]}

    echo "Elementcount:" $ELEMENT_COUNT >> hw.txt

    echo "PCI ID Array:" $PCI_ID_ARRAY >> hw.txt


    RET_STATUS=1

    if (($(lspci -n | grep -ic ${PCI_ID_ARRAY[0]}) != 0)); then

    for ((i=1;i<$ELEMENT_COUNT;i++))

    do

    echo "PCI_ID_ARRAY:" ${PCI_ID_ARRAY[$i]} >> hw.txt

    echo "aktiver Index:" $i >> hw.txt

    (($(lspci -nv | grep -i "sub" | grep -ic ${PCI_ID_ARRAY[$i]}) != 0)) && RET_STATUS=0

    ((RET_STATUS == 0)) && break

    done

    fi

    echo "Ergebnis:" $RET_STATUS >> hw.txt

    return $RET_STATUS

    }


    Bei der Stelle wo die sub ID geprüft wird kommt bei mir 1131:0000 an der Konsole raus, warum auch immer.

    Mit den neuen Einträgen in der Datenbank wird die Karte sowie der IR-Empfänger wieder erkannt und die Installation klappt dann auch.

    Ich konnte so über das Hardware Setup den IR-Empfänger auf Lirc Com1 umstellen und wieder zurück auf den IR-Empfänger der TT-S2 6400.
    Hier die Dateien von mir "hw-lib.zip" hw-lib.zip

  • Hi, die beiden Einträge in den Datenbanken ir und dvb Pflege ich nach, bei dem Treiber und Kernel Part kann ich leider nix tun, eventuell hilft da wolfi.m.


    Gruß Aaron

    Mediacenter
    easyVDR4alpha(64-Bit) Gigabyte, Ltd. H97-HD3 mit Intel(R) G3260 @ 3.30GHz 4GB DDRx,Intelgrafik,MATSHITA BD-MLT UJ265 Bluray LW, 2TB Festplatte,LCD+IRTrans-Empfänger,2x SkystarS2 PCI


  • Das ist keine ID irgendeiner Version der S2-6400. Da hast Du Dir den EEPROM auf der Karte zerschossen.

    Danke für den Hinweis, erspare ich mir Arbeit 8)

    Mediacenter
    easyVDR4alpha(64-Bit) Gigabyte, Ltd. H97-HD3 mit Intel(R) G3260 @ 3.30GHz 4GB DDRx,Intelgrafik,MATSHITA BD-MLT UJ265 Bluray LW, 2TB Festplatte,LCD+IRTrans-Empfänger,2x SkystarS2 PCI


  • Hallo Sören,

    OK, aber wie geschieht das, den Eprom zerschiessen? Ich habe nichts an der Karte rumgemacht.


    Und wieso wird die Karte wieder erkannt wenn ich eine Neuinstallation vomUSB-Stick mache, an der iso habe ich ja gar nichts angepasst, sie ist original.

    Damit wird im HW-Setup wieder TT-S2 6400 erkannt. Demnach müsste ja die originale HW-ID wieder funktionieren? Das könnte nicht sein wenn etwas am Eprom auf der Karte dauerhaft zerschossen wäre.

    Ich kann mal Clonezilla booten und mit lspci auslesen ob da was anderes kommt bei einem anderen System/Kernel.

    Oder kann man die Installations-ISO booten und dann auf die Konsole wechseln um das zu testen?

    Komisch ist das schon.

  • Hi,

    du kannst v3.5 im Live-DVD Mode booten zum Test.

    V5 kann das nicht. Oder Ubuntu...


    hwinfo spuckt alles aus.

    MfG,

    Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • OK, aber wie geschieht das, den Eprom zerschiessen?

    Mir ist das schon mal beim Basteln mit PCIe-Adaptern (Projekt siehe hier) passiert. DIe genauen Umstaende sind (natuerlich) nicht klar. Ich wollte solche Fehler auch nicht absichtlich provozieren und da weiter testen.

    Es waren zum Glück nur ein oder 2 Bytes kaputt, die konnte mit i2c-tools wieder fixen.

    Und wieso wird die Karte wieder erkannt wenn ich eine Neuinstallation vomUSB-Stick mache, an der iso habe ich ja gar nichts angepasst, sie ist original.

    Damit wird im HW-Setup wieder TT-S2 6400 erkannt. Demnach müsste ja die originale HW-ID wieder funktionieren? Das könnte nicht sein wenn etwas am Eprom auf der Karte dauerhaft zerschossen wäre.

    Ich habe keinerlei Ahnung von Easyvdr und damit auch nicht von der dortigen Hardwareerkennung.

    Fuer mich sah es so aus, als ob eine neue ID in die Datenbank eingetragen werden soll, damit die Karte wieder erkannt wird (weil sie jetzt diese PCI-ID hat). Insbesondere:

    lspci bringt eine andere Hardware-ID aus als in der Datenbank hinterlegt ist

    kam mir bekannt vor. Heisst das, lspci gibt nach jedem Reboot andere PCI-IDs fuer die Karte aus?

    Denkbar ist schon, dass ein EEPROM etwas durcheinander kommt, wenn man mitten im Schreibzyklus die Power wegnimmt. Aber ein beliebiges anders Hardwareproblem kann ich natuerlich nicht ausschliessen.


    Gruss,

    S:oren

  • Hallo S:oren,


    vielen Dank für die Hinweise. Ich habe gerade Clonezilla gebootet und lspci -v -n gemacht.

    Dann wieder easyVDR 5 (Ubuntu 20.04 im Unterbau) gebootet, also der gleiche PC mit der selben TT-S2 6400 und da auch lspci -v -n gemacht.

    Hier das Ergebnis:

    Clonezilla:

    ---------------------------------------------------------------------


    03:00.0 0480: 1131:7160 (rev 02)

    Subsystem: 13c2:300a

    Flags: bus master, fast devsel, latency 0, IRQ 11, NUMA node 0

    Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

    Capabilities: [40] MSI: Enable- Count=1/32 Maskable- 64bit+

    Capabilities: [50] Express Endpoint, MSI 00

    Capabilities: [74] Power Management version 2

    Capabilities: [80] Vendor Specific Information: Len=50 <?>

    Capabilities: [100] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>


    Und das kommt bei EasyVDR5 (Ubuntu 20.04):

    ---------------------------------------------------------------------


    03:00.0 0480: 1131:7160 (rev 02)

    Subsystem: 1131:0000

    Flags: bus master, fast devsel, latency 0, IRQ 27, NUMA node 0

    Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

    Capabilities: [40] MSI: Enable+ Count=1/1 Maskable- 64bit+

    Capabilities: [50] Express Endpoint, MSI 00

    Capabilities: [74] Power Management version 2

    Capabilities: [80] Vendor Specific Information: Len=50 <?>

    Capabilities: [100] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

    Kernel driver in use: SAA716x FF

    Kernel modules: saa716x_ff


    Einziger Unterschied ist die ID und diese Zeile Capabilities: [40] MSI...


    Nochmal:

    wenn man EasyVDR5 neu installiert mit der ISO wird dieselbe TT-S2 6400 wieder erkannt !!! Das kann nur geschehen wenn lspci dann wieder die korrekte ID ausgibt.

    Wenn man dann weitermacht mit der Installation von EasyVDR5 mitsamt Kernelupdate (alles vom Ubuntu 20.04 repository) und manuelles Module kompilieren für die TT-S2 6400 und laden der Module wird danach die Karte im Hardware-Setup von EasyVDR nicht mehr erkannt !!! lspci bringt nun eine andere ID !!!


    Grund kann keinesfalls EasyVDR sein oder die Hardware selbst, das belegt oben das Ergebnis !!!

    Es muss also etwas damit zu tun haben welcher Kernel läuft oder wie ich die Module erzeugt habe.

    Wieso sonst bringt plötzlich lspci eine andere ID als Subsystem? Die Karte funktioniert ja korrekt und unter einem anderen System wird die richtige ID wieder erkannt. Das kann doch nicht der Eprom sein, oder wird der vom aktuellen Linuxsystem umgeschrieben? Kann ich mir nicht vorstellen.

    Ich werde als nächstes mal ein Ubuntu 20.04 booten und lspci wieder prüfen.

    Hast du noch eine Idee für das unterschiedliche Verhalten von lspci auslösen könnte?

    Verwendest du eine TT-S2 6400 unter Ubuntu 20.04 schon so dass ich mir den Aufwand nicht antun müsste?

  • Hallo S:oren,


    hab gerade noch unter EasyVDR anstatt lspci den Befehl hwinfo ausgeführt.


    hwinfo :


    >> pci.2: get sysfs pci data

    pci device: name = 0000:03:00.0

    path = /devices/pci0000:00/0000:00:0b.0/0000:03:00.0

    modalias = "pci:v00001131d00007160sv000013C2sd0000300Abc04sc80i00"

    class = 0x48000

    vendor = 0x1131

    device = 0x7160

    subvendor = 0x13c2

    subdevice = 0x300a

    irq = 27

    res[0] = 0xfbf00000 0xfbffffff 0x140204

    config[64]


    direkt danach nochmal lspci -vvv -nn :


    03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160 [1131:7160] (rev 02)

    <------>Subsystem: Philips Semiconductors SAA7160 [1131:0000]

    <------>Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+

    <------>Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

    <------>Latency: 0, Cache Line Size: 64 bytes

    <------>Interrupt: pin A routed to IRQ 27

    <------>NUMA node: 0

    <------>Region 0: Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

    <------>Capabilities: [40] MSI: Enable+ Count=1/1 Maskable- 64bit+

    <------><------>Address: 00000000fee01004 Data: 402b

    <------>Capabilities: [50] Express (v1) Endpoint, MSI 00

    <------><------>DevCap:>MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us

    <------><------><------>ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W

    <------><------>DevCtl:>CorrErr- NonFatalErr- FatalErr- UnsupReq-

    <------><------><------>RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

    <------><------><------>MaxPayload 128 bytes, MaxReadReq 128 bytes

    <------><------>DevSta:>CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-

    <------><------>LnkCap:>Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us

    <------><------><------>ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

    <------><------>LnkCtl:>ASPM Disabled; RCB 128 bytes Disabled- CommClk-

    <------><------><------>ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

    <------><------>LnkSta:>Speed 2.5GT/s (ok), Width x1 (ok)

    <------><------><------>TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

    <------>Capabilities: [74] Power Management version 2

    <------><------>Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)

    <------><------>Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

    <------>Capabilities: [80] Vendor Specific Information: Len=50 <?>

    <------>Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

    <------>Kernel driver in use: SAA716x FF

    <------>Kernel modules: saa716x_ff


    Man beachte fett markierte Angaben.
    Das würde bedeuten lspci gibt was anderes aus als hwinfo !!!


    @gb:

    Den Eintrag 1131:0000 würde ich nicht in die Datenbank von easyVDR aufnehmen, es bedeutet ja dass die Ausgabe von lspci falsch wäre oder?

    hwinfo gibt es korrekt aus.


    S:oren :

    Was hälst du davon? Eine Idee warum lspci was anderes ausgibt? Hab schon von lspci die neuesten Sourcen 3.7.0 geholt und kompiliert, es kommt als Subsystem auch 1131:0000 raus anstatt wie bei hwinfo 13c2:300a.

  • Jetzt wird die Sache schon etwas klarer.

    03:00.0 0480: 1131:7160 (rev 02)

    Subsystem: 13c2:300a

    Das sind die richtigen PCI-IDs (aus dem EEPROM):

    Vendor:Device 1131:7160 (Philips, SAA7160)

    Subvendor:Subdevice 13c2:300a (Technotrend, S2-6400 Production Version)

    Auf diese IDs wird der Treiber gematcht und offenbar auch geladen.

    03:00.0 0480: 1131:7160 (rev 02)

    Subsystem: 1131:0000

    Das sind die Hardware-IDs der PCIe-Bridge, wenn sie keinen EEPROM erkennt. Diese IDs sollten nicht auftauchen, insbesondere wenn der Treiber schon mit Hilfe der richtigen IDs geladen wurde.

    Es muss also etwas damit zu tun haben welcher Kernel läuft

    Welcher ist es denn?

    Das kann doch nicht der Eprom sein, oder wird der vom aktuellen Linuxsystem umgeschrieben?

    Nein.

    Wieso sonst bringt plötzlich lspci eine andere ID als Subsystem? Die Karte funktioniert ja korrekt und unter einem anderen System wird die richtige ID wieder erkannt.

    Das ist offenbar ein Bug. Wo genau der zu suchen ist, ist nun die Frage.


    Gruss,

    S:oren

  • Hallo S:oren,


    ich habe die Module mit meinem Script kompiliert. Im Prinzip basiert es auf deine Hinweise die ich im vdr portal gefunden hatte.

    Es klappte damit auch ohne Fehler, die Karte funktioniert.

    Vor dem kompilieren musste ich die kernel sourcen vom Ubuntu repository holen, aber weil man da immer den letzten Stand bekommt

    hat dieser nicht zum vorinstallierten kernel von easyVDR5 gepasst, also habe ich ein upgrade gemacht. Nach einem reboot passte dann

    kernelversion zur sourceversion. Danach habe ich im Prinzip deine Anleitung hoffentlich richtig befolgt.


    Die kernelversion ist bei mir aktuell diese:

    uname -r ->

    5.4.0-54-generic


    Damit kommt diese Ausgabe:

    lspci -vvv -nn ->

    03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160 [1131:7160] (rev 02)

    Subsystem: Philips Semiconductors SAA7160 [1131:0000]

    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+

    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

    Latency: 0, Cache Line Size: 64 bytes

    Interrupt: pin A routed to IRQ 27

    NUMA node: 0

    Region 0: Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

    Capabilities: [40] MSI: Enable+ Count=1/1 Maskable- 64bit+

    Address: 00000000fee01004 Data: 402b

    Capabilities: [50] Express (v1) Endpoint, MSI 00

    DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us

    ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W

    DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-

    RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

    MaxPayload 128 bytes, MaxReadReq 128 bytes

    DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-

    LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us

    ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

    LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk-

    ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

    LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)

    TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

    Capabilities: [74] Power Management version 2

    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)

    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

    Capabilities: [80] Vendor Specific Information: Len=50 <?>

    Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

    Kernel driver in use: SAA716x FF

    Kernel modules: saa716x_ff


    Der vorinstallierte kernel ist ja auch noch im grub, also habe ich den mal gebootet (hier habe ich keine module kompiliert):

    uname -r ->

    5.4.0-26-generic


    Damit kommt diese Ausgabe, mit der richtigen Sub-ID:

    lspci -vvv -nn ->

    03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160 [1131:7160] (rev 02)

    Subsystem: Technotrend Systemtechnik GmbH SAA7160 [13c2:300a]

    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-

    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

    Latency: 0, Cache Line Size: 64 bytes

    Interrupt: pin A routed to IRQ 11

    NUMA node: 0

    Region 0: Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

    Capabilities: [40] MSI: Enable- Count=1/32 Maskable- 64bit+

    Address: 0000000000000000 Data: 0000

    Capabilities: [50] Express (v1) Endpoint, MSI 00

    DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us

    ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W

    DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-

    RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

    MaxPayload 128 bytes, MaxReadReq 128 bytes

    DevSta: CorrErr- NonFatalErr+ FatalErr- UnsupReq+ AuxPwr- TransPend-

    LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us

    ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

    LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk-

    ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

    LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)

    TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

    Capabilities: [74] Power Management version 2

    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)

    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

    Capabilities: [80] Vendor Specific Information: Len=50 <?>

    Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>


    Man beachte dass lspci mit kernel 5.4.0-26-generic wieder die richtige sub-ID ausgibt.

    Allerdings werden hier auch keine module geladen.


    Mit kernel 5.4.0-54-generic bringt lspci die falsche sub ID aus. Allerdings sind hier die nachkompilierten module bereits geladen.

    Also habe ich den vdr gestoppt und mit rmmod saa716x_ff entladen. Dann kommt das raus:


    lspci -vvv -nn:

    03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160 [1131:7160] (rev 02)

    Subsystem: Philips Semiconductors SAA7160 [1131:0000]

    Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-

    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

    Interrupt: pin A routed to IRQ 19

    NUMA node: 0

    Region 0: Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

    Capabilities: [40] MSI: Enable- Count=1/1 Maskable- 64bit+

    Address: 0000000000000000 Data: 0000

    Capabilities: [50] Express (v1) Endpoint, MSI 00

    DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us

    ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W

    DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-

    RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

    MaxPayload 128 bytes, MaxReadReq 128 bytes

    DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-

    LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us

    ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

    LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk-

    ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

    LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)

    TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

    Capabilities: [74] Power Management version 2

    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)

    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

    Capabilities: [80] Vendor Specific Information: Len=50 <?>

    Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

    Kernel modules: saa716x_ff


    Immer noch die falsche sub ID.


    Ein Vergleich deckt auf dass noch etwas anderes angezeigt wird:

    bei kernel 5.4.0-26-generic:

    DevSta: CorrErr- NonFatalErr+ FatalErr- UnsupReq+ AuxPwr- TransPend-

    bei kernel 5.4.0-54-generic:

    DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-


    Leider kann ich die sourcen zu 5.4.0-26-generic nicht finden.

    Ich könnte jedoch einfach mal mit den vorhandenen sourcen 5.4.0-54-generic dies unter dem kernel 5.4.0-26-generic kompilieren und schauen was dabei rauskommt.


    Was meinst du?

  • Hi,

    Isr nicht gerade der. 80 released worden mit vielen Problemen zumindest was ich in anderen Distris mitbekommen habe? Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Hallo Sören, Hallo SurfaceCleanerZ,


    der neue Treiberpatch funktioniert!


    Folgendes habe ich zuerst erprobt:

    zuerst nur den neuesten Kernel vom Ubuntu repository geholt:

    uname -r

    5.4.0-60-generic


    Die Pakete und Sourcen dazu vom repository:

    linux-generic : Version: 5.4.0.60.63

    linux-image-generic : Version: 5.4.0.60.63

    linux-headers-generic: Version: 5.4.0.60.63

    linux-source : Version: 5.4.0.60.63


    Reboot mit neuem Kernel.


    Ich habe keinen neuen Treiber Patch verwendet sondern den alten Stand wie bisher und die Module neu kompiliert (mit meinem Skript).

    lspci -vvv -nn:

    03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160 [1131:7160] (rev 02)

    Subsystem: Philips Semiconductors SAA7160 [1131:0000]

    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+

    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

    Latency: 0, Cache Line Size: 64 bytes

    Interrupt: pin A routed to IRQ 27

    NUMA node: 0

    Region 0: Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

    Capabilities: [40] MSI: Enable+ Count=1/1 Maskable- 64bit+

    Address: 00000000fee01004 Data: 402b

    Capabilities: [50] Express (v1) Endpoint, MSI 00

    DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us

    ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W

    DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-

    RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

    MaxPayload 128 bytes, MaxReadReq 128 bytes

    DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-

    LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us

    ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

    LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk-

    ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

    LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)

    TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

    Capabilities: [74] Power Management version 2

    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)

    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

    Capabilities: [80] Vendor Specific Information: Len=50 <?>

    Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

    Kernel driver in use: SAA716x FF

    Kernel modules: saa716x_ff


    Also das war nicht die Lösung nur den neueren Kernel zu laden.

    Nun den neuen Treiber Patch geholt und mit meinem Skript erneut die Module kompiliert, Reboot.

    Danach lspci geprüft:


    03:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7160 [1131:7160] (rev 02)

    Subsystem: Technotrend Systemtechnik GmbH SAA7160 [13c2:300a]

    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+

    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

    Latency: 0, Cache Line Size: 64 bytes

    Interrupt: pin A routed to IRQ 27

    NUMA node: 0

    Region 0: Memory at fbf00000 (64-bit, non-prefetchable) [size=1M]

    Capabilities: [40] MSI: Enable+ Count=1/32 Maskable- 64bit+

    Address: 00000000fee01004 Data: 402c

    Capabilities: [50] Express (v1) Endpoint, MSI 00

    DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us

    ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 0.000W

    DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-

    RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-

    MaxPayload 128 bytes, MaxReadReq 128 bytes

    DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-

    LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us

    ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-

    LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk-

    ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

    LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)

    TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

    Capabilities: [74] Power Management version 2

    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-)

    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

    Capabilities: [80] Vendor Specific Information: Len=50 <?>

    Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?>

    Kernel driver in use: SAA716x FF

    Kernel modules: saa716x_ff


    Damit kommt die richtige Sub ID.

    Die Hardware-Erkennung von EasyVDR5 klappt nun auch wieder mit der original Datenbank ohne den Eintrag 1131:0000.


    Also nochmal den älteren Kernel 5.4.0-54-generic gebootet:

    lspci bringt wieder die falsche Sub-ID 1131:0000

    Dann den neuen Treiber-Patch kompiliert für diesen Kernel.

    vdr gestoppt

    rmmod saa716x_ff zum entladen

    lsmod zeigte an dass es auch entladen war

    modprobe saa716x_ff zum laden

    lspci brint immer noch die falsche Sub-ID 1131:0000 obwohl der neu kompilierte Treiber geladen wurde.

    Reboot und erneuter boot mit kernel 5.4.0-54-generic

    lspci zeigt nun die korrekte Sub-ID an !

    -> OK der neue Treiberpatch ist die Lösung. Es wird zwingend ein reboot des kernels nötig.


    Noch eine Kleinigkeit zum kompilieren:

    Beim kompilieren der Module mit meinem Skript trat noch ein Fehler auf:

    ...

    The next patch would create the file Documentation/media/uapi/dvb/audio-get-pts.rst,

    which already exists! Assume -R? [n]

    usw...

    ...

    Ich habe bereits das versucht:

    - /usr/src/linux-source-5.4.0 -> make clean -> keine Abhilfe

    - make distclean -> keine Abhilfe

    - patch --forward -p1 -> keine Abhilfe: führt dazu dass alle Patchbefehle übersprungen werden, selbst die welche noch nicht vorhanden sind in saa716x_boot.c war immer noch die Greg-Zeile drin obwohl sie mit dem neuen Patch verschwinden sollte. Der Patch wirkte also nicht.

    - /usr/src/linux-source-5.4.0 von Hand gesäubert, alle Verzeichnisse bis auf die debian-Verzeichnisse und die tar.bz2 zum entpacken der Sourcen. Nur damit hat das Patchen wieder funktioniert wenn man auf leere Verzeichnisse neu entpackt.

    Das bedeutet: wenn schon mal gepatch wurde dann kann man nicht nochmal einen anderen Patch darauf anwenden. Habe ich das so richtig verstanden?

    Wie macht ihr das richtig?

    Ich kann natürlich mit meinem Skript auch alles löschen vor dem entpacken und patchen. Soll ich das so tun?




  • der neue Treiberpatch funktioniert!

    Da bin ich ja froh, dass wenigstens der Fix fuer meinen Treiberbug nicht kompletter Bloedsinn ist. ;-)

    Es wird zwingend ein reboot des kernels nötig.

    Eigentlich ein Reset der S2-6400, z.B. durch Neuladen des PCIe-Hostcontroller-Treiber-Moduls. Aber Reboot tut's auch, ist einfacher, und wird sowieso nie wieder gebraucht, wenn man nur den gefixten Treiber verwendet.

    Das bedeutet: wenn schon mal gepatch wurde dann kann man nicht nochmal einen anderen Patch darauf anwenden.

    Einen anderen Patch schon. Sinnvollerweise nicht nochmal den selben (ersten Teil).

    Ich kann natürlich mit meinem Skript auch alles löschen vor dem entpacken und patchen. Soll ich das so tun?

    Finde ich sinnvoll. Ein Update fuer einen ueber ein Jahr alten Treiberbranch ist kommt ja nicht so oft vor, dass man dafuer speziell optimieren muesste.


    Gruss,

    S:oren