Posts by HelmutB

kls wrote:

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

helau wrote:

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

Dein Link zu HTPC-Forum den ich abgespeichert habe geht auch wieder von WIndows-Rechnern - das war die letzten Tage/Wochen nicht so.

Helmut

jsffm wrote:

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

Argus wrote:

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

Ich frage mich gerade, wie sich die Karte in so einem einem PCIe-Riser verhalten würde.

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

Ich sehe gerade das auch es deine DuoFlex C/C2/T/T2/ISDB-T mit Octobus PCIe Bridge sein könnte:

https://www.digital-devices.eu…s-pcie-bridge-v3-set?c=94

Helmut

kls wrote:

*** 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.

kls wrote:

wo aus ddbreadl() aufgerufen wurde

Da gibt es noch dev->regs als base - dann sollte man in ddbridge-regs.h sehen zu welcher Registergruppe die Adresse gehört.

Helmut

kls wrote:

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?

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

wirbel wrote:

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

In drivers/pci/pcie/err.c sind Debugausgaben eingebaut.

Aber vielleicht muss - so wie du geschrieben hast - zuvor CONFIG_PCIEAER in der Kernel-config aktiviert sein.

Helmut

SHF wrote:

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

kls wrote:

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