Posts by Sundtek

    64bit ARM wird auch unterstützt und ist im Installer enthalten.

    PCI-Express und USB sind derzeit die einzigen High-Speed Busse die direkt am CPU angebunden sind daher werden die die Zukunft bleiben.

    USB aus dem Grund da es von Anfang an Hotplug fähig war und es langsame Datalinks unterstützt z.B eine Maus mit billigsten Kabeln am Computer verbinden kann, bei PCI-e benötigt man sehr teure Kabel für so kleine Gadgets was sich nicht rechnen würde.
    PCIe ist auch Paket-basiert und hat ein leichteres Protokoll als USB.

    Ich schätze wir werden im Februar auch die ersten PCI-e Geräte haben, treiberseitig gibt's da heutzutage einige Optionen, PCIe - komplett Userspace oder Hybrid mit einfachem Kernel-Datalink (ohne LinuxDVB Abhängigkeiten)
    Letztes Jahr haben sich bei uns ein paar gute Gelegenheiten im Maschinenbau ergeben daher haben wir das nicht früher fertig gemacht.

    Was Du nicht sagst.

    Ach, willste dann mit screenshots auf die Kernel Mailingliste? :mua

    Meinst Du die nehmen Bugreports von ner proprietären deutschen Provinzklitsche an?

    Ich war per kernel remote serial console dran, aber da kam auch nix.

    Leute die Computer "Rechner" nennen, nehme ich fachlich nicht ernst, sorry.

    Du hast zwar kein Gerät von uns aber dennoch:

    Update:

    ----

    Das Problem wurde bereits gefixt:

    https://nvd.nist.gov/vuln/detail/CVE-2024-45006

    https://ubuntu.com/security/CVE-2024-45006

    ----

    Da ich bei uns ein System aktualisiert habe kann ich Dein Problem wohl nachvollziehen.

    Ein allgemeiner Bug hat sich im XHCI Controller eingeschlichen.

    Und ja sie werden Bugreports von ner proprietären Provinzklitsche dankend annehmen, vor allem da uns auch bekannt ist wo das Problem im Controller Treiber liegt.

    Der Fehler ist meiner Ansicht nach extrem kritisch, man kann damit jedes Linux System mit einem preparierten USB Stick abstürzen lassen ohne dass man Zugriff auf das System hat, betroffen sind davon auch Android Handies mit Versionen um Linux 6.8.0.

    Das Problem kann durch

    * präparierte USB Geräte getriggert werden

    * defekte USB Geräte

    * defekte USB Kabel

    * schlechte Verbindungen (und das ist bei Hotplug nun mal nicht ausgeschlossen)

    Bei PCIe Hotplug Systemen würde es noch viel schlimmer aussehen da die jeweiligen Treiber dort niemals für Hotplug entwickelt wurden, bei diesem Fehler hier handelt es sich sehr offensichtlich um einen Kernel Bug. USB Treiber sind da halt etwas fordernder.

    Maintainer von diversen Subsystemen in Linux sind nicht unbedingt Experten im jeweiligen Bereich, sie managen die Subsysteme. Irgendwer muss Patches annehmen und sich zumindest halbwegs auskennen und bewerten können ob die Patches schlüssig sind.

    Das Problem liegt in xhci.c

    Hi,

    das heisst nur dass der Treiber da nichts gemacht hat, eventuell wurde das Node schon vorher geschlossen und errno wurde halt nicht gesetzt.

    kann ich mir leider erst gegen Ende nächster Woche anschauen, zur Zeit gibts wohl nen kritischen USB Fehler in 6.8.0 der wohl durch Dummheit in den Kernel gelangt ist...

    Unser Testsystem crashed relativ häufig wegen dem Bug, bearbeite den gerade..

    @woprr

    Wenn Du meinst von einem XHCI Bug betroffen zu sein - und der Kernel nicht tainted ist dann macht es durchaus Sinn Bugreports abzuliefern. Die Regel lautet sobald der Kernel Tainted ist, ist Fremdcode im Kernel.

    Du scheinst ja so Erfahren zu sein, also wo sind Deine Bugreports und welche USB Geräte sind betroffen? (mit uns hat das ja nichts zu tun).

    Dass diverse USB Kernel Treiber Probleme mit Hotplug haben ist bekannt, noch viel mehr PCIe Treiber würden crashes verursachen wenn sie mit Hotplug zu tun hätten - die sind einfach nicht dafür ausgerichtet.

    Und hier sind wir wieder bei den Userspace Treibern, entweder wird dort der Tuner deregistriert, oder der gesamte Multimedia Stack wird im Falle von Standby heruntergefahren (ist ja nur eine Userspace Applikation). Zudem unterstützen Windows und MacOS auch Userspace Treiber.

    Selbst PCIe unterstützt seit würde ich sagen 2016 Userspace Treiber (technisch bei einigen Systemen schon etwas länger, aber je länger man abwartet desto interessanter wird die Sache auf dem Markt)

    Aber ich will Dich nicht länger füttern, bis jetzt sind nichts als haltlose Argumente von Dir gekommen.

    Tja Photos machen, Bugreport und Problem analysieren.

    XHCI Probleme sehe ich (wenn überhaupt) bei Kunden dann nur mit Speicherproblemen bei Kunden, also jetzt nicht XHCI Probleme sondern Speicherprobleme. Wer weiß vielleicht hat dein Rechner ja anderswo Probleme.

    USB bereitet hier keine Probleme.

    Und wie erwähnt wir unterstützen die Geräte aus 2008 immer noch (und müssen uns darum nicht mal kümmern), nahezu alle Kunden würde ich sagen verwenden exakt den gleichen Treiber.

    Mit möglicherweise mit vielen Kerneln binärinkompatiblen proprietären closed source treibern?

    Nein, Danke.

    Wenn Sundtek soviel Geld will dann sollense gefällist richtige OSS Treiber zum mainline Kernel beitragen.

    Das ist der Clou, wir greifen auf ein rohes USB Interface vom Kernel zu. Das hat sich seit 2006 so gut wie nicht geändert. Außerdem müssen wir uns nicht mit Kerneltreiber rumschlagen. Die SkyTV 8er von 2018 haben keine Updates benötigt die letzten Jahre lang und funktionierten hier auf einem System mit Linux 4-6 mit dem gleichen Treiber. SkyTV Dual hat einige Updates bezüglich des Treibers selber benötigt. Bis jetzt funktionieren die Geräte aus 2008 immer noch mit dem gleichen Paket auf weitaus mehr Systemen als die Linux Kerneltreiber kompilierbar sind. Das Paket ist 1 1/2 Jahrzehnte praktische Erfahrung mit verschiedenen Systemen. Wir müssen bei neuen Kernel Versionen nicht updaten, das funktioniert ohne unser zutun.

    Vor allem steht das da, der Treiber wurde also gestoppt

    2024-10-01T16:30:51.319279+02:00 vdrserver systemd[1]: Stopping sundtek.service - Sundtek mediasrv...

    usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd mediasrv rqt 64 rq 187 len 1 ret -4

    interrupted system call, da wurde wohl der Treiber (was 2-3 Prozesse sind) gekillt.

    Ein richtig abnormales Verhalten welches den VDR während der Laufzeit beeinflusst kann man aus der Logfile nicht entnehmen (hattest Du hier auch nicht erwähnt). Ich weiß auch nicht wie das Update da jetzt genau gemacht wurde, eigentlich sollte das Paket zuvor gestoppt werden und danach der Treiber aktualisiert werden (so macht unser Installer eigentlich, yavdr hat seine eigene Installations / Upgrade Routine).

    Das geht wieder in die Richtung so günstig kann man das eigentlich nicht fertigen wenn's ordentlich sein soll.

    Der Sony Chip wird über einen USB Chip programmiert der keine Video Daten übertragen kann, der Transportstrom wird aber wohl direkt rausgeleitet.

    Fragwürdig wäre da zudem noch welche LNB Spannungsversorgung da verwendet wird, für aktive Multiswitches kann man bald mal was zusammenwursteln (da reichts wenn man nen billigen Step-Up Controller verwendet den man entsprechend konfiguriert), wenn man jedoch die LNBs direkt ansteuert braucht das Power und die Spannung muss auch überwacht und justiert werden (=kostet Geld, jetzt nicht nur der Chip sondern auch die Bauteile rundherum).

    Im großen und Ganzen das Gerät funktioniert wenn überhaupt nur mit der jeweiligen Android Amlogic Box da die Pins entsprechend geroutet wurden.

    Kannst Du eventuell mal nen remote Zugang zu dem System bereitstellen?

    Was ich da machen würde wäre ein kleines Testprogramm mit entsprechenden Filtern, vielleicht wird da irgendetwas gematched was im Filter eigentlich nicht gematched werden sollte. Wir haben einen eigenen Demuxer in der Software-Chain, der hat einige spezielle Features für spezielle Anwendungen.

    Hat Das bei Dir sonst irgendwelche Nebenwirkungen?

    Wenn ich hier einen EIT Filter auf diesen Transponder loslasse sehe ich keine Probleme (aber ich kenne halt auch nicht die genauen Filter Settings die VDR da loslässt und auf diese wird es ankommen).

    SIGNAL: [ ] ( 0%) SATQUALITY: 0% SNR: 9 BER: 0 FREQ: 11817000 Hz LOCKED: NO SYS: DVB-S2 SYM: 29700000 FEC: FEC_2_3 MOD: PSK_8 VOLTAGE: V(13V) TONE: ON

    SIGNAL: [ ] ( 0%) SATQUALITY: 0% SNR: 0 BER: 0 FREQ: 11597000 Hz LOCKED: NO SYS: DVB-S SYM: 22000000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF

    überprüfe mal was das für Transponder sind, vielleicht ist ja nur ein Parameter falsch. Die treten in der Logfile ein paar mal auf.

    Also, egal wen ich vorher starte... Sundtek schnappt sich die beiden ersten frontends...

    vdr startet mit dem LD_PRELOAD für die sundteks. vtunerc ist mit 6 devices geladen und mit satip sind die 6 devices zugewiesen. Am Ende hätte ich gerne 8 tuner ;)

    Du brauchst first_adapter=N in /etc/sundtek.conf das weist unserem Stack den ersten freien Adapter zu. N sollte die Nummer des ersten Adapters sein welcher von unserem Stack benutzt werden darf.

    Grundsätzlich versucht der Stack abzuwarten bis andere Treiber geladen sind aber das ist halt nicht wirklich vorhersehbar wann was geladen wird deshalb die first_adapter Option.