Posts by S:oren

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

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

csp wrote:

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

c.h. wrote:

Die momentanen DD-Treiber im Kernel hat der User S:oren mit viel Mühe reinbekommen.

Das stimmt so nicht. Ich kuemmere mich um den saa716x-Treiber (insbesondere fuer die TechnoTrend S2-6400). DigitalDevices-Karten habe ich nicht, somit auch nichts an den zugehoerigen Treibern entwickelt.

Gruss,

S:oren

xblades wrote:

Zumindest für dvbsddevice hab ich das patchen können

Was wäre das für ein Patch?

Danke,

S:oren

Probleme im Mietshaus habe auch erlebt, siehe oben. Im Eigenheim erwarte ich sowas nicht.

Wieviel Flexibilitaet man sich wuenscht, ist Geschmacksache, denke ich. Mancher mag vielleicht keinen Splitter-Verhau im Keller, wo die ganze Wand mit Kabeln zugepflastert ist. Moeglichkeiten gibt es wie immer viele. Und der Trend geht momentan ja eher weg von Koax-Verkabelung.

Man sollte nur keine

Angelosarikis wrote:

(T-Stücke hinter der Dose?)

verwenden, sondern richtige Durchgangsdosen, wenn man mehrere an einem Strang haben will.

Ähm, was hat diese Antwort mit meiner Frage zu tun?

PmK findet eine Strangverkabelung kompliziert, ich nicht. Es kann gegenueber einer Sternverkabelung mit Splitter im Keller nur einfacher werden.

Angelosarikis wrote:

mit einem Kabel von einem Raum in den nächsten zu gehen, scheint attraktiv, da der Verkabelungs-Aufwand gering ist und damit günstiger.

Somit stimme ich der Idee von Angelosarikis zu, will es aber nicht uneingeschraenkt empfehlen, weil ich es selbst so fuer SAT-Unicable nicht im Einsatz habe.

Wieviele Dosen man an welche Wand nagelt und ob man hinter der Dose (welcher Art auch immer) weitere Splitter installiert, ist davon komplett unabhaengig...

PmK wrote:

Ich denke von Raum zu Raum Kabel ziehen mit Splitter in jeder Dose erhöht auf jedenfall mal die Komplexität.

Warum nicht Durchgangs- und Enddosen passend installieren? Die Durchgangsdosen enthalten die Splitter quasi schon, spart ggf. 'ne Menge Kabel und Verlegeaufwand, mit einem Splitter im Keller kann man ggf. mehrere Straenge aufbauen.

Funktioniert das nur in der Theorie und hat jemand damit schlechte Erfahrungen? Bei Kabelfernsehanlagen gab es ja manchmal Probleme, wenn der Nachbar meinte, auf die Dosen noch zusaetzliche Kabel klemmen zu muessen. Im eigenen Haus passiert das ja eher nicht...

Gruss,

S:oren

nobanzai wrote:

Das Budget-Modul lässt sich allerdings nach wie vor nicht übersetzen - das brauche ich aber auch nicht.

Ich habe den Build fuer budget und hybrid im 4.12er Branch gefixt, sollte jetzt gehen.

Gruss,

S:oren

Es gibt keinen einfachen Weg, den Treiber ohne komplette Kernel-Sourcen zu bauen, da auch die Kernel-Header gepatcht werden muessen.

Wer sich da ausgefeilte Skripte oder dkms-Pakete oder was-auch-immer bauen will, darf das natuerlich gerne machen, muss aber mit jeder neuen Kernel-Version damit rechnen, dass man da wieder etwas anpassen muss. Da das Herunterladen der Kernel-Sourcen + Patchen + Bauen der Module keine 10 Minuten dauert (wenn man es nicht zum ersten Mal macht), wird man m.E. die Zeit nie wieder einsparen, die man die Entwicklung solcher Spezial-Loesungen steckt. Wer aber Spass daran hat, soll es meinetwegen gerne machen. Ich kann und moechte dafuer jedenfalls keinen Support leisten, ich selbst nutze sowieso keine Distro-Kernel auf meinen VDR- und Treiber-Entwicklungs-Rechnern. Aber auch da soll jeder nehmen, was ihm/ihr gefaellt.

Nach den Problembeschreibungen, die ich so bisher bekommen habe, haben jedenfalls viele Leute schon deutlich mehr Zeit in die Fehlersuche gesteckt, als das Herunterladen und Patchen der kompletten Kernel-Sourcen gedauert haette. Die meisten Distro-Kernel werden sowieso exakt passende Modul-Versionen fordern, evt. sogar signierte Module. Wie das bei SuSE aussieht, weiss ich allerdings nicht. Die letzte von mir genutzte SuSE-Version war 9.3 ...

Gruss,

S:oren

kamel5 wrote:

Kernel 4.4 ist ja auch schon eine Weile her und wenn ich mich richtig erinnere, sind seit dem geringfügige Anpassungen am Treiber gemacht worden.

