I2C Timeouts mit ddbridge

9000H · March 31, 2019 at 12:44 PM

Hi,

http://asrock.pc.cdn.bitgravity.com/BIOS/CPU/J3455-ITX(1.50)ROM.zip

http://asrock.pc.cdn.bitgravity.com/BIOS/CPU/J3455-ITX(1.60)ROM.zip

CU

9000h

SHF · March 31, 2019 at 2:11 PM

Da es ja bei rjkm geht, könnte es auch am Kernel liegen.

Anfangs gab es Probleme, weil die Boards noch nicht unterstützt waren, das sollte aber jetzt von Tisch sein.

Dann meine ich mich zu erinnern, dass es auch mit den Spectre/Meltdown Patches und einigen PCIe Devices Ärger gab.

Die sollte man zum Test mal deaktivieren. Aber allein das ist wohl schon ein umfangreicheres Thema: Ubuntu: MitigationControls

SuSE ist da, zumindest anfangs, einen eigenen Weg gegangen. Die haben da einiges an zurück portiert.

Im Zweifelsfall würde ich es noch mit einem neuen Kernel, bzw. einer anderen Distro (am besten der von rjkm) versuchen.

HelmutB † · March 31, 2019 at 5:17 PM

Quote from 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

kls · March 31, 2019 at 9:17 PM

Ich habe jetzt das J3455M gegen eines getauscht, das noch BIOS 1.20 hatte, und dieses auf 1.60 upgedatet.

Der Fehler tritt auch hier auf, so dass die Tatsache, dass es bei rjkm keine Probleme gibt, offensichtlich nicht mit der BIOS-Version zusammenhängt.

Weitere Tests mach ich in den nächsten Tagen.

rjkm welche Linux-Distri und welchen Kernel verwendest du denn?

rjkm · March 31, 2019 at 11:12 PM

Debian unstable mit Standard Debian kernel 4.19.0-1 + mein dddvb git (letzteres hat keine Änderungen, die bzgl. des Problems relevant wären).

Da aber wirklich der PCIe-Link "wackelt", glaube ich nicht, daß es am Kernel liegt, eher an Einstellungen an den PCIe-PHYs. Und die werden im Kernel soweit ich weiß normalerweise nicht angefaßt, nur im BIOS.

Da ich die Probleme, als sie noch auftraten, bei weiterer Belastung der CPU hatte (ich habe immer zum Test ein Kernel gleichzeitig gebaut), kann natürlich noch ein Unterschied ziwschen dem J3355M und dem J3455M bestehen, da letzterer 2 Kerne mehr hat.

wirbel · April 1, 2019 at 8:41 AM

PCIe wackelt? Irgendwelche interrupts tauchen schneller auf als die CPU erwartet, die CPU beschäftigt sich nur noch damit und wird langsam für alles andre.

Nach etwas googlen steht CMCI für 'Corrected Machine Check Interrupt', also ein hardware error flag, während die grub doku in dem Zusammenhang auf 'shared banks', also den Speicher verweist. Anscheinend hat jede Speicherbank einen eigenen Counter und fehler werden dann doppelt gemeldet. Machine check error deutet aber auch darauf hin, dass es ein hardware error ist, aber nicht nur der Speicher in Frage käme.

https://en.wikipedia.org/wiki/Interrupt_storm

https://access.redhat.com/solutions/367773

mce=no_cmci

Disable CMCI(Corrected Machine Check Interrupt) that

Intel processor supports. Usually this disablement is

not recommended, but it might be handy if your hardware

is misbehaving.

Note that you'll get more problems without CMCI than with

due to the shared banks, i.e. you might get duplicated

error logs.

kls · April 1, 2019 at 12:00 PM

Mit "mce=no_cmci" immer noch der gleiche Fehler.

Das Problem tritt übrigens auf drei Exemplaren des J3455M, mit zwei Sätzen von Speicherchips auf. Ein Hardwareproblem scheint mir da eher unwahrscheinlich zu sein.

davie2000 · April 1, 2019 at 6:43 PM

off topic: Boah ... das liest sich ja wie ein Krimi ... bin ich gespannt auf den "Mörder"!

wirbel · April 1, 2019 at 6:50 PM

