Das Modul dvb-core.kopasst nicht zu der Version gegen die smipcie.ko gebaut worden ist. Kontrolliere noch einmal die Module (der externe dddvb-0.9.36 Treiber z.B. installiert seine Version von dvb-core.ko).
Das war extern versorgt.
Wenn es nur über den PCIe Slot auch ginge wäre das Thema "Spannung" endgültig geklärt.
Helmut
Wenn du Vorschläge für Tests hast, kann ich die gerne durchführen.
die Tests mit den eigenen Hausmittlen hattest Du ja schon gemacht (Spannung PCIe, Taktrate) usw. Mehr wird da ohne spezielles Equipment nicht möglich sein. Vielleicht liest jemand von den Verdächtigen mit und könnte sich da einen Reim drauf machen.
Es geht also doch!
Und damit ist DD erst recht gefragt, das zu verbessern.
da es aber im praktischen Betrieb keine Probleme gibt ist die Frage, ab wann es problematisch wird. Ein detektierter Fehler der das Flag setzt, wird nicht das Problem sein. Hier sind diese Fehler auch bekannt --> https://www.kernel.org/doc/Doc…ion/PCI/pcieaer-howto.txt und wohl üblich.
Schwer zu sagen, ab wann es problematisch wird.
Wenn man dieser Seite trauen kann, werden die Fehler durch eine erneute Übertragung behoben.
Diese kosten natürlich unnötig Bandbreite und das wird man irgendwann merken.
Wahrscheinlich wird es aber schon früher zu Problemen kommen und zwar, wenn eine Übertragung mehrfach hintereinander scheitert.
Die Puffer sind in den Geräten sind nicht besonders gross, da könnte es schon nach ein paar Fehlversuchen eng werden.
Leider geben die Flags nicht an, wie oft der Fehler aufgetreten ist, sondern nur, dass er (mindestens einmal) aufgetreten ist.
Aber selbst ein Pufferüberlauf ist eigentlich kein Grund, dass die Karte komplett aussteigt.
Meine Vermutung geht stark Richtung Timing-Problem.
Die Karte muss synchron zum Referenztakt von 100MHz den Datentakt von 2,5GHz erzeugen. Das scheint auf einem FPGA nicht ohne Tücken zu sein.
Wenn man nach diesen PCIe-Parametern sucht, stösst man immer wieder auf FPGA-Howtos bezgl. korrektem PCIe-Timing.
Wenn der Oszillator stolpert, sind ruck-zuck ein paar Datenpakete hinüber und wenn die Störung zu gross wird hängt sich die Karte auf.
100MHz gehen noch, wer will und in entsprechendes Oszilloskop hat, kann ja mal versuchen, ob man auf dem RecCkl-Signal beim J3355M was sieht.
... aber zurück zu den Fehlern.
Wenn es alles richtig läuft, sollten die überhaupt nicht auftreten. Auf keinem meiner Computer konnte ich welche beobachten.
Ein gutes Zeichen sind sie zudem nicht, besonders wenn sie regelmässig auftreten. Das es bedeutet, das irgendwas grenzwertig arbeitet.
ZitatErrors in the low-level packets are not only a performance issue (retransmissions are a waste of bandwidth). With properly designed hardware, there is no reason for their appearance at all, so their very existence indicates that something might be close to stop working.
Wo die Grenze zwischen geht und geht nicht mehr in der Praxis liegt, hat kls schön gezeigt. Wir sitzen ziemlich genau drauf.
Beim J4105M geht es, beim J3355M geht es nicht und der Unterschied in der Fehlerrate ist nicht so gross.
neben den unterschiedlichen devices auch max payload, linkspeed, Powerlimit, devcap, linkctl, usw.
Die ...Cap-Zeilen kann man ignorieren, die geben nur die Fähigkeiten des Devices an.
Der aktuelle Status ist in ...Sta zu finden. Da sind dann die Abweichungen nicht mehr so gross.
Was die wiederholte Übertragung bei Fehlern auf dem PCIe betrifft, das gilt evtl. dann nicht für Message-Signaled-Interrupts (MSI),
zumal diese auch nicht bestätigt werden. In dem Fall würde der Kernel auch irgendwann nicht behandelte Interrupts monieren
oder die hardware evtl auf den Treiber warten..
Wenn es nur über den PCIe Slot auch ginge wäre das Thema "Spannung" endgültig geklärt.
Hab's probiert. Die Stromversorgung des PCIe Extension Boards ist zwingend notwendig, sonst wird bereits dieses selber nicht erkannt.
Klaus, auch wenn das jetzt off-topic ist: Nutzt Du die integrierte Intel-Grafik oder hast Du eine Nvidia-Grafikkarte am laufen? Kannst Du da mal einen Vergleich ziehen? Wie unterscheidet sich die Bildqualität der Intel-Grafik zwischen J4105M und J3355M, und inwieweit siehst Du bei beiden einen Unterschied zur Nvidia-Karte?
Was die wiederholte Übertragung bei Fehlern auf dem PCIe betrifft, das gilt evtl. dann nicht für Message-Signaled-Interrupts (MSI), zumal diese auch nicht bestätigt werden.
Nach meinem Verständnis werden die Wiederholungen auf der Hardware-Schicht ausgelöst.
Das heisst, wenn die Message-Signaled-Interrupts in Datenpaketen verschickt werden, sollten die auch erneut übertragen werden.
Mein Wissen stammt aber aus Sekunderquellen, bei derartigen Detailfragen müsste man sich selber mal durch die Spezifikation arbeiten.
Nachtrag zum J4105M Board: Der Eintrag "options ddbridge msi=0" in /etc/modprobe.d/ddbridge.conf scheint wohl nicht nötig zu sein.
Die Einstellung ist AFAIK auch nur bei fehlerhaften ACPI-, MSI-, Wasauchimmer-Tabellen im BIOS sinnvoll.
Die Einstellung ist AFAIK auch nur bei fehlerhaften ACPI-, MSI-, Wasauchimmer-Tabellen im BIOS sinnvoll.
da sehe ich auch so. WIe in MSI-HOWTO.txt beschrieben sind interrupt requests über MSI u.a deshalb effektiver, da sie eindeutig einem Gerät zugeordnet werden können. Bei der anderen Methode mit Signalisierung über Hardware-Pins (msi=0) kann es sein das dieser Pin von mehreren Geräten verwendet wird und deshalb unnötigerweise die Interrupt Service Routinen (ISR) aller dieser Geräte aufgerufen werden (müssen). Wenn damit keine Pobleme auftauchen ist MSI die bessere Wahl. Grundsätzlcih sollte es aber mit jeder Einstellung funktionieren.
Beim ddbridge Treiber ist übrigens die default Einstellung für MSI auf github und im Kernel etwas unterschiedlich. Auf github (0.9.37) ist MSi per default aktiviert, im Linux Treiber (0.9.33) hängt es vom Wert von DVB_DDBRIDGE_MSIENABLE ab, dieser ist im default "N"also deaktiviert. Dazu gibt es auch eine kurze Beschreibung:
config DVB_DDBRIDGE_MSIENABLE
bool "Enable Message Signaled Interrupts (MSI) per default (EXPERIMENTAL)"
depends on DVB_DDBRIDGE
depends on PCI_MSI
default n
---help---
Use PCI MSI (Message Signaled Interrupts) per default. Enabling this
might lead to I2C errors originating from the bridge in conjunction
with certain SATA controllers, requiring a reload of the ddbridge
module. MSI can still be disabled by passing msi=0 as option, as
this will just change the msi option default value.
If you're unsure, concerned about stability and don't want to pass
module options in case of troubles, say N.SATA war zwar hier noch nicht das Thema, wir wissen inzwischen aber das msi=0 in der Kombination von J3455M und V7A nicht hilft.
Helmut
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
Sehr ausfühlich - Danke!
Helmut
Cool. Halte uns dazu Mal auf dem laufenden.
Super 
Wenn das DD hilft, das Problem zu fixen, werde sich viele freuen 
Ich ziehe jetzt schonmal den Hut vor euch allen.
Ich verfolge wie wahrscheinliche andere den Thread seit Wochen nur um zu schauen wie es weiter geht...
Auch wenn ich die Karte aktuell nicht mehr nutze, würde ich mich freuen wenn DD einen fix dazu herausbringt.
... nach Rücksprache mit der Geschäftsleitung von DD einen VDR zusammengestellt, mit dem das Problem zuverlässig reprodizierbar ist und ihnen geschickt...
Wow, das nenne ich mal Einsatz - Respekt!
Gibt's hier schon Neuigkeiten?
Stefan
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!