Posts by HelmutB

    Gleicher Test mit TT S2-6400 (ist ja auch eine PCIe-Karte)

    Vielleicht übersehe ich es in den vielen Posts - gab es schon einen Test mit der DuoFlex C/C2/T/T2/ISDB-T mit Octobus PCIe Bridge ohne V7A ?

    Helmut

    Ich habe meine PCIe 1x/16x Riser genauer angesehen.

    Sei sieht genau so aus wie auf dem Bild in #184, darauf sind 4 runde Kodensatoren, 1 DC/DC Spannungswandler, 1 Spule und 1 Spannungsregler. Die Unterseite ist plan, mit 2mm Moosgummi sauber abgedeckt.

    Also nur Power, keine PCIe-Bridge.

    Helmut

    Inwiefern unfertig ?

    "www.htpc-forum.de" wurde unter Windows immer auf "www.gen2vdr.de" ungeleitet, Und da kam immer so etwas "Website in Bearbeitung". Jetzt komme ich sowohl zu "htpc.forum.de" als auch zu "gen2vdr.de"

    Helmut


    Edit: Die Meldung war so ähnlich wie hier: webparts

    Ich habe mich nur gewundett. Unter Linux bin ich zu "htpc-forum.de" gekommen, unter Windows nur zur unfertigen "gen2vdr.de".

    Egal, ich werde mir jetzt den neuen Link merken.

    Helmut

    muss aber CONFIG_SND=y sein.

    Nicht unbeding. Es ist zwar ein anderes System, aber hier auf meinem alten Sony Notebook (Intel) und gentoo habe ich nurCONFIG_SND_HDA_I915=y direkt im Kernel , CONFIG_SND=m und alle ander 'SND' Optionen nur als Modul.


    In '/etc/conf.d/modules' habe ich 'snd_mixer_oss und 'snd_pcm_oss' eigentragen damit diese beiden Module beim Start immer geladen werden - das habe ich aber schon seit Jahren so drinnen stehen, vielleicht ist es gar nicht mehr notwendig.


    lsmod zeigt das 'snd' Aufgrund vieler Abhängigkeiten automatisch geladen wird.

    snd 57344 9 snd_pcm_oss,snd_hda_intel,snd_hwdep,snd_mixer_oss,snd_hda_codec,snd_hda_codec_idt,snd_timer,snd_hda_codec_generic


    Helmut

    Die Extender haben meist einen PCI-Brigde

    Ich bin ziemlich sicher das bei so einer 1x PCIe Riserkarte wie auf meinem Bild kein Bridge-IC verbaut ist - nur Bauteile für die Spannungsversorgung. Ich habe aber eine sehr ähnliche herumliegen und werde am Abend genauer draufschauen.

    Helmut

    Am Signal ("wackeln"?) wird es vermutlich nichts ändern, die zusätzllche Spannungsversorgung könnte Schwankungen ausgleichen - falls es doch daran liegt.

    Die PCIe-Riser werden/wurden oft verwendet um "fette" Grafikkarten fürs Bitcoin-Mining anzuschließen und sind derzeit um ein paar € zu haben

    Helmut

    Zu ddbreadl(): Ich habe jetzt etwas genauer nachgesehen. Die i2c-base Adresse ist bei vielen DVB-Karten von DD 0x80, das gilt auch für die V7A und der Log-Zeile im Post oberhalb (die verwendete regmap heißt "octopus_map").


    Dynamic_debug Ausgaben sind nur solche die im Treiber mit dev_dbg() oder pr_debug() angegeben sind.

    Diese werden in 'pcie/err.c' aber nicht verwendet und damit wären alle pci_info() Meldungen auch so im syslog gelandet - wenn es denn welche gegeben hätte. Das PCI recovery system kann hier also wie es aussieht auch nicht helfen.


    Igendwie gehen mir die Ideen aus.


    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.

    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

    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

    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]

    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

    Es gab/gibt von Daniel Scheller auf patchwork patchwork.kernel.org eine save_ddbreadl() Implementierung die den Fall von 0xffffffff prüft und dann 0 zurückgibt. Vielleicht kann man das in diesem Sinn an ein paar Stellen im Treiber doch übernehmen.


    Helmut


    Edit: bzw. nach einem ddbreadl() Fehler kein ddbwritel() mehr anwenden.

    Edit2: das kann aber bei i2c _xfer nicht angewendet werden, da dieser mit leider immer einem ddbwritel() beginnt

    Eine kleine Richtigstellung - es gibt die Probleme bei lesen/schreiben der in einen virtuellen Kernel-Speicherberich gemappten PCI-Register der DD - und nicht mit dem DMA Buffer. Ich bin leider kein PCI/DMA Spezialist und musste mich erst schlauer machen.

    Helmut