Beiträge von HelmutB

Ein USB Netzwerkadapter iwe von vdr_rossi hier vorgeschlagen wäre zumindest eine Möglichkeit von der PCI Bridge wegzukommen.

Wenn du zufällig noch einem USB WLAN-Stick herumliegen hast wäre er für einen 1. Test möglicherweise auch brauchbar.

Greift ddbridge/Cine eigentlich von sich aus auf das Netzwerk zu ? (ich wüsste jetzt aber gar nicht warum das sein sollte).

Helmut

Hallo Yuri,

here is the patch with a link-layer size of 256 bytes.

Helmut

Falls RHS ihn nicht schon vorher postet kann ich es morgen Nachmittag tun.

Helmut

Hallo Yuri,
I think your new CAM ignores the negotiated buffersize of 255 bytes and send the data in 256 byte-blocks without notifying the driver.

The Old CAM fills the buffer of 255 bytes in thsi way (4 x 60 + 15 bytes)

[36462.365365] CI_read_CMD_REPLY   : [06] 255/60/195
[36462.397236] CI_read_CMD_REPLY   : [06] 195/60/135
[36462.429354] CI_read_CMD_REPLY   : [06] 135/60/75
[36462.461349] CI_read_CMD_REPLY   : [06] 75/60/15
[36462.493342] CI_read_CMD_REPLY   : [06] 15/15/0

And your new CAM (4 x 60 +16 bytes)

[95684.661847] CI_read_CMD_REPLY   : [06] 0/0/0 --> means 256/60/196
...
[95684.693988] CI_read_CMD_REPLY   : [06] 196/60/136
[95684.725924] CI_read_CMD_REPLY   : [06] 136/60/76
[95684.757780] CI_read_CMD_REPLY   : [06] 76/60/16
[95684.789930] CI_read_CMD_REPLY   : [06] 16/16/0

I use a buffersize of 255 bytes because there is only a 8-bit size-field in the msg-header (0..255).

But when i assume, that a 0-byte TPDU never can occure, then i can increase the drivers buffersize to 256 bytes.

I will modify the driver in this way and post the patch tomorrow.

Helmut

Here is the patch - more a proof of concept - Let's see.

The more_core_info.diff is also included.

Helmut

I think see the problem:

[  546.143489] CI_read_CMD_REPLY   : [06] 0/0/0
[  546.143500] CA_recv_TPDU : *** ERROR *** TPDU too large (frag_size = 18446744073709551614 > 4094)

The CAM report that it has some data for the host, the CAM status-byte indicates "data ready" but the actual read gives 0 bytes of data. And as CA_recv_TPDU() does not expect zero-len data this ends in an error.

I will send you a first patch tonight.

Helmut

Zitat von SHF

Witziger weise laufen die Karten auch mit dem r8169 ohne Firmware

Die Firmware die nachgeladen wird dürfte auch nur ein Patch sein und keine Vollständige die zum Betrieb notwendg ist.

Mein J3455-ITX läuft auch ohne den fw-patch problemlos (abe auch ohne DD) - hab ihn einfach nie installiert.

Mit dmesg | greo r816 sehe ich diese Melung (aus r8169.c):

