Posts by 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

S:oren wrote:

Haettest Du wie oben beschrieben 4.15.0 installiert, dann wuerde ich eine Modulsignatur 4.15.0 (oder allenfalls 4.15.0-generic) erwarten, auch noch nicht 4.15.0-48-generic wie benoetigt.

Anscheinend ist bei Ubuntu alles anders, ich "liebe" diese Distribution. Jedenfalls sehe ich auch, dass eine installierte Ubuntu-linux-source in Version 4.15.0-48.51 sich selbst als 4.15.18 bezeichnet. Gruselig.

Folgendes Vorgehen

ergibt zumindest mal saa716x-Module, die sich unter einem Kernel 4.15.0-48-generic laden lassen.

Leider (oder zum Glück?) habe ich keinen Ubuntu-Rechner mit S2-6400. Ob die Module funktionieren, kann ich also nicht testen. Ich hoffe das Beste...

Gruss,

S:oren

Es ist fuer mich schwer nachzuvollziehen, welche Sourcen Du genau wie installiert hast.

Fakt ist, die Module sagen (auch die neu generierte config), es waere ein Kernel 4.15.18. Das wird dann auch so sein.

Haettest Du wie oben beschrieben 4.15.0 installiert, dann wuerde ich eine Modulsignatur 4.15.0 (oder allenfalls 4.15.0-generic) erwarten, auch noch nicht 4.15.0-48-generic wie benoetigt.

Ich weiss auch nicht, wie man bei Ubuntu die Kernel-Sourcen richtig installiert, da muss es aber doch Anleitungen geben!? Falls sonst niemand eine Idee hat, kann ich das heute Abend (?) mal ausprobieren...

Gruss,

S:oren

Luwex wrote:

und dann eben von Hand zurück ändern.

Das wird nicht helfen. Es hilft nur, nicht nur die richtige config, sondern auch die richtigen Sourcen zu verwenden...

Du hast den Treiber anscheinend mit einem Stable-Kernel 4.15.18 gebaut, und noch den Distro-Kernel 4.15.0-48-generic laufen.

Ich kann nur immer wieder den Hinweis wiederholen, die 2 verschiedenen Wege zum Bauen und Nutzen des Treibers (Mainline/Stable- oder Distro-Kernel) nicht zu vermischen...

Gruss,

S:oren

Leider sind die Infos zu den beiden Varianten, den Treiber zu bauen, etwas verstreut hier im Forum.

Neben diesem und dem oben verlinkten Thread gab es kürzlich hier nochmal ein ganz kurze Anleitung. Aber auch sonst haben verschiedene User schon Anleitungen für verschiedene Linux-Distributionen gepostet.

Konkrete Fragen beantworte ich gerne, eine allgemeingültige Anleitung für beliebige Distros auf allen denkbaren Rechnerarchitekturen mit verschiedenen Bootloadern habe ich leider auch nicht.

Gruss,

S:oren

HelmutB wrote:

Bei der anderen Methode mit Signalisierung über Hardware-Pins

Gerade zum Thema MSI bei PCIe gibt es wohl viele Missverstaendnisse.

Zunaechst mal werden alle Interrupts bei PCIe ueber Messages signalisiert. Es gibt schlichtweg keine weiteren Leitungen neben den PCIe-Lanes, ueber die solche Informationen uebertragen werden koennten.

Die erste PCIe-Version war nun so designt, dass sie softwaremaessig kompatibel zu "normalem" PCI war, somit gab es bis zu 4 "legacy" Interrupts pro PCIe-Slot, die auch fuer den ganzen "Bus" (PCIe-Root-Complex) geshared werden.

In spaeteren PCIe-Versionen kam man nun auf die Idee, dass man neben den ohnehin vorhandenen Messages als Option auch mehr als diese 4 Interrupts signalisieren koennte (bis zu 32 in 2er-Potenz-Schritten bei MSI, flexibler bei MSI-X), kostet halt quasi (an Hardware) nix. Diese Zusatz-Interrupts werden nun nicht geshared, es gibt aber keine Garantie, dass man die angeforderte Anzahl auch zugeteilt bekommt. Ein PCIe-Root-Complex unterstuetzt halt nur eine begrenzte Anzahl an Interrupts (die er ja zunaechst mal wieder ueber regulaere Leitungen an einen Interrupt-Controller signalisieren muss), und ein PCIe-"Bus" kann ja ueber Bridges recht viele PCIe-Slots haben. "Neuerdings" muessen die Interrupt-Messages nicht mehr im PCIe-Root-Complex enden, sondern koennen - per memory-mapped-IO, uebersetzt vom Root-Complex - auch direkt in Registern eines Interrupt-Controllers enden. Somit braucht man keine dedizierten MSI-IRQ- Leitungen vom Root-Complex zum Interrupt-Controller mehr, die vorhandenen IRQ-Anzahl kann im Zweifel zwischen mehrenen PCIe-Bussen flexibel aufgeteilt werden, eine Obergrenze (Adressen im Interrupt-Controller) gibt es aber immer noch.

In der Praxis ist es nun so, dass normalerweise keine Interrupts geshared werden, da selten mehr als 4 PCIe-Karten pro Bus benutzt werden. Auch kenne ich keine DVB-PCIe-Karte, die mehr als einen Interrupt benutzt (einfach weil der Treiber eh mit der Tatsache zurechtkommen muss, dass er nicht mehrere Interrupts (Vektoren) zugeteilt bekommt und alternativ eine single-IRQ-Option implementieren muss). Somit gibt es in der Praxis nur selten einen (meist nur kleinen) Vorteil von MSI(-X). Aber gutes Treiber-Design nutzt jedoch auch diesen potentiellen kleinen Vorteil durch Aktivierung von MSI(-X).

Frueher (in aelteren Kernel-Versionen) war es in LInux noetig, dass ein Treiber sich entscheiden muss, ob er legacy- oder MSI(-X)-Interrupts nutzen will. Das ist heutzutage (bei aktuellen Kerneln) nicht mehr so. Ein vernuenftiger Treiber hat die Modul-Option zur Aktivierung von MSI also heutzutage nicht mehr.

Leider gibt es einige (buggy) PCIe-Root-Complex-Implementierungen, die nicht gleichzeitig legacy- und MSI-Interrupts unterstuetzen. Auch kann man MSI im Kernel deaktivieren. Nur fuer diese Faelle ergibt eine Modul-Option fuer MSI Sinn.

Zusammenfassend ist so eine MSI-Kernel-Modul-Option heutzutage nicht mehr notwendig und ergibt auch in aelteren Kernel-Versionen nur als Workaround fuer Hardware-Fehler Sinn. Performance-Unterschiede oder auch anderes Verhalten gegenueber PCIe-AER (wie in diesem Thread diskutiert) wird man nicht feststellen.

Gruss,

S:oren

In dem Fall

Dann mit 'patch -p1< /path/to/file/v4.12...saa716x-4.12.diff' im Distro-Kernel-Source Tree anwenden...

Gruss,

S:oren

jasminj wrote:

Vielleicht schafft es der Treiber ja doch nach Staging.

Eher nicht. Mauro wollte ihn explizit nicht in staging. Deshalb habe ich bereits alles aufgeraeumt, was ich (und checkpatch.pl) fuer noetig hielt.

Gruss,

S:oren