Posts by S:oren

  • [gelöst] easyVDR5 TT-S2 6400 Problem mit der Hardwareerkennung

    momit wrote:

    der neue Treiberpatch funktioniert!

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

    momit wrote:

    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.

    momit wrote:

    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).

    momit wrote:

    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

  • [gelöst] easyVDR5 TT-S2 6400 Problem mit der Hardwareerkennung

    Jetzt wird die Sache schon etwas klarer.

    momit wrote:

    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.

    momit wrote:

    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.

    momit wrote:

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

    Welcher ist es denn?

    momit wrote:

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

    Nein.

    momit wrote:

    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

  • [gelöst] easyVDR5 TT-S2 6400 Problem mit der Hardwareerkennung

    momit wrote:

    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.

    momit wrote:

    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:

    momit wrote:

    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

  • TT S2-6400 - Bildstoerung bei gleichzeitigen HD Aufnahmen

    Ach ja, mit nur einem (funktionierenden) Antennenkabel kann man bei der Karte auch auf dem zweiten Frontend empfangen, wenn Band und Polarisation übereinstimmen. Das erschwert die Fehlersuche sehr, wenn man einen Wackelkontakt oder Kurzschluss auf einem Antennenkabel hat. Zu lange Innenleiter am F-Stecker spielen da z.B. gerne mal einen Streich.


    Aber Virtualisierung und NFS bringen noch weitere mögliche Fehlerquellen. Ohne Kristallkugel wird es schon schwer, aus allgemeinen "Bildstörungen" zu einer fundierten Fehler-Fern-Diagnose zu kommen...


    Gruss,

    S:oren

  • TT S2-6400 - Bildstoerung bei gleichzeitigen HD Aufnahmen

    Die S2-6400 hat keinen HW-PID-Filter, der Karte ist also völlig egal, ob SD oder HD empfangen werden soll. Es wandert immer der ganze Transportstream der Transponder über den PCIe-Bus (auch dann doppelt, wenn auf beiden Frontends der selbe Transponder empfangen wird).


    In einer virtuellen Maschine habe ich so eine Karte noch nie betrieben, sieht für mich aber eher nach einem Problem mit den Antennen aus. Und ja, 2 verschiedene Antennen brauchen natürlich auch zwei mal Strom für die LNBs (und Switches)...


    Gruss,

    S:oren

  • [rockpro64] Gibt es für den rockpro64 ein Ausgabe-Plugin?

    butjar wrote:

    Zusammenfassend brauche ich für das Setup dann den Chiptreiber linux-saa716x und den PCIe switch support für den rockpro64 von linux-rockpro64, richtig?

    Ja.

    Insbesondere wenn der RockPro64 nicht von eMMC, sondern von SD-Karte gebootet werden soll, empfehle ich auch ein selbstgebautes u-boot mit der angepassten Trusted-Firmware von hier (da könnte ich mal eine neue Version bauen).


    Gruss,

    S:oren

  • [rockpro64] Gibt es für den rockpro64 ein Ausgabe-Plugin?

    butjar wrote:

    Super, danke. Hast du ausschließlich drivers/media/pci/saa716x/ angefasst, oder gibt es weitere Änderungen am Kernel? Wo finde ich den rockpro64 pcie-Extender support?

    Das sind zwei Paar Schuhe. Den S2-6400-Treiber gibt es im linux-saa716x-Repository, voellig unabhaengig vom Hostrechner.

    Patches fuer den PCIe-Switch Support auf dem RockPro64 gibt es im linux-rockpro64-Repository, was nicht heisst, dass alle Switches damit funktionieren, s.o.


    Gruss,

    S:oren

  • [rockpro64] Gibt es für den rockpro64 ein Ausgabe-Plugin?

    butjar wrote:

    Welche Extender kannst du mir empfehlen?

    Leider habe ich nicht herausfinden koennen, warum manche PCIe-Boards (und damit auch Switches) am RockPro64 funktionieren, und andere nicht. Die S2-6400 wird schon vom PCIe-PHY nicht erkannt, da lässt sich leider auch nichts in irgendeinem Treiber fixen. Jedenfalls habe ich bisher keinen Trick finden können.


    Ich benutze diesen Switch, ohne Garantie.


    Gruss,

    S:oren

  • [rockpro64] Gibt es für den rockpro64 ein Ausgabe-Plugin?

    Uwe wrote:

    Zusätzlich muss man nun die Kernelmodule in einer bestimmten Reihenfolge und ganz wichtig auf einem bestimmten Core laden...

    Reihenfolge nicht, ist ja nur ein Modul. Aber für die Cores habe ich eine /etc/modprobe.d/pcie_rockchip_host.conf mit folgendem Inhalt:

    Code
    1. install pcie_rockchip_host /usr/bin/taskset -c 4-5 /sbin/modprobe --ignore-install pcie_rockchip_host $CMDLINE_OPTS

    Gruss,

    S:oren

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

    seahawk1986 wrote:

    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

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

    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.


    csp wrote:

    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