netif_warn(tp, ifup, tp->dev, "unable to load firmware patch %s (%d)\n",

Helmut

Hi Yuri,

can you apply this patch (no fix, only more logging) an post the output.

Helmut

The driver itself polls the CAMs status byte only every 2 seconds to detect insertions/removes, and you can change it here:

ca_dev->ca_task.delay = HZ * 2; /* 2 sec */

But VDR itself regularly queries the the CAM by writing short PDUs to see if the CAM has some data to send,

And for this writes the status byte has to be read too. I dont know how often these queries are done, you could check it by insert a pr_info("...") at the beginning of the function ca_write() (line 554).

Helmut

Hi Yuri,
for me it looks like some kind of race condition between a CAM request ('cc_data_req' after a 5 second delay) and the regulary polled CI status from the driver.

Does this occur on every (new) CAM initilalization or only once and then ?

But I will check it.

Helmut

Zitat von kls

Ich habe versuchsweise mal das Videoverzeichnis auf eine über NFS gemountete Platte gelegt und vier gleichzeitige Aufnahmen gemacht. Kein Poblem.

Jetzt wäre ein anderer Test noch interessant -ein rsync ohne Netzwerk z.B auf eine USB-Disk oder zumindest in eine andere Partition oder Unterverzeichnis auf der lokalen Disk. Vielleicht kann man dann den Netzwerkadapter als Mitverursacher auschließen.

Helmut

Wird die Netzwerklast und damit der Fehler nur durch die Datensicherung erzeugt (mit Fetsplattenzugriff) oder passiert das auch beim übertragen eines Live-Stream (ohne Diskzugriff) über das Netzwerk vom VDR?

Helmut

Eine Suche hier im Forum bringt ja etliche Treffer zu ddbridge und i2c-timeouts - zum Teil schon 6 Jahre alt und meistens in Kombination mit Asrock Boards. Eine finale Lösung habe ich nirgends herausgelesen.

Auch wenn es möglicherweise ain anderes Problem ist (s. hier) und du die Treiberoption msi=0 schon ausprobiert hast würde ich, um es wirklich ausschließen zu können, mit der Kernel-Boot Option "pci=nomsi" MSI einmal global abschalten und beobachten (msi-howto Pkt.5.1 und 5.2).

Ich habe übrigens die ITX Version von deinem Boardmit einer DVBSky Karte . Den i2c Fehler gibt es in dieser Kombination nicht (dafür andere Eigenarten bei den USB Ports - irgendwie finde ich das MB nicht ganz astrein obwohl VDR sonst gut drauf läuft).

Helmut

Es gibt nur 3 CA-Pids die aber für alle 4 Sendern gelten. Eigentlcih sollte hinter jeder Pid "#4" stehen, aber wie es aussieht wird die CA-Pid von jedem Programm 4 mal an cReceiver::AddPid() / DelPid() gemeldet. Das ist mir schon bei deinem Post #18 aufgefallen.

Warum das so ist kann ich jetzt nicht sagen, möglicherweise hat es auch etwas mit MTD (?) zu tun.

Helmut

Bei &IndexTs->offsetgibt es einen Fehler wegen dem Pointer ein bit-field.

Aber so bemängelt gcc-8.2.0 in recording.c nichts mehr:

--- recording.c.orig    2018-03-17 11:56:13.000000000 +0100
+++ recording.c    2019-03-27 19:50:48.926806610 +0100
@@ -2634,7 +2634,7 @@ void cIndexFile::ConvertToPes(tIndexTs *
         IndexPes.type = uchar(IndexTs->independent ? 1 : 2); // I_FRAME : "not I_FRAME" (exact frame type doesn't matter)
         IndexPes.number = uchar(IndexTs->number);
         IndexPes.reserved = 0;
-        memcpy(IndexTs, &IndexPes, sizeof(*IndexTs));
+        memcpy((char *)IndexTs, &IndexPes, sizeof(IndexPes));
         IndexTs++;
         }
 }

Helmut

Das mit der Warnung habe ich erwartet.

In der Eränzung von meinem letzten Post hätte ich mir die Zeile so vorgstellt: memcpy(&IndexTs->offset, &IndexPes, sizeof(IndexPes)); - vielleicht lässt es gcc dann als "trivial" durchgehen obwohl es nach dem Datentype eigentlich mmer noch nicht richtig passt.

Ich werde es am Abend ausprobieren.

Helmut

Hab ich übersehen - IndexPes ist ja kein Pointer sondern die struct selbst, also nun ohne "*" -> memcpy(IndexTs, &IndexPes, sizeof(IndexPes));.

Helmut

Kleine Ergänzung: damit soll eigentlich nur der Fehler behoben werden, die Warnung wird vermutlich bleiben.

Ich kann es jetzt nicht ausprobieren, aber vieleicht braucht es dafür noch &IndexTS->offsetals erstes Argument.

RHS : Wenn du in ci.c, Zeile 1584 strncpy ebenfalls durch memcpy sollte diese Warnung auch nicht mehr auftauchen. Hier soll kein "C"-String in den Buffer geschrieben werden.

Die beiden strncpy() Aufrufe sind keine Fehler, memcpy(IndexTs, &IndexPes, sizeof(*IndexTs));in recording.c, Zeile 2637 allerdings schon;

Die Länge von struct tIndexPes (64 Bit) ist kleiner als die der struct tIndexTs es soll aber nur der Inhalt von IndexPes in die ersten 64 Bit von IndexTS kopiert werden. Also müsste hier memcpy(IndexTs, &IndexPes, sizeof(*IndexPes)); stehen.

Das kann - oder besser - wird die Ursache für den Speicherzugriffsfehler sein.

Helmut

Edit: ich sehe gerade das die Funktion ConvertToPes mit obigen Fehler eben nur bei Pes-Aufnahmen verwendet wird - das sind Aufnahmen mit der Endung ".vdr" ->

bool IsPesRecording = fileName && endswith(fileName, ".vdr");

Da das bei die eher nicht der Fall sein wird (oder?), kann der Speicherzufriffsfehler aber auch eine andere Ursache haben

Zur 3. Warnung:

Ich glaube es sollte genügen die Zeile 607 in recording.c inmemcpy(p, buf, 3); zu ändern.

Hier wird ein Zeichen durch einen 3 Byte Hexcode ersetzt - deshalb zuerst die Verschiebung des String um 2 Bytes nach hinten um Platz zu schaffen. Das '0'-Byte des Ersatzstring darf nicht mitkopiert werden, ein strncpy(p, buf, 4); wie im Patch schneidet den String gleich nach der ersten Ersetzung ab.

Helmut

Das Problem mit den shared CA-Pids ist ja mit dem Patch in Post #17 eigentlich schon gelöst.

Trotzdem hier der Versuch einer Lösung für alle Pids die von cReceiver im Device hinzugefügt/entfernt werden.

Der kleine Patch im Anhang erkennt mittels eines Referenzzählers in cReceiver nun shared Pids und handelt dementsprechend.

Und hier das Log bei laufender Aufnahme auf ORF1, umschalten auf ORF2 (gleiche CA-Pid) und wieder zurückschalten auf ORF1. Sieht vernünftig aus, allerdings kann ich es nicht zu 100% testen da beim Simpli-TV Module CaPmts mit "Update" nicht richtig zu funktionieren scheinen.

vdr[15597]: [15597] switching to channel 1327 T-8232-101-14102 (ORF2 W HD)
vdr[15597]: [15710] osdteletext-receiver thread ended (pid=15597, tid=15710)
vdr[15597]: [15597] buffer stats: 0 (0%) used
vdr[15597]: [15597] cReceiver: add shared PID (Pid = 1019 #2)
vdr[15597]: [15597] creating directory /var/cache/vdr/osdteletext/T-8232-101-14102
vdr[15597]: [15724] osdteletext-receiver thread started (pid=15597, tid=15724, prio=high)
vdr[15597]: [15707] [xine..put] H.264: Found NAL SPS at offset 6/889
vdr[15597]: [15707] [xine..put] H.264 SPS: profile_idc 100
vdr[15597]: [15707] [xine..put] H.264 SPS: pic_width:  80 mbs
vdr[15597]: [15707] [xine..put] H.264 SPS: pic_height: 45 mbs
vdr[15597]: [15707] [xine..put] H.264 SPS: frame only flag: 1
vdr[15597]: [15707] [xine..put] H.264 SPS: aspect_ratio_idc 1
vdr[15597]: [15707] [xine..put] H.264 SPS: -> aspect ratio 1 / 1
vdr[15597]: [15707] [xine..put] H.264 SPS: -> video size 1280x720, aspect 1:1
vdr[15597]: [15707] [xine..put] Detected video size 1280x720
...
vdr[15597]: [15597] cReceiver: keep shared PID (Pid = 1019 #1)
vdr[15597]: [15597] switching to channel 1326 T-8232-101-14101 (ORF1 HD)
vdr[15597]: [15724] osdteletext-receiver thread ended (pid=15597, tid=15724)

Helmut