I2C Timeouts mit ddbridge

  • In linux-4.18.14-gentoo/Documentation/PCI/pci-error-recovery.txt finde ich:

    Das Dokument ist aus 2006 und spricht von powerpc, aber wenn es inzwischen hier ähnlich ist - und es sieht ja fast so aus - dann hat der ddbridge Treiber keinen Zugriff mehr auf den PCI Configuration Space.

    DIe Fehlermeldungen für I2C und ddb_data_avail() sagen dann aber gar nichts mehr aus, weil ddbreadl() immer 0xffffffff zurückgibt und ddbwritel() gar nichts bewirkt.


    Über /sys/kernel/debug/dynamic_debug bekommt man u.U. genauere Informationen über den PCI Zustand.

    Helmut

  • Möglicherweise würde es helfen, einen kernel mit AER(advanced error reporting) zu bauen.


    In der kernel config..

    Bus options (PCI etc.) --->[x] Root Port Advanced Error Reporting support


    Danach sollte es in /sys neue Einträge wie diese geben: /sys/bus/pci/devices/<dev>/{aer_dev_correctable,aer_dev_fatal,aer_dev_nonfatal}, welche du mit cat anzeigen kannst. <dev> sollte ein pci root port oder eine pci bridge sein, die mit dem problematischen PCI gerät (endpoint = dd oder netzwerkkarte) redet:


    Code
    1. Note that this may mean that if an endpoint is causing problems, the AERcounters may increment at its link partner (e.g. root port)
  • Über /sys/kernel/debug/dynamic_debug bekommt man u.U. genauere Informationen über den PCI Zustand.

    Das ist ein Directory, in dem es nur die Datei "control" gibt, mit dem Inhalt

    Insgesamt 2321 Zeilen.

    Ich glaube nicht, dass das weiterhilt...

  • Das ist ein Directory, in dem es nur die Datei "control" gibt

    Genau, und über diese werden dann z.B. alle dynamische debug Ausgaben des modules '[ehci_pci]' mit echo -n 'module ehci_pci +p' > /sys/kernel/debug/dynamic_debug/control aktiviert. (und mit "-p" wieder abgeschalten).

    Also am besten mit grep alle "pci"-zeilen in control anzeigen lassen, und dann für jedes interessante Modul ([......]) dieses echo mit +p aufrufen.
    In /usr/src/linux-4.18.14-gentoo/Documentation/admin-guide/dynamic-debug-howto.rst gibt es die nicht ganz leicht zu lesende Anleitung. Es mit 'file' statt 'module' auch möglich die Debugmeldungen nur auf Dateien oder sogar nur auf einzelne Zeile daraus anzuwenden.

    Helmut

    Edit : die entsprechenden Zeilen in control ändern sich das von '=_' zu '=p' (für print), in deiner control sieht man schon ein paar aktivierte Debugausgaben z.B bei [main]

  • Anscheinend gibt es das I2C Problem unter Windows nicht. Auch in den Bedienungsanleitungen zur Max findet sich der Hinweis bei I2C-Timeout zur msi Behandlung unter Linux.

    Das I2C-Problem, das mit msi zusammenhängt, wird es unter Windows nicht geben, schätze ich.

    Ich ordne es in die Reihe "übliche ACIP-Probleme" ein.

    Soweit ich sehen konnte, tritt es auch auf unterschiedlichen Mainboards auf und kommt bzw. geht teilweise mit den Kerneln.


    Das Problem hier scheint aber anders gelagert zu sein und betrifft anscheinend nur Mainboards mit Apollo-Lake-SOC.

    Diese Boards sind hier überproportional oft vertreten, weil sie praktisch ideal für diese Anwendung sind. Wie der Anteil bei Windows-Usern der DD-Karten aussieht, kann ich nicht abschätzen. Wenn der Anteil klein ist und die Ausfälle nur sporadisch auftreten, kann das Problem bislang durchaus unerkannt geblieben sein.

    Hier wäre jetzt interessant auszuprobieren, ob genau diese Boards unter Windows auch Probleme machen.

    Das würde für ein Hardware-Problem sprechen (höheres Rauschen auf Grund der Integration von PCIe-Controller und CPU in einem Chip oder ...) .

    Wenn es unter Windows geht, könnte man gezielter suchen. Registerdumps vergleichen usw...




    Wurde eigentlich schon mal

    Code
    1. pcie_aspm=off

    versucht? Ich hab da irgendwie den Überblick verloren.



    Möglicherweise würde es helfen, einen kernel mit AER(advanced error reporting) zu bauen.

    Das soll bei Debian drin sein, soviel ich weiss.

    Allerdings bekomme ich bei lspci nur AER Capabilities bei der Realtek-Netzwerkkarte angezeigt.

    Code
    1. Capabilities: [100 v1] Advanced Error Reporting
    2. [...]

    Auch in /sys/kernel/debug/dynamic_debug/control gibt es nichts zu den PCIe-Bridges usw. Nur wieder zur NIC und den USB-Controllern.

    Entweder unterstützten meine Boards das nicht, oder man muss da noch irgendwas aktivieren.

    Gruss
    SHF


  • Auch in /sys/kernel/debug/dynamic_debug/control gibt es nichts zu den PCIe-Bridges usw


    Falscher Pfad. /sys/bus/pci/devices/<PCI_Adresse>/...

  • Das Problem hier scheint aber anders gelagert zu sein

    Es scheint wirklich so so sein, das die PCI Controlle die V7A aufgrund eines Fehlers aus dem System nimmt. Mann erkennt es auch daran, dass, wie im Post #99 erwähnt, lspcidie Karte nach einem Fehler nicht mehr findet. Der Treiber läuft aber normal weiter und gibt auch weiter verschiedene Fehlermeldungen aus. Diese haben aber weder mit DMA oder I2C etwas zu tun - die V/A ist einfach nicht mehr vorhanden.


    pci-error-recovery.txt beschreibt aber auch die recovery Möglichkeit aus diesen Zustand und in den Kernel Sourcen ist In include/linux/pci.h das PCI Error Recovery System definiert: PCI-ERS

    Dieser PCI error_handler ist sogar im ngene driver (z.B für die cineS2v5) implementiert: ngene


    Wenn dieser PCI error_handler auch im ddbridge Treiber enthalten wäre, könnte die V7A möglicherweise auch wieder aktiviert werden.


    Helmut

  • Im ddbridge Treiber gibt es eine Funktion die LEDs anzusteuern. Die wird aber nicht genutzt.

    Man könnte eine kleine Anwendung bauen, die die LEDs umschaltet, und gucken, was im Fehlerfall passiert.

    Das Leuchten der fünften LED im Fehlerfall kann also nur von der Firmware auf dem Lattice verursacht worden sein. Die Firmware erkennt anscheinend, dass der PCIe sich aufgehängt hat und stellt die LED an. Die Firmwaresourcen hat aber nur DD.

  • Dieser PCI error_handler ist sogar im ngene driver (z.B für die cineS2v5) implementiert: ngene

    Ich habe das jetzt mal entsprechend in den DD-Treiber eingebaut (siehe Anhang), ohne wirklich zu wissen, was ich da tue ;-).

    Hat leider nichts geändert und es kam auch nie eine Log-Meldung "PCI error", also wurde ddb_error_detected() wohl auch nie aufgerufen.

    <edit>sorry, der diff war reversed</edit>

  • ohne wirklich zu wissen, was ich da tue ;-).

    Dann sind wir schon zu zweit :)

    Hat dein Kernel AER unterstützung - pcieaer-howto (PCI Express Advanced Error Reporting Driver) für mehr logging?

    Code
    1. 2. User Guide
    2. 2.1 Include the PCI Express AER Root Driver into the Linux Kernel
    3. The PCI Express AER Root driver is a Root Port service driver attached
    4. to the PCI Express Port Bus driver. If a user wants to use it, the driver
    5. has to be compiled. Option CONFIG_PCIEAER supports this capability. It
    6. depends on CONFIG_PCIEPORTBUS, so pls. set CONFIG_PCIEPORTBUS=y and
    7. CONFIG_PCIEAER = y.

    Vielleicht ist der pci_error_handler in ngene_cards.c nicht vollständig implementiert

    Ich hätte aber schon erwarted, das zumindest ddb_error_detected()aufgerufen wird.

    Hier alle Treiber die pci_error_handlers verwenden.

    Ich werde es mir am Abend auch noch genauer ansehen.

    Helmut

  • *** ddbreadl() B regs=ffffc900013a0000 adr=00000080 /home/kls/vdr/DVB/dddvb-0.9.36/ddbridge/ddbridge-i2c.c(35)

    Ok, 'regs' war doch unnötig, das ist die virtuelle Speicheraddresse.

    adr=00000080 -> kommt aus Zeile 35 val = ddbreadl(dev, i2c->regs + I2C_COMMAND);

    Wenn ich das zurückverfolge komme ich auf einen i2c Zugriff auf eine octopus.

    Das kann aber nicht sein, weil du gar keine hast. Da muß irgendwo ein Denkfehler sein.

    Helmut

    Edit: Kannst du inddbridge-i2c.c(35) den Wert von i2c->regs ausgeben.

  • Stimmt, hardwaremäßig war die mit der V7A verbunden. Ich hatte lediglich VDR mit -D0 aufgerufen, um nur ein Device zu verwenden.

    Hab jetzt alles abgesteckt und es ist nur mehr die V7A in Betrieb.

    Es kommt nach wie vor


    Apr 15 17:36:21 vdr3 kernel: [ 174.245165] *** ddbreadl() B regs=ffffc900012c0000 adr=00000080 6595 /home/kls/vdr/DVB/dddvb-0.9.36/ddbridge/ddbridge-i2c.c(35)


    Die 6595 ist die Anzahl der Aufrufe mit adr=0x80, bevor der Fehler passiert.