Koennte man so sagen, exakt 95 Patches...

nobanzai wrote:

Ich kann ja schlecht den Patch, der gegen einen ganzen Kerneltree laufen würde, gegen das bisschen Sourcecode werfen, das in den src.rpms drin war.

Bitte immer nur komplette Kernel-Sourcen verwenden. Die gibt es ganz sicher auch von SuSE.

Die letzte Anfrage, den Treiber fuer Suse zu bauen, kam von kls, siehe hier.

Gruss,

S:oren

Freut mich, dass es hier eine relativ einfache Loesung gibt.

Gruss,

S:oren

Es ist natuerlich immer eine gute Idee, "meinen Original-Kernel" aus dem Repo zu testen, wenn es Probleme mit dem Treiber gibt. Leider hat jede Distri da so ihre eigenen Tuecken.

Mittelfristig sollte ich wahrscheinlich das request_mem_region/ioremap in das neuere devm_ioremap aendern. Es waere mir allerdings neu, wenn es "oldstyle" nicht mehr funktioniert.

Vielleicht findet sich ja noch eine einfache Erklaerung. Ansonsten ist leider 'git bisect' angesagt...

Gruss,

S:oren

Sieht erstmal nicht verkehrt aus. Nur dass "SAA716x Core" eben nicht geladen ist.

Der Speicher ist im Prinzip da und nicht anderweitig belegt.

Ich habe im Moment keine weitere Idee...

Gruss,

S:oren

S:oren wrote:

Normalerweise funktioniert das request_mem_region() nicht, wenn schon ein anderer Treiber diesen Bereich reserviert hat.

Steht in /proc/iomem etwas dazu? Bei mir sieht das so aus:

kamel5 wrote:

Kann das an zu alter Hardware liegen?

Eher nicht. Normalerweise funktioniert das request_mem_region() nicht, wenn schon ein anderer Treiber diesen Bereich reserviert hat.

kamel5 wrote:

Was nutzt Du da für eine Hardware-Basis?

Immer noch die.

Gruss,

S:oren

kamel5 wrote:

Deshalb die Frage in die Runde, funktioniert bei Jemanden die TT6400 in Verbindung mit Kernel 5.1.x.

Laeuft bei mir mit 5.1.6.

kamel5 wrote:

BAR0 Request failed

Hier klappt schon das allererste Mappen des PCIe-Speichers nicht. Da wird noch nichts Karten-spezifisches gemacht.

Im Moment keine Ahnung, was da nicht klappt.

Gruss,

S:oren

kls wrote:

Nicht Skins, sondern OSD-Implementierungen.

Ja, nur das ergibt Sinn. Wie ist dann aber

kls wrote:

in SkinFlatPlus die Funktion MaxPixmapSize implementieren und einen beliebigen Wert, der für deine Zwecke groß genug ist, zurückgeben

zu verstehen?

kls wrote:

Wenn keiner was dagegen hat kann ich gerne diese Änderung machen

Zumindest von mir wird es da keinen Einspruch geben.

Gruss,

S:oren

Mein Verstaendnis mal zusammengefasst:

Der Raspi hat ein Problem mit surfaces grosser als 2048x2048 bei hardware-beschleunigtem OSD. Bei der simpelst moeglichen Implementierung im Ausgabedevice duerfen dann Pixmaps auch nicht groesser sein. Daraufhin legt der vdr-Core willkuerlich diese Aufloesung als Obergrenze fuer sein Software-OSD fest. Skins duerfen diese Grenze aber aendern!?

Nun reichen 2048x2048 nicht mal mehr fuer die sichtbare Bildschirmaufloesung. Dann legt man wieder willkuerlich 4096x4096 fest, unabhaengig von den tatsaechlich vorhandenen Ressourcen im System, womit weder den eventuellen Erfordernissen im Ausgabedevice (die meisten nutzen die Software-Implementierung, die nur durch den vorhandenen Hauptspeicher begrenzt ist, und nur fuer die gilt dieser Wert), noch den Wuenschen eines Skin gedient ist.

Bin ich der Einzige, der das absurd findet?

Gruss,

S:oren

OleS wrote:

und unter linux-4.15.0/ liegt dann das ganze entpackt und mit eingespielten Patches

Auf den ersten Blick ist das, was unter linux-4.15.0/ liegt, dann identisch zu dem (und genauso "kaputt"), was ich oben mit dem

S:oren wrote:

tar xjf /usr/src/linux-source-4.15.0.tar.bz2

ausgepackt hatte. Aber wie immer gibt es mehr als einen Weg zum Ziel.

Die "komischen" Versionsnummern in den Sourcen scheinen dann immerhin konsistent zu sein. Den "Trick" mit dem Ueberschreiben der KERNELVERSION habe ich uebrigens auch aus dem Ubuntu-Build-Skript, scheint da so ueblich zu sein...

Gruss,

S:oren