Hi,
kannst noch pci=pcie_bus_safe versuchen.
CU
9000h
Hi,
kannst noch pci=pcie_bus_safe versuchen.
CU
9000h
pci=pcie_bus_safe hat leider auch nichts gebracht.
Hast du mal mit den CPU Stromsparmodi gespielt?
Ich habe jetzt mal
Intel SpeedStep Technology
CPU C States Support
Enhanced Halt State (C1E)
alle auf "Disabled" gesetzt und den rsync laufen lassen.
Nach gefühlt in etwa der Zeit, die vorher verging, bis der Fehler auftrat, kamen solche Meldungen:
Mar 29 17:23:19 vdr3 kernel: [ 334.170901] CMCI storm detected: switching to poll mode
Mar 29 17:28:20 vdr3 kernel: [ 634.723167] CMCI storm subsided: switching to interrupt mode
Mar 29 17:29:21 vdr3 kernel: [ 696.086885] perf: interrupt took too long (2537 > 2500), lowering kernel.perf_event_max_sample_rate to 78750
(dazwischen andere, normale VDR-Meldungen). Sowohl VDR als auch rsync liefen aber die ganze Zeit störungsfrei.
Ich lasse das jetzt mal weiter laufen und beobachte...
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.
Zu früh gefreut - der Fehler ist wieder aufgetreten :-(.
Nachdem das Problem auf zwei verschiedenen Rechnern mit gleichen Motherboard und DD-Boards auftritt, sollte ich wohl mal ein anderes MB versuchen. Was wäre denn als Alternative zum Asrock J3455M geeignet? Sinnvollerweise wohl von einem anderen Hersteller.
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.
Wenn 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?
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.
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:
CPU0 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 event
Alles anzeigen
Und hier kurze Zeit nachdem der Fehler auftrat:
CPU0 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
Alles anzeigen
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
CU
9000h
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 :
(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
Natü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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!