Hi,
kannst noch pci=pcie_bus_safe versuchen.
CU
9000h
I2C Timeouts mit ddbridge
-
-
Hast du mal mit den CPU Stromsparmodi gespielt?
-
Möglicherweise ist deine CPU oder deren Spannungsregler auf dem MB zu langsam und läuft beim wakeup in ein timeout, wenn sie wegen eines Interrupts aufgeweckt wird.
-
Selbst das Ausführen des Reboots dauert eine Weile. Aber immerhin schafft er es, wieder hochzukommen. Ein Reset ist nicht nötig.
Man könnte versuchen, ob es reicht nur den VDR zu beenden und die Kartentreiber zu entladen
(runvdr).
Zur Belüftung des Gehäuses habe ich einen langsam drehenden Lüfter in Betrieb, so dass ein Wärmestau eigentlich auch ausgeschlossen sein dürfte.
Trotzdem können einzelne Komponenten zu warm werden, wenn sie nicht genug Luft abbekommen.
DVB-Hardware würde ich bei den geschilderten Symptomen inzwischen für unwahrscheinlich halten.Wenn der Prozessor zu warm wird und ins throttling gerät könnte das aber passen.
Die CPU-Temperatur ist aber einfach zu überprüfen.
Da jetzt einige Meldungen mit Interrupts kamen, wäre es interessant mal zu schauen, was sich da tut.
Codewatch -tn1 cat /proc/interruptsWenn die Meldungen stimmen, muss irgend ein Gerät das System mit Interrupts fluten. Das müsste man eindeutig sehen können.
Da der Fehler durch kopieren von Daten über das Netzwerk zu provozieren ist, gerät die Netzwerkkarte auch in Verdacht.
Zu dem RTL8111 gibt es auch einen alternativen Treiber (r8168), der nicht im Kernel ist. Der könnte einen Versuch wert sein.
Den musste ich anfangs (einige Jahre her) verwenden, weil der aus dem Kernel (r8169) noch nicht so recht wollte. Debian bietet den r8168 als DKMS-Paket (non-free) an, SuSE weiss ich leider nicht.
Verteilen sich die Interrupts denn einigermassen gleichmässig über die CPU-Kerne?
Was wäre denn als Alternative zum Asrock J3455M geeignet? Sinnvollerweise wohl von einem anderen Hersteller.
Von Asrock gibt es einen Nachfolger mit J4105 Celeron (µATX).
Mit der oder einer ähnlichen CPU gibt es sonst nur ITX-Boards. D.h. du hättest nur einen Slot.
Da ist die Auswahl aber recht übersichtlich, ein zwei Boards pro Hersteller, insgesamt keine 10.
Wenn man Asrock ausklammert, sieht es bei den aktuellen CPUs aber (noch?) schlecht aus.
Bei den aktuellen Sockel 1151v2 Boards hat Fujitsu zwei im Angebot, recht interessant aussehen: D3642-B und D3643-H
Intel NIC, sehr schön aufgeräumt und sparsam sollen die auch sein.
Die Boards erinnern mich an die, die Intel früher selber verkauft hat.
MSI hat auch "kleine", nicht überladene 1151v2 Boards mit Intel-NIC am draussen.
-
Flackern die LEDs auf dem Cine-Board, z.B. wenn gleichzeitig das Netzwerk belastet ist?
Nimmt das Board denn z.B einen Downgrade auf das 1.80 BIOS an?
-
Man könnte versuchen, ob es reicht nur den VDR zu beenden und die Kartentreiber zu entladen
(runvdr).
Das reicht leider nicht. Der Treiber lässt sich meist auch gar nicht komplett entfernen, da noch Teile in Benutzung sind.
Wenn der Prozessor zu warm wird und ins throttling gerät könnte das aber passen.
Die CPU-Temperatur ist aber einfach zu überprüfen.
Im Normalbetrieb mit langsam laufendem Lüfter und aktivem vaapidevice beträgt die CPU-Temparatur ca. 58 Grad.
Lasse ich den Lüfter mit maximaler Geschwindigkeit laufen, geht sie runter auf ca. 48 Grad.
In beiden Fällen, und auch ohne geladenes vaapidevice-Plugin, tritt der Fehler bei Netzwerklast nach kurzer Zeit auf. Ohne Netzwerklast läuft es stabil die ganze Nacht über.
Da jetzt einige Meldungen mit Interrupts kamen, wäre es interessant mal zu schauen, was sich da tut.
Hier die Interrupts nach einiger Zeit Betrieb (mit Netzwerklast) vor dem Fehler:
Code
Alles anzeigenCPU0 CPU1 CPU2 CPU3 0: 24 0 0 0 IO-APIC 2-edge timer 8: 0 0 0 0 IO-APIC 8-fasteoi rtc0 9: 0 0 0 0 IO-APIC 9-fasteoi acpi 14: 0 0 0 0 IO-APIC 14-fasteoi INT3452:00, INT3452:01, INT3452:02, INT3452:03 120: 0 0 0 0 PCI-MSI 311296-edge PCIe PME 121: 0 0 0 0 PCI-MSI 313344-edge PCIe PME 122: 0 0 0 0 PCI-MSI 315392-edge PCIe PME 123: 0 0 0 0 PCI-MSI 317440-edge PCIe PME 124: 532 0 41307 0 PCI-MSI 294912-edge ahci[0000:00:12.0] 125: 3461453 0 0 0 PCI-MSI 1572864-edge ddbridge 126: 47074 0 40463 0 PCI-MSI 344064-edge xhci_hcd 127: 336 8853373 0 0 PCI-MSI 32768-edge i915 373: 29 0 0 0 PCI-MSI 245760-edge mei_me 374: 138 0 0 3076073 PCI-MSI 524288-edge eth0 375: 545644 0 0 0 PCI-MSI 229376-edge snd_hda_intel:card0 NMI: 135 140 140 130 Non-maskable interrupts LOC: 3041946 5442493 3464806 2967821 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 135 140 140 130 Performance monitoring interrupts IWI: 2366328 3038938 3628743 2755808 IRQ work interrupts RTR: 0 0 0 0 APIC ICR read retries RES: 2986155 2888259 3614110 3122795 Rescheduling interrupts CAL: 12671 5597 5297 4066 Function call interrupts TLB: 44 20 57 52 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts DFR: 0 0 0 0 Deferred Error APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 44 44 44 44 Machine check polls ERR: 0 MIS: 0 PIN: 0 0 0 0 Posted-interrupt notification event NPI: 0 0 0 0 Nested posted-interrupt event PIW: 0 0 0 0 Posted-interrupt wakeup eventUnd hier kurze Zeit nachdem der Fehler auftrat:
Code
Alles anzeigenCPU0 CPU1 CPU2 CPU3 0: 24 0 0 0 IO-APIC 2-edge timer 8: 0 0 0 0 IO-APIC 8-fasteoi rtc0 9: 0 0 0 0 IO-APIC 9-fasteoi acpi 14: 0 0 0 0 IO-APIC 14-fasteoi INT3452:00, INT3452:01, INT3452:02, INT3452:03 120: 0 0 0 0 PCI-MSI 311296-edge PCIe PME 121: 0 0 0 0 PCI-MSI 313344-edge PCIe PME 122: 0 0 0 0 PCI-MSI 315392-edge PCIe PME 123: 0 0 0 0 PCI-MSI 317440-edge PCIe PME 124: 532 0 63131 0 PCI-MSI 294912-edge ahci[0000:00:12.0] 125: 3495173 0 0 0 PCI-MSI 1572864-edge ddbridge 126: 47534 0 40463 0 PCI-MSI 344064-edge xhci_hcd 127: 336 8942310 0 0 PCI-MSI 32768-edge i915 373: 29 0 0 0 PCI-MSI 245760-edge mei_me 374: 138 0 0 4659384 PCI-MSI 524288-edge eth0 375: 551129 0 0 0 PCI-MSI 229376-edge snd_hda_intel:card0 NMI: 145 159 150 148 Non-maskable interrupts LOC: 3077350 5491570 3522225 3004929 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 145 159 150 148 Performance monitoring interrupts IWI: 2379965 3066845 3697604 2763960 IRQ work interrupts RTR: 0 0 0 0 APIC ICR read retries RES: 3057852 2922258 3720193 3579782 Rescheduling interrupts CAL: 14578 6520 5325 4090 Function call interrupts TLB: 46 27 64 68 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts DFR: 0 0 0 0 Deferred Error APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 44 44 44 44 Machine check polls ERR: 0 MIS: 0 PIN: 0 0 0 0 Posted-interrupt notification event NPI: 0 0 0 0 Nested posted-interrupt event PIW: 0 0 0 0 Posted-interrupt wakeup event -
Hi,
mein Realtek driver/firmware
ethtool -i enp1s0
driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl8168g-2_0.0.1 02/06/13
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
CU9000h
-
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
-
Ohne Netzwerklast leuchten die ersten beiden LEDs (von der Hinterkante mit dem TAB2-Stecker her gezählt) permanent, die anderen 3 sind aus.
Mit Netzwerklast blinkt die 5. LED. Sobald der Fehler auftritt leuchtet auch diese permanent, und ich meine, dass die dritte dann ganz schwach leuchtet.
Den Downgrade auf BIOS 1.80 hat das Board angenommen, am Verhalten hat sich aber dadurch nichts geändert.
Die LEDs zeigen, daß der PCIe-Link instabil wird.
Das gleiche hatte ich mit BIOS <1.60 auch. Mit dem 1.60 konnte ich es nicht mehr provozieren.
Ich nehme also an, daß die in >=1.70 wieder etwas geändert haben.
Leider kann man wohl auf das 1.60 nicht zurück.
-
2 x DD Cine S2 V7A
werden LNBs direkt aktiv über diese Karten mit Spannung versorgt? Wenn ja, ist der Spannungsstecker zum Netzteil hinten drauf?
Ich frage deswegen, weil bei manchen PCB-Layouts vom PCIe auf dem MB die Stromversorgungspfade etwas ungünstig designt wurden. Dadurch könnte die PCIe Versorgung in die Knie gehen und instabil werden. DD empfiehlt ab 5 Watt LNB-Verbrauch den Stromstecker zu verwenden.
-
Ich nehme also an, daß die in >=1.70 wieder etwas geändert haben.
Leider kann man wohl auf das 1.60 nicht zurück.
Ich habe noch ein solches Board, welches noch BIOS 1.20 hat.
Aber leider gibt es auf der ASRock Download-Seite die Version 1.60 nicht (mehr).
Hast du die vielleicht noch und könntest sie mit zum Testen zur Verfügung stellen?
-
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?
Ich habe versuchsweise mal das Videoverzeichnis auf eine über NFS gemountete Platte gelegt und vier gleichzeitige Aufnahmen gemacht. Kein Poblem. Möglicherweise kommen da aber nicht so viele Daten in so kurzer Zeit zusammen wie bei einem rsync.
-
werden LNBs direkt aktiv über diese Karten mit Spannung versorgt?
Die Karten sind an einem Multiswitch angeschlossen, der die LNBs versorgt. Da dürfte also keine große Last dranhängen.
-
Bei 60°C sollte thermal throttling eigentlich kein Thema sein.
Die Interruptverteilung sieht für mich auch grob sinnvoll aus. eth0 und DDbridge sind auch unterschiedlichen CPUs zugeordnet.
Die Zahlenwerte sind die aufgetretenen Interrupts seit Systemstart. Da ist es etwas schwer festzustellen, wenn ein Gerät amok läuft.
Da müsste man schauen, ob einer der Zähler ungewöhnlich schnell hoch (>1000/s) läuft.
Die Gesamtzahl der Interrupts pro Sekunde zeigt auch :
Codevmstat 1(Das 1 aktualisiert sekündlich, die Ausgabe in eine Datei umleiten ist also nicht verkehrt.)
Auch die anderen Werte von system und cpu könnten interessant sein. Erklaerung und Beurteilung der ausgegebenen Werte
Wenn der Fehler auftritt müsste man eigentlich irgendwas sehen. Eventuell kann man aus dem Zustand in dem die CPU dann läuft Rückschlüsse ziehen was da passiert.
Ich habe versuchsweise mal das Videoverzeichnis auf eine über NFS gemountete Platte gelegt und vier gleichzeitige Aufnahmen gemacht. Kein Poblem. Möglicherweise kommen da aber nicht so viele Daten in so kurzer Zeit zusammen wie bei einem rsync.
Was passiert denn, wenn man den Prozessor etwas traktiert
Codenice -n19 cat /dev/zero > /dev/nullNatürlich einmal je CPU-Kern.
Wenn das alleine keine Probleme verursacht, dann zusammen mit rsync.
Unter Umständen verbessert sich die Stabilität dabei, weil der Prozessor nicht mehr runter taktet.
-
Ich habe noch ein solches Board, welches noch BIOS 1.20 hat.
Aber leider gibt es auf der ASRock Download-Seite die Version 1.60 nicht (mehr).
Hast du die vielleicht noch und könntest sie mit zum Testen zur Verfügung stellen?
Ich habe nur die vom J3355M (identisches Board nur mit 2-Core statt 4-Core Apollo-Lake).
Man kann aber anscheinend die alten runterladen, wenn man den Download-Link per Hand anpasst.
Soweit ich mich erinnere, mußte man auch erst 1.50 als "Bridge-BIOS" nehmen.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!