..im Zweifelsfall ist es immer der Gärtner.

kls · April 1, 2019 at 11:11 PM

Ich habe jetzt https://cdn.kernel.org/pub/linux/kern…-4.19.32.tar.xz geholt und installiert (auf dem openSUSE-System, wo alle bisherigen Versuche stattgefunden haben). Mit diesem Kernel lief der rsync zwar etwas länger als mit dem vorherigen Kernel, der Fehler trat aber auch wieder auf.

Bei diesem Kernel ist der ddbridge-Treiber 0.9.33 dabei. Wenn ich die Version 0.9.37 übersetze erhalte ich bei 'make install'

Code

DEPMOD  4.19.32-lp150.12.48-default
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/pci/pt1/earth-pt1.ko needs unknown symbol dvb_module_release
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/pci/pt1/earth-pt1.ko needs unknown symbol dvb_module_probe
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/pci/pt3/earth-pt3.ko needs unknown symbol dvb_module_release
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/pci/pt3/earth-pt3.ko needs unknown symbol dvb_module_probe
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/pci/ngene/ngene.ko needs unknown symbol dvb_module_release
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/pci/ngene/ngene.ko needs unknown symbol dvb_module_probe
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/usb/dvb-usb-v2/dvb-usb-af9015.ko needs unknown symbol dvb_module_release
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/usb/dvb-usb-v2/dvb-usb-af9015.ko needs unknown symbol dvb_module_probe
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/usb/dvb-usb-v2/dvb-usb-gl861.ko needs unknown symbol dvb_module_release
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/usb/dvb-usb-v2/dvb-usb-gl861.ko needs unknown symbol dvb_module_probe
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/usb/dvb-usb-v2/dvb-usb-dvbsky.ko needs unknown symbol dvb_module_release
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/usb/dvb-usb-v2/dvb-usb-dvbsky.ko needs unknown symbol dvb_module_probe
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/usb/cx231xx/cx231xx-dvb.ko needs unknown symbol dvb_module_release
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/usb/cx231xx/cx231xx-dvb.ko needs unknown symbol dvb_module_probe
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/usb/em28xx/em28xx-dvb.ko needs unknown symbol dvb_module_release
depmod: WARNING: /lib/modules/4.19.32-lp150.12.48-default/kernel/drivers/media/usb/em28xx/em28xx-dvb.ko needs unknown symbol dvb_module_probe
make[1]: Leaving directory '/home/Mirror/Kernel/linux-4.19.32'

Display More

und bei dem Versuch, ihn zu laden

modprobe: ERROR: could not insert 'ddbridge': Invalid argument

Weiß jemand, was da schief läuft?

Ich würde gerne noch die Kombination Kernel 4.19.32 mit ddbridge 0.9.37 testen.

SHF · April 3, 2019 at 12:11 AM

Falsche Kernel-Header? Ist aber nur geraten.

Im Zweifelsfall alle deinstallieren, die nicht verwendet werden sollen.

Quote from rjkm

Die LEDs zeigen, daß der PCIe-Link instabil wird

Gibt es eine Beschreibung was die genau anzeigen?

ich konnte nichts finden.

Code

lspci -vv

Gibt einiges an Einstellungen der PCIe Geräte aus.

Das könnte man auch noch vergleichen, vielleicht sieht man da Unterschiede.

Zum BIOS:

Das jeweilige vom J3355M und J3455M ist binär identisch.

Daran kann es jedenfalls nicht liegen, dass es bei rjkm geht und bei kls nicht.

kls · April 3, 2019 at 11:43 AM

Ich bin jetzt wieder auf meinen ursprünglichen Kernel 4.12.14 zurückgegangen und habe den rsync nicht über das Netzwerk geschickt, sondern auf eine lokale (externe) USB-Platte. Dieser Versuch läuft inzwischen seit eineinhalb Stunden störungsfrei (der rsync über das Netzwerk brachte den Fehler immer bereits nach kurzer Zeit). Parallel dazu lasse ich 8 gleichzeitige Aufnahmen auf 4 Devices laufen!

Man kann also wohl davon ausgehen, dass das Problem am Netzwerktreiber liegt (wie hier bereits vermutet).

Allerdings läuft hier bereits der Treiber r8169:

#> ethtool -i eth0

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

Soeben kam im Log diese Meldung:

kernel: [ 6046.137805] r8169 0000:01:00.0: invalid large VPD tag 7f at offset 0

Der rsync, die 8 Aufnahmen und die Wiedergabe laufen aber störungsfrei weiter.

Jetzt habe ich parallel dazu nochmal den rsync über das Netzwerk gestartet und nach wenigen Sekunden trat der Fehler wieder auf.

Den Output von 'lspci -vv' hänge ich an (zu lang für die Message).

Hat jemand eine Idee, was ich als nächstes versuchen könnte?

Piet · April 3, 2019 at 12:34 PM

Das schreit eigentlich nach einem Test mit einer anderen NIC, Intel oder so. Noch einen Slot frei?

davie2000 · April 3, 2019 at 12:42 PM

Glaub zwar nicht, dass es dir viel hilft (weil offenbar andere Karte mit anderem Chipset), aber hier meine Ausgabe von "lspci -vv" für "Ethernet".

Mir fällt zB auf, dass bei dir unter "Capabilities" öfter "+" steht, wo bei mir ein "-" ist; hab aber keine Ahnung, ob das was bedeutet.

Ausgabe 'lcpci -vv' Abschnitt "Ethernet"

Code

05:00.0 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet (rev c0)
        Subsystem: ASRock Incorporation Device 1083
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 45
        Region 0: Memory at fb100000 (64-bit, non-prefetchable) [size=256K]
        Region 2: I/O ports at d000 [size=128]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000fee0300c  Data: 41e1
        Capabilities: [58] Express (v1) Endpoint, MSI 00
                DevCap: MaxPayload 4096 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
                        ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 unlimited
                        ClockPM+ Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Capabilities: [6c] Vital Product Data
pcilib: sysfs_read_vpd: read failed: Connection timed out
                Not readable
        Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP- SDES+ TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
        Capabilities: [180 v1] Device Serial Number ff-e6-40-ba-00-25-22-ff
        Kernel driver in use: atl1c

Display More

9000H · April 3, 2019 at 12:44 PM

Hi,

versuch doch mal den driver von Realtek selbst zB https://github.com/airium/Realtek-PCIe-GBE-NIC-Driver

CU

9000h

kls · April 3, 2019 at 4:57 PM

Piet Ein PCIe-Slot wäre zwar frei, der Einbauplatz ist aber belegt durch eine Receiver-Karte.

9000H Hab den Realtek-Treiber installiert:

Code

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: no

Display More

Der Fehler trat aber beim rsync nach wenigen Sekunden wieder auf :-(.

kls · April 3, 2019 at 5:12 PM

Könnten vielleicht mal einige von euch versuchen, ob sie den Fehler, den ich hier beobachte, nachvollziehen können?

Die Vorgehensweise ist:

- ein System mit DD Cine S2 V7A

- laufender VDR

- ein großes Verzeichnis (z.B. das Video-Directory) mit 'rsync -a' über das Netzwerk auf einen anderen PC kopieren

- das Logfile im Blick halten und auf Meldungen wie im Eingangspost achten

Nach kurzer Zeit tritt damit bei mir der Fehler zuverlässig auf.

Wäre interessant, ob das auch bei anderen passiert.

ACHTUNG: sobald der Fehler auftritt hilft nur noch ein Reboot! Also nicht während "produktivem" Betrieb testen!

vdr_rossi · April 3, 2019 at 6:56 PM

Ein "Workaround" wäre eventl. eine USB Netzwerkkarte zu verwenden. Das Board hat auch ein USB-C Anschluss onboard.

Muss man sehen wie das da mit Treibern und vor allen Dingen mit Geschwindigkeit bestellt ist...

Nur so als Idee.

speed · April 3, 2019 at 7:43 PM

Hallo,

also das wäre für mich kein "Workaround" wenn schon eine Lan Karte einbauen.

Eine Intel wäre eine Option.

speed

vdr_rossi · April 3, 2019 at 8:14 PM

Naja, wenn der freie PCIe Slot aber von der Tunerkarte überlagert ist...

I2C Timeouts mit ddbridge

Participate now!

Users Viewing This Thread