Dann wird es doof
I2C Timeouts mit ddbridge
-
-
Ist auf dem Board(s) ein ASmedia 1083 als PCIe to PCI Bridge?
Der hat nämlich Probleme mit Interrupts und es gibt keinen sinnvollen Workaround
https://www.spinics.net/lists/linux-btrfs/msg28010.htmlWurde auch schon mal hier diskutiert
-
FireFly : Danke für die Info.
Der Link hinter dem Link ist nicht ganz sauber, es fehlt ein Doppelpunkt.
So geht es besser:
https://www.spinics.net/lists/linux-btrfs/msg28010.html
-
Hi,
bei meinem Asrock J4205-ITX
Code
Alles anzeigen00:00.0 Host bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge (rev 0b) 00:02.0 VGA compatible controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Integrated Graphics Controller (rev 0b) 00:0e.0 Audio device: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster (rev 0b) 00:0f.0 Communication controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Trusted Execution Engine (rev 0b) 00:12.0 SATA controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SATA AHCI Controller (rev 0b) 00:13.0 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #1 (rev fb) 00:13.1 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #2 (rev fb) 00:13.2 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #3 (rev fb) 00:13.3 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #4 (rev fb) 00:15.0 USB controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series USB xHCI (rev 0b) 00:1f.0 ISA bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Low Pin Count Interface (rev 0b) 00:1f.1 SMBus: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SMBus Controller (rev 0b) 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11) 03:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02) 04:00.0 PCI bridge: Pericom Semiconductor Device 2304 (rev 05) 05:01.0 PCI bridge: Pericom Semiconductor Device 2304 (rev 05) 05:02.0 PCI bridge: Pericom Semiconductor Device 2304 (rev 05) 06:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter 07:00.0 Multimedia controller: Digital Devices GmbH Cine V7
CU
9000h
-
Ist auf dem Board(s) ein ASmedia 1083 als PCIe to PCI Bridge?
Sieht nicht so aus (siehe Attachment hier).
'lspci -d 1b21:1080 -v' liefert nichts.
-
Soeben kam im Log diese Meldung:
kernel: [ 6046.137805] r8169 0000:01:00.0: invalid large VPD tag 7f at offset 0Das kommt bei meinem Arbeitsrechner auch.
Ist mir aber eben erst aufgefallen. Probleme gibt es keine, auf dem System läuft aber kein VDR.
vorher:
driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl8168e-3_0.0.4 03/27/12
expansion-rom-version:
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
nachher:
driver: r8168
version: 8.046.00-NAPI
firmware-version:
expansion-rom-version:
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: noSieht hier genau so aus.
r8169 am Arbeitsrechner, r8168 am VDR.
Warum ich da den r8168 weiss ich nicht mehr. Wird aber einen Grund gehabt haben.
Merkwürdig ist, dass der r8168 keine Firmware braucht. Da ist nicht mal was dazu erwähnt.
Witziger weise laufen die Karten auch mit dem r8169 ohne Firmware. Das Phänomen ist mir vor Jahren mal aufgefallen.
Es gibt eine Fehlermeldung beim Laden des Moduls, gehen tut es aber trotzdem.
Das ganze sagt aber nicht unbedingt was aus. Es könnte sich um unterschiedliche Chips handeln, es gibt da so viele Varianten und Versionen.
Glaub zwar nicht, dass es dir viel hilft ...
Wirklich sinnvoll ist es nur die Ausgaben der DD- und der Realtekkarten auf möglichst ähnlichen Boards zu vergleichen.
Ein PCIe-Slot wäre zwar frei, der Einbauplatz ist aber belegt durch eine Receiver-Karte.
Könnte man die Huckepackkarte nicht testweise ausbauen oder verlängern?
Eine andere Netzwerkkarte wäre die einfachste Option das Problem einzugrenzen.
Ist auf dem Board(s) ein ASmedia 1083 als PCIe to PCI Bridge?
Ist nicht drauf.
Ausserdem hat nur die Rev. 01 den Fehler und die wird seit mindestens Mitte 2013 nicht mehr verbaut.
Bei neueren Mainboards sollte man sicher sein.
Meine beiden mit Rev. 03 laufen auch seit Jahren zuverlässig.
Bei der Suche bin ich zufällig auf diesen Artikel gestossen:
Der r8169-Treiber für den Realtek-Netzwerkchip funktioniert bis zur Kernelversion 4.16 nicht immer korrekt. Es können Timeouts entstehen, die Netzwerkkarte zwischen den Zuständen link up/link down wechseln sowie Bandbreitenprobleme oder sogar Systemabstürze vorkommen.
Eine Lösung des Problems besteht in der Installation des offiziellen r8168 Treibers von Realtek statt dem r8169 des Linux Kernels. Er kann aus Fremdrepositories nachinstalliert oder selbst kompiliert werden. Alternativ kann der Kernel auf Version 4.17+ aktualisiert werden.
[...]
-
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
-
Eine andere Netzwerkkarte wäre die einfachste Option das Problem einzugrenzen.
Ich habe jetzt mal so eine Karte bestellt
https://www.amazon.de/gp/product/B001CY0P7G
und werde es damit probieren.
rjkm Dein System scheint ja doch dem meinen recht ähnlich zu sein. Wäre es möglich, dass du mal den hier beschriebenen Test machst?
-
Eine gute Wahl
-
Ich habe jetzt mal so eine Karte bestellt
besteht denn das Platzproblem nicht mehr? Zur Diagnose wäre es sicher notwendig, wenn alle beteiligten Geräte im System wären.
Wenn Dein Gehäuse Platz dafür bietet, könntest Du einen PCIe Expander verwenden.
So was in der Art --> https://www.ebay.com/itm/PCI-E…80bb8b:g:W18AAOSwsq1cZ76G
Vielleicht nicht gerade den verlinkten, das Transfer Kabel wäre mir zu lang und vielleicht auch wieder fehleranfällig. Aber etwas mit 15-20cm sollte bestimmt funktionieren.
-
Das Platzproblem besteht nur bei meinem Wohnzimmer-VDR. Zum Testen habe ich einen zweiten, mit gleichem Motherboard, bei dem das Problem genauso auftritt, der aber Platz für eine separate Netzwerkkarte hat.
-
Hi,
oder so was https://www.ebay.com/itm/113632570882 , aber ich glaube es ist ein Kernel Problem.
CU
9000h
-
Heute wurde die Intel-Netzwerkkarte geliefert. Hab sie eingebaut, den onboard Netzwerk-Adapter im BIOS ausgeschaltet, die neue Karte konfiguriert und den Test gestartet. Bereits nach ein paar Sekunden trat exakt der gleiche Fehler wieder auf.
Ich fasse jetzt mal meine bisherigen Erkenntnisse zusammen:
1. Betreibt man auf einem ASRock J3455M-Motherboard mit einer DD Cine S2 V7A einen VDR, und macht parallel dazu einen 'rsync' großer Dateien (z.B. das VDR-Videoverzeichnis) über das Netzwerk auf einen anderen Rechner, so kommt es nach kurzer Zeit zu I2C-Timeouts. <edit>'options ddbridge msi=0' ist in /etc/modprobe.d/ddbridge.conf eingetragen.</edit>
2. Das Problem tritt nicht auf, wenn zwar der ddbridge-Treiber geladen ist (und der 'rsync' läuft), aber kein VDR läuft, da dann ja auch keine Zugriffe auf die DD-Devices stattfinden. Ich kann auch den VDR starten und nach einiger Zeit wieder beenden und dann erst den 'rsync' laufen lassen, was auch keine Probleme macht.
<edit>Ebenfalls tritt das Problem nicht auf wenn der 'rsync' (bei laufendem VDR) auf eine lokale (externe) USB-Platte erfolgt.</edit>
3. Das Problem ist nicht auf ein bestimmtes Exemplar des Motherboards beschränkt (habe es mit drei Examplaren des J3455M probiert).
4. Es ist nicht auf ein bestimmtes Exemplar der DD Cine S2 V7A beschränkt (habe mit drei verschiedenen getestet).
5. Es ist unabhängig von der BIOS-Version (getestet mit Version 1.20, 1.50, 1.60 und 1.90).
6. Es ist unabhängig von der Kernel-Version (getestet mit Kernel 4.12.14 und 4.19.32).
7. Es tritt sowohl mit dem onboard NIC (r8168) als auch einem Intel NIC (e1000e) auf.
Nachdem nun schon einige mögliche Fehlerquellen ausgeschlossen wurden, bleiben als mögliche Ursachen eigentlich nur
A. Ein Hardware-Design-Fehler auf dem J3455M Board.
B. Ein Hardware-Design-Fehler auf der DD Cine S2 V7A.
C. Ein Fehler in der DD-Firmware.
D. Ein Fehler im ddbridge-Treiber.
Bevor ich mir jetzt ein anderes Motherboard besorge und damit teste, wäre es nett, wenn jemand hier, der einen VDR mit DD Cine S2 V7A und einem *anderen* Board als das J3455M betreibt, den hier beschriebenen Test machen könnte.
-
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
-
Testen kann ich mangels DD-Karte leider nicht, aber trotzdem eine Frage dazu:
Rsync läuft auf ein, per nfs, samba oder was-auch-immer, gemountetes Verzeichnis, oder rsync direkt übers Netzwerk?
Keine Ahnung ob das einen Unterschied macht, aber besser man testet es auch genau so.
kpti=off nopcid nopti nospectre_v1 nospectre_v2 nospec_store_bypass_disable pr_spec_disable_noexec
Mit den Optionen sollten eigentlich alle Spectre-Geschichten deaktiviert sein. (Das hoffe ich zumindest mal.)
Ist einen Versuch wert, denke ich.
Da es auch mit einer anderen Netzwerkkarte zu den Problemen kommt, könnte man noch an den PCIe-Parametern drehen.
Ich vermute, dass die Cine wegen der vielen Pakete von der Netzwerkkarte zu selten an die Reihe kommt um ihren internen Puffer ganz leer zu bekommen. Eine Weile geht das, aber irgendwann kommt noch ein Ereignis, der Puffer läuft über und die Karte oder der Treiber hängt sich (warum auch immer) auf.
In dem Zusammenhang wäre es echt interessant, was die LED bedeutet.
Meine Vermutung ist, die hat mit dem Füllstand des FIFO auf der Karte zu tun. Das würde passen.
Das Problem trat so ähnlich schon bei den PCI-Karten auf. Bei den FF-Karten brachte ein erhöhen der PCI-Latency bei mir auch immer was an Stabilität. Mit der voreingestellten Latency konnten die Karten den internen Puffer nicht in einem Zug leeren, wenn er ganz voll war.
An den PCIe-Parametern habe noch nicht rumschrauben müssen, kann also nicht so genau abschätzen was es bringt.Ich würde aber mal versuchen die
MaxReadReq
der Cine, nach dieser Anleitung, auf4096
zu erhöhen.Man könnte auch noch versuchen die
MaxReadReq
Netzwerkkarte auf 512 zu senken.Eventuell könnte man auch die Priorität des DD-Treibers erhöhen.
Ob das auf Kernel-Ebene geht weiss ich aber nicht.
-
Bevor ich mir jetzt ein anderes Motherboard besorge und damit teste, wäre es nett, wenn jemand hier, der einen VDR mit DD Cine S2 V7A und einem *anderen* Board als das J3345M betreibt, den hier beschriebenen Test machen könnte.
Hi Klaus,
Apologies for the English. Not sure how useful it will be, but I have a predecessor board, an Asrock N3150M with a DD Cine S2 V7A and a TT S2 6400 and I occasionally rsync tens of GB without issue, although I can't guarantee VDR was running as well. The system is busy currently but I'll run a test in the next 24 hours and get back to you.
One thought I had. Ralph is running the dual core version of your board without issue and I think your board has two cores plus 2 hyperthreaded "cores", rather than 4 full cores.
Have you tried disabling hyperthreading, (not sure of the boot option for that)?
Regards,
Richard
-
Vielleicht lohnt es sich, den DD Support zu kontaktieren. IIRC ist der doch recht gut und kennt sicher die Bedeutung der LEDs.
Gruß,
Hendrik
-
Rsync läuft auf ein, per nfs, samba oder was-auch-immer, gemountetes Verzeichnis, oder rsync direkt übers Netzwerk?
Für den Test mache ich einen rsync direkt über das Netzwerk:
rsync -av vdr3:/video .
Ich habe aufgrund deiner Frage jetzt den rsync auch mal so gemacht, dass ich mich auf dem VDR-PC via ssh eingeloggt und auf ein dort via NFS gemountetes Volume kopiert habe. Damit lief der Test zwar relativ lange, aber nach einer knappen halben Stunde kam es wieder zu dem bekannten Fehler.
-
kpti=off nopcid nopti nospectre_v1 nospectre_v2 nospec_store_bypass_disable pr_spec_disable_noexec
Mit den Optionen sollten eigentlich alle Spectre-Geschichten deaktiviert sein. (Das hoffe ich zumindest mal.)
Ist einen Versuch wert, denke ich.Leider unverändert.
-
An den PCIe-Parametern habe noch nicht rumschrauben müssen, kann also nicht so genau abschätzen was es bringt.
Ich würde aber mal versuchen die MaxReadReq der Cine, nach dieser Anleitung, auf 4096 zu erhöhen.
Man könnte auch noch versuchen die MaxReadReq Netzwerkkarte auf 512 zu senken.Wenn ich gemäß dieser Anleitung
setpci -s 02:00.0 68.w
mache erhalte ich '0000'. Erwartet würde aber ein Wert wie '2936'.
Code
Alles anzeigenroot@vdr3:/home/kls > lspci 00:00.0 Host bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge (rev 0b) 00:02.0 VGA compatible controller: Intel Corporation Device 5a85 (rev 0b) 00:0e.0 Audio device: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster (rev 0b) 00:0f.0 Communication controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Trusted Execution Engine (rev 0b) 00:12.0 SATA controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SATA AHCI Controller (rev 0b) 00:13.0 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #1 (rev fb) 00:13.1 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #2 (rev fb) 00:13.2 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #3 (rev fb) 00:13.3 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #4 (rev fb) 00:15.0 USB controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series USB xHCI (rev 0b) 00:1f.0 ISA bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Low Pin Count Interface (rev 0b) 00:1f.1 SMBus: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SMBus Controller (rev 0b) 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) 02:00.0 Multimedia controller: Digital Devices GmbH Cine V7 root@vdr3:/home/kls > lspci -s 02:00.0 -vvv | grep DevCtl: -C 2 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes root@vdr3:/home/kls > setpci -s 02:00.0 68.w 0000
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!