Plantage total RPi4b - Serveur de temps NTP

Domatizer · Août 12, 2020, 4:37

Je comprends bien que le problème de base n’a rien à voir avec Jeedom. J’essaie juste d’avoir une solution Jeedom plus robuste.

J’ai de nouveau eu un plantage. Jeedom est cette fois-ci fonctionnel en partie. J’ai accès à distance (heureusement car n’étant pas présent sur place). La page Santé est toute au vert. Les daemons sont tous au vert aussi. Certains plugins (RFPlayer, ZWave) ne remontent plus les infos des capteurs, leurs daemons sont bien vert mais plus fonctionnel en réalité. Difficile de s’en rendre compte rapidement. Et rien dans les log, c’est comme si les choses étaient en pause.

Un redémarrage des daemons et les infos remontent de nouveau. Mais dans ces conditions, je ne peux pas savoir qui est réellement NOK. Je préfère redémarrer proprement Jeedom depuis l’interface Jeedom afin que tout rentre dans l’ordre et refonctionne jusqu’à la prochaine fois.

[EDIT] 8h d’uptime seulement !

Ça m’a vraiment gonflé, alors j’ai viré cette m.rde de fake-hwclock qui se lance toutes les heures à la 17ième minute comme ici
https://stackoverflow.com/questions/61155895/raspberry-pi-raspbian-reboot-issue-with-ssd

sudo apt-get remove fake-hwclock
sudo rm -f /etc/cron.hourly/fake-hwclock

Domatizer · Novembre 18, 2020, 9:13

Je ne m’en sors pas avec cette m.rd. de redémarrage foireux. J’en ai eu plusieurs depuis.

Mes essais
J’étais dans la configuration suivante : boot sur la carte SD et système sur le SSD
Au point où j’en étais, j’en ai profité pour tout remettre à jour y compris le firmware du RPi4b.

Ainsi, en suivant les tutos, j’ai pu booter directement sur le SSD. Super !
Les redémarrages foireux étaient plus fréquents.
N’ayant pas confiance aux ports USB du RPi. J’ai pensé au disque SSD. J’ai décidé de tout remettre sur une carte SD (spéciale Dashcam pour limiter l’usure prématurée).

Là, le système a tenu assez longtemps, au moins 2 mois. Je pensais être sortie d’affaire.
Mais, non, rebelote hier soir à 19h34m48s, tout le système domotique HS.

Je n’arrive toujours pas à trouver la cause du plantage qui le fait redémarrer le Pi tout seul.
J’ai constaté un petit pic de température à 50°C au lieu de 40-45°C. J’ai opté pour ce refroidisseur de compète (je n’alimente pas le ventilo)
https://www.amazon.fr/GeeekPi-Raspberry-Boîtier-Ventilateur-Aluminium/dp/B084S4CFCK/

Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000] Linux version 5.4.51-v8+ (dom@buildbot) (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9)) #1333 SMP PREEMPT Mon Aug 10 16:58:35 BST 2020
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000] Machine model: Raspberry Pi 4 Model B Rev 1.1

Le fichier /var/log/user.log m’interpelle un peu (le redémarrage a eu lieu dans la même seconde)

Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: checking bus 1, device 6: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1"
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: bus: 1, device: 6 was not an MTP device
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: checking bus 1, device 6: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1"
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: bus: 1, device: 6 was not an MTP device
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: checking bus 1, device 6: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1"
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: checking bus 1, device 8: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4.1"
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: bus: 1, device: 8 was not an MTP device
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: checking bus 1, device 10: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4.3"
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: bus: 1, device: 10 was not an MTP device
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: checking bus 1, device 11: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4.4"
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: bus: 1, device: 11 was not an MTP device
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: checking bus 1, device 9: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4.2"
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: bus: 1, device: 9 was not an MTP device
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: bus: 1, device: 6 was not an MTP device
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: checking bus 1, device 8: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4.1"
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: bus: 1, device: 8 was not an MTP device
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: checking bus 1, device 11: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4.4"
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: bus: 1, device: 11 was not an MTP device
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: checking bus 1, device 9: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4.2"
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: bus: 1, device: 9 was not an MTP device
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: checking bus 1, device 10: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4.3"
Nov 17 19:34:48 RPi4b-Jeedom mtp-probe: bus: 1, device: 10 was not an MTP device
Nov 17 19:34:49 RPi4b-Jeedom htpdate: htpdate version 1.2.0 started
Nov 17 19:34:49 RPi4b-Jeedom htpdate: www.pool.ntp.org host or service unavailable
Nov 17 19:34:50 RPi4b-Jeedom mtp-probe: checking bus 1, device 13: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.3"
Nov 17 19:34:50 RPi4b-Jeedom mtp-probe: bus: 1, device: 13 was not an MTP device
Nov 17 19:34:50 RPi4b-Jeedom mtp-probe: checking bus 1, device 13: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.3"
Nov 17 19:34:50 RPi4b-Jeedom mtp-probe: bus: 1, device: 13 was not an MTP device
Nov 17 19:34:51 RPi4b-Jeedom mtp-probe: checking bus 1, device 14: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.3"
Nov 17 19:34:51 RPi4b-Jeedom mtp-probe: bus: 1, device: 14 was not an MTP device
Nov 17 19:34:51 RPi4b-Jeedom mtp-probe: checking bus 1, device 14: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.3"
Nov 17 19:34:51 RPi4b-Jeedom mtp-probe: bus: 1, device: 14 was not an MTP device

Dans le fichier /var/log/syslog, je constate toujours un problème de temps : le système passe de 19h44 à 19h34. C’est tout de même suprenant alors qu’il est connecté au réseau en permance.

Nov 17 19:30:01 RPi4b-Jeedom CRON[5265]: (root) CMD (/usr/bin/php /var/www/html/core/php/watchdog.php >> /dev/null)
Nov 17 19:30:01 RPi4b-Jeedom CRON[5267]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:31:01 RPi4b-Jeedom CRON[7646]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:32:01 RPi4b-Jeedom CRON[9693]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:33:01 RPi4b-Jeedom CRON[11886]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:34:01 RPi4b-Jeedom CRON[14021]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:35:01 RPi4b-Jeedom CRON[16046]: (root) CMD (/usr/bin/php /var/www/html/core/php/watchdog.php >> /dev/null)
Nov 17 19:35:01 RPi4b-Jeedom CRON[16049]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:36:01 RPi4b-Jeedom CRON[18229]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:37:01 RPi4b-Jeedom CRON[20289]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:38:01 RPi4b-Jeedom CRON[22313]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:39:01 RPi4b-Jeedom CRON[24364]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Nov 17 19:39:02 RPi4b-Jeedom CRON[24365]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:39:02 RPi4b-Jeedom systemd[1]: Starting Clean php session files...
Nov 17 19:39:03 RPi4b-Jeedom systemd[1]: phpsessionclean.service: Succeeded.
Nov 17 19:39:03 RPi4b-Jeedom systemd[1]: Started Clean php session files.
Nov 17 19:40:01 RPi4b-Jeedom CRON[26427]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:40:01 RPi4b-Jeedom CRON[26428]: (root) CMD (/usr/bin/php /var/www/html/core/php/watchdog.php >> /dev/null)
Nov 17 19:41:01 RPi4b-Jeedom CRON[28590]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:42:01 RPi4b-Jeedom CRON[30467]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:43:01 RPi4b-Jeedom CRON[32271]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:44:01 RPi4b-Jeedom CRON[1715]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
Nov 17 19:34:48 RPi4b-Jeedom systemd-fsck[110]: e2fsck 1.44.5 (15-Dec-2018)
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000] Linux version 5.4.51-v8+ (dom@buildbot) (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9)) #1333 SMP PREEMPT Mon Aug 10 16:58:35 BST 2020
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000] Machine model: Raspberry Pi 4 Model B Rev 1.1

Dans le fichier /var/log/debug

Nov 15 01:46:41 RPi4b-Jeedom PackageKit: daemon start
Nov 15 01:51:46 RPi4b-Jeedom PackageKit: daemon quit
Nov 16 08:29:35 RPi4b-Jeedom PackageKit: daemon start
Nov 16 08:34:40 RPi4b-Jeedom PackageKit: daemon quit
Nov 17 13:10:19 RPi4b-Jeedom PackageKit: daemon start
Nov 17 13:15:24 RPi4b-Jeedom PackageKit: daemon quit
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000] On node 0 totalpages: 1025536
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000]   DMA zone: 4096 pages used for memmap
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000]   DMA zone: 0 pages reserved
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000]   DMA zone: 255488 pages, LIFO batch:63
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000]   DMA32 zone: 12032 pages used for memmap
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000]   DMA32 zone: 770048 pages, LIFO batch:63
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000] pcpu-alloc: s89240 r8192 d29544 u126976 alloc=31*4096
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    1.171023] dwc_otg: FIQ enabled
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    1.171032] dwc_otg: NAK holdoff enabled
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    1.171040] dwc_otg: FIQ split-transaction FSM enabled
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    1.171052] Module dwc_common_port init
Nov 17 19:34:48 RPi4b-Jeedom kernel: [    6.003375] brcmfmac: F1 signature read @0x18000000=0x15264345
Nov 17 19:34:48 RPi4b-Jeedom thd[373]: Found socket passed from systemd
Nov 17 20:57:32 RPi4b-Jeedom deCONZ-update2.sh[374]: found deCONZ port 8484

Toujours pareil, je dois juste débrancher puis rebrancher l’alim du Pi (effectué à 20h57) et tout repart correctement et côté Jeedom, tout est vert.

Il me reste à tester le hub USB2 et le Pi 4. Il ont chacun une alim dédiée de 3A et le tout est sur onduleur.

J’ai envie de défoncer ce Pi avec un pic ! Je comprends qu’on fini par acheter un NUC…

Domatizer · Novembre 27, 2020, 4:51

@naboleo Malgré tes modifications dans le fichier /var/www/html/core/php/watchdog.php

J’ai eu de nouveaux plantages. Plus d'acces à Jeedom le matin un jour sur deux depuis deux jours! - #86 par Domatizer

Je vais changer de hardware.

Domatizer · Décembre 5, 2020, 2:27

Bon, j’ai des plantages de plus en plus fréquents.

Je commence à tout revoir mon installation (nouveau RPi4 8G, des Rpi zero, un NUC) et préparer ma pioche aussi pour exploser ce Pi !

Les log deviennent plus bavards au moment du plantage, juste avant le redémarrage auto.
Le kern.log par exemple

Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.125729] xhci_hcd 0000:01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.125734] xhci_hcd 0000:01:00.0: Looking for event-dma 000000003a0afab0 trb-start 000000003a0afb00 trb-end 000000003a0afb10 seg-start 000000003a0af000 seg-end 000000003a0afff0
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.126729] xhci_hcd 0000:01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.126733] xhci_hcd 0000:01:00.0: Looking for event-dma 000000003a0afac0 trb-start 000000003a0afb00 trb-end 000000003a0afb10 seg-start 000000003a0af000 seg-end 000000003a0afff0
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.127730] xhci_hcd 0000:01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.127734] xhci_hcd 0000:01:00.0: Looking for event-dma 000000003a0afad0 trb-start 000000003a0afb00 trb-end 000000003a0afb10 seg-start 000000003a0af000 seg-end 000000003a0afff0
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.128731] xhci_hcd 0000:01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.128735] xhci_hcd 0000:01:00.0: Looking for event-dma 000000003a0afae0 trb-start 000000003a0afb00 trb-end 000000003a0afb10 seg-start 000000003a0af000 seg-end 000000003a0afff0
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.129730] xhci_hcd 0000:01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.129735] xhci_hcd 0000:01:00.0: Looking for event-dma 000000003a0afaf0 trb-start 000000003a0afb00 trb-end 000000003a0afb10 seg-start 000000003a0af000 seg-end 000000003a0afff0
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400140] Unable to handle kernel paging request at virtual address 0000000006084b01
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400165] Mem abort info:
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400172]   ESR = 0x96000046
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400181]   EC = 0x25: DABT (current EL), IL = 32 bits
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400189]   SET = 0, FnV = 0
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400196]   EA = 0, S1PTW = 0
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400202] Data abort info:
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400209]   ISV = 0, ISS = 0x00000046
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400216]   CM = 0, WnR = 1
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400225] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000f2a99000
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400234] [0000000006084b01] pgd=00000000d4c58003, pud=00000000d4c58003, pmd=0000000000000000
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400251] Internal error: Oops: 96000046 [#1] PREEMPT SMP
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400260] Modules linked in: aes_neon_blk crypto_simd cryptd bnep hci_uart btbcm bluetooth ecdh_generic ecc option usb_wwan fuse 8021q garp stp llc ftdi_sio usbserial cdc_acm brcmfmac brcmutil s$
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400357] CPU: 2 PID: 13545 Comm: python Tainted: G         C        5.4.72-v8+ #1356
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400365] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400374] pstate: 00000005 (nzcv daif -PAN -UAO)
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400391] pc : __memset+0x4c/0x188
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400400] lr : copy_process+0x270/0x1628
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400406] sp : ffffffc012473c80
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400411] x29: ffffffc012473c90 x28: 00000000003d0f00
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400419] x27: ffffff80dc95d940 x26: ffffff80b03a0d80
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400427] x25: ffffff80f6165940 x24: 0000000000000000
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400434] x23: 0000000000000000 x22: 0000000000000000
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400441] x21: ffffffc0100e3f80 x20: ffffffc012473e18
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400449] x19: ffffff80dc95d940 x18: 0000000000000000
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400456] x17: 0000000000000000 x16: 0000000000000000
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400463] x15: 0000000000000000 x14: 0000000000000000
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400470] x13: 0000000000000000 x12: 0000000000000000
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400477] x11: 0000000000000000 x10: 0000000000000000
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400484] x9 : 0000000000000000 x8 : 0000000006084b01
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400492] x7 : 0000000000000000 x6 : ffffffc010e96ec0
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400499] x5 : ffffffc010e96eb0 x4 : 000000000000000f
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400506] x3 : 00000000113ada02 x2 : 0000000000004000
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400513] x1 : 0000000000000000 x0 : 0000000006084b01
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400521] Call trace:
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400528]  __memset+0x4c/0x188
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400534]  _do_fork+0x88/0x3e0
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400541]  __arm64_sys_clone+0x78/0xa0
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400550]  el0_svc_common.constprop.0+0x7c/0x1a8
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400557]  el0_svc_compat_handler+0x30/0x60
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400564]  el0_svc_compat+0x8/0x10
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400574] Code: d65f03c0 cb0803e4 f2400c84 54000080 (a9001d07)
Dec  5 12:37:21 RPi4b-Jeedom kernel: [146223.400583] ---[ end trace e69c28756db9f937 ]---
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^$
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] Linux version 5.4.72-v8+ (dom@buildbot) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #1356 SMP PREEMPT Thu Oct 22 13:58:52 BST 2020
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] Machine model: Raspberry Pi 4 Model B Rev 1.1
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] efi: Getting EFI parameters from FDT:
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] efi: UEFI not found.
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] Reserved memory: created CMA memory pool at 0x000000001ec00000, size 256 MiB
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] On node 0 totalpages: 1025536
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000]   DMA zone: 4096 pages used for memmap
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000]   DMA zone: 0 pages reserved
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000]   DMA zone: 255488 pages, LIFO batch:63
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000]   DMA32 zone: 12032 pages used for memmap
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000]   DMA32 zone: 770048 pages, LIFO batch:63
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] percpu: Embedded 31 pages/cpu s89304 r8192 d29480 u126976
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] pcpu-alloc: s89304 r8192 d29480 u126976 alloc=31*4096
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] Detected PIPT I-cache on CPU0
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] CPU features: detected: EL2 vector hardening
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware
Dec  5 12:24:14 RPi4b-Jeedom kernel: [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 1009408

J’ai l’impression qu’il est mort ce Pi !

Toujours le problème de l’horloge, il redémarre avec un avant qu’il ne plante. 13min de dérive temporelle, c’est beaucoup en 40h de fonctionnement depuis le précédent redémarrage.

lone · Décembre 5, 2020, 2:37

Essaye le même support sur un autre pi, c’est peut être matériel…

Makaveli · Décembre 12, 2020, 5:35

Hello ! Je me joins à toi et je vais essayer de t’indiquer un ou deux trucs.

Le fonctionnement que tu indiques est plus ou moins normal : tous les 17 de chaque heure, fake-hwclock passe et si tu as un plantage entre deux passages, alors, tu vas repartir sur cette heure là. Que tu n’aies que des 17 c’est normal, et ça n’indique pas le moment précis ou ça plante. Donc tu sais pas et t’as rien sur l’origine éventuelle de la panne.

Maintenant pourquoi je suis là :o Je migre progressivement mes Pi3 vers des Pi4. La domotique est arrivée en dernier : migration sur un Pi4 4GB avec SSD (SATA MX500), une interface avec teleinf (usb2) et une clé aeotec sur un HUB USB2 (passif).

Reboot fréquent que je n’ai pas vu tout de suite car moi tout marche suite au reboot Mais, je n’ai rien vu dans les logs. Et en essayant de situer l’heure exacte je n’ai rien trouvé de probant. J’ai eu au départ des freezes nets, mais ce n’a pas duré.

J’ai pensé assez rapidement à un Pi défectueux. Il se trouve que j’ai des Pi4 2Gb à la maison, et bien ça plante pas ! Le système est bien stable dessus. J’ai bien sur du mettre en place des quirks pour le boitier externe.

J’ai installé une raspbian desktop sur le Pi4 4GB, en le testant dans tous les sens (stress test CPU, memtest…) et j’ai rien qui ressort. Il est hyper stable, et tient plusieurs jours sans plantage.

Il semblerait de plus qu’on soit quelques uns à rencontrer le problème. Et puis le fait que ça arrive sur un 4 GB mais pas un 2… Attention si tu passes sur un 8 !

Après mes investigations je pense que les prises USB jouent un rôle (car suite à mon test desktop, rien ne plante, mais il y a rien sur les prises USB !!!). Je ferai le test je pense avec un HUB USB2 alimenté pour voir si ça marche, et aussi avec une alimentation 3A USB C native.

En attendant, il n’y a qu’avait mon Pi sur Jeedom que ça plante. On est pas non plus à l’abri d’une erreur sur la distrib qui bugge sur le Pi4… Mais pourquoi 4GB ?

Ma deuxième piste c’est être sur un système 32bits avec 4GB. Est ce que ça pourrait poser problème ? A voir si ça passe avec la version 64bits de raspbian mais elle est encore en béta. Oublie pas que pour les 8GB tu dois normalement passer dessus !

Je te tiendrai au courant de mes investigations…

Domatizer · Décembre 12, 2020, 5:57

Merci @Makaveli, je me sens moins seul dans cette galère

Ok, maintenant que j’ai viré ce fake-hwclock, c’est n’importe quand les plantages.

Je n’ai aucune confiance dans la gestion des ports USB du RPi, j’avais lu quelque part que la norme USB n’était pas bien respectée.

Là, je viens de faire un essai en débranchant l’alim de 3A du hub USB. Tous les dongles USB sont donc alimentés par un seul des 4 ports USB du RPi4b où est branche le hub. Le tout est alimenté par une seule alim de 3A.

Ça tient depuis le 5 décembre (mon dernier post sur ce fil).
Je vais laisser comme cela pour les fêtes, j’espère que ça ne plantera pas.

Si ça ne plante pas pendant 3 mois (ouais, il faut viser long) alors il y a une merde dans l’alim du hub

J’ai toujours une autre idée en tête : re-alimenter le Hub et le Rpi, mais couper le fil d’alim +5V entre le RPi et le Hub pour éviter la connexion des alim 5V ensemble…

Normalement non, avec les 32 bits, on adresse bien les 4GB (2^32 =4G) mais en nombres non signés

Idem sur 1 sur 4 RPi

Un autre truc, j’ai la révision 1.1 du RPi4 sachant qu’il existe une révision 1.2

Makaveli · Décembre 12, 2020, 7:38

J’ai la 1.2 c’est pas mieux

Mais je comprends pas quelle différence il pourrait y avoir entre la version 2 qui marche impec ici et la 4 qui plante…

Domatizer · Décembre 14, 2020, 7:57

La version 3 du RPi plante aussi pour d’autres. Voir le lien plus haut d’un autre sujet similaire.

guitouuu · Mars 4, 2021, 2:22

Bonsoir,

J’ai un jeedom 64bit sur pi 4b 4go rev 1.2 avec ssd et hub alimenté pour mes dongle zigbee, zwave…
Mon système a été mis en place il y a un peu plus d’un mois et je viens d’avoir ce problème pour la 1ère fois, le 1er mars a 15:17:05. jeedom était inaccessible alors que le pi tournait et j’ai du couper l’alim pour qu’il fonctionne à nouveau.

J’ai globalement les mêmes logs que @Domatizer . Le pi a reboot seul mais il s’est arreté à « Mar 1 15:17:22 jeedom dhcpcd[603]: eth0: no IPv6 Routers available » et juste avant il a fait plein de « Soliciting pool server » et dans les logs je suis tombé sur un « Mar 1 15:17:16 jeedom ntpd[639]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized »

Vu le fil de discussion j’imagine que ce problème va revenir, ce qui m’embête fortement car si le système plante et n’est pas capable de reboot proprement seul sans intervention ca veut dire que la maison peut se retrouver dans un état inacceptable en cas d’absence…

Pensez vous qu’il peut s’agir d’un problème matériel? Du pi ? Mon installation étant récente elle n’est pas polluée niveau logiciel, et si ca venait de la distrib jeedom j’imagine que beaucoup d’autres auraient ce problème…

Avez vous trouvé une solution depuis ?

Domatizer · Mars 4, 2021, 9:00

Bien, j’en conclu que

32bit ou 64bit,
rev 1.1 ou rev 1.2,
SSD ou carte SD,
hub USB alimenté en externe ou non
installe propre de Jeedom ou pas

ça plante toujours pareil !

Par défaut, il y a le fake-hwclock dans le cron, le bug se passe à la minute 17 ! J’ai bidouillé tout un tas de truc sur la synchro de l’horloge et viré le fake-hwclock. Résultat, ça plante toujours pareil mais de façon aléatoire !

Oui et tu ne sais pas quand… Le système peut tenir quelques heures, quelques jours, quelques semaines mais il plante à un moment donné !

Exactement, cet hiver le système a planté la veille de mon retour de vacances, juste avant que je puisse remettre le chauffage… J’ai passé une bien mauvaise soirée à mon retour !

Parmi tous les problèmes rencontrés, c’est le pire bug car, comme toi

Oui, des ports USB du RPi4. Si j’enlève tous les dongles USB du RPi4, il ne plante plus l’enfoiré !

Oui, un vrai PC de bureau Lenovo Intel I3 + SSD en externe.

Sur un vrai PC, les normes USB sont respectées et pas de problème de ports USB. Aussi, je n’ai plus de déconnexions inopinées de certains dongles comme j’avais avant.

Autres essais, j’ai aussi racheté un RPi zero :

Première chose constatée, il reboot dès que je branche le hub USB ou un seul dongle (clé Z-Wave). Parfois, il se foutait en vrac suite au reboot. En revanche, une fois le hub USB branché, le branchement de la clé Z-Wave sur le hub ne faisait plus rebooter le Pi.

Ensuite, j’ai installé USB Redirector sur ce Pi zero et sur le NUC Lenovo afin de d’exporter tous les dongles USB (temporairement pour le test et pour pouvoir placer le contrôleur Z-Wave proche des modules lors des inclusions sans devoir déplacer la box domotique). Résultat, le Pi zero a fini par planter rapidement (sachant un simple mauvais contact du câble USB et le système saute, ce n’est pas très fiable). J’ai aussi effectué différents essais en mettant une partie des dongles sur le Pi zero et l’autre sur le NUC, là le PI zero ne plantait plus.

Malheureusement, je n’ai pas réussi à installer USB Redirector sur le RPi 4 pour faire le même genre d’essai. Sans dongle USB connecté physiquement sur le RPi 4, il ne planterait pas…

J’ai arrêté car je trouvais qu’USB Redirector en WiFi, c’était un peu limite dans l’utilisation, des lenteurs parfois dans les actions Z-Wave…

L’alternative serait d’utiliser (=racheter) un Odroid au lieu du Raspberry Pi.

Comme je trouve que mon installation Jeedom est déjà assez lourde car beaucoup d’équipements, de commandes et de scénarios, j’ai un peu peur de revenir sur une machine finalement pas assez puissante avec un Odroid.

Mais, au fond, ça m’ennuie d’utiliser la solution NUC pour de la domotique.

Conclusion, la domotique avec le RPi4, c’est possible mais il ne faut pas avoir besoin d’utiliser ses ports USB

Domatizer · Mai 28, 2021, 4:16

Voilà, ça me gave !!!

Le système a d’abord tenu 5 semaines. Puis 3 semaines car j’ai dû faire des mises à jour et redémarrer pour installer le BlueTooth. Ensuite, j’ai eu 3 plantages en 1 semaine ! Là, ça tient depuis 3 jours !

Ça fait presqu’un an que je galère avec ce souci. Je pense que je ne trouverai pas pourquoi ce RPi 4 déconne. Maintenant, je cherche une alternative fiable pour remplacer ce Pi…

naboleo · Mai 28, 2021, 4:18

Salut,

La suite logique, c’est le nuc …

Domatizer · Mai 28, 2021, 4:32

Ouais, je sais !
Je réfléchis aussi à une solution décentralisée pour avoir une domotique plus robuste : 1 RPi zero (ou autre chose que du Pi) par protocole avec du MQTT partout, quoi !

naboleo · Mai 28, 2021, 4:39

C’est pas dit que ce soit plus robuste …

Le pi zero c’est pas super puissant… et 1 port USB.
Même en multipliant les points de fonctionnement, en cas de coupure de courant, ça revient au même : rien ne fonctionne. Et multiplier les onduleurs pour chaque pi
Autant de mise à jour OS à faire que de pi …
Niveau WAF… un truc dans chaque pièce, pas sur que ça passe…
Quand il faut rebooter le pi électriquement, tu es bon pour de déplacer…

Nuc + Onduleur + Disque de backup … c’est à mon avis bien plus souple. Mais bon ça reste un avis perso

Domatizer · Mai 28, 2021, 5:14

1 pi zero avec 1 port USB pour 1 protocole, ça devrait aller. J’aime assez bien l’approche modulaire. Ainsi quand on bricole un nouveau protocole, on ne touche strictement à rien du reste

Non, ils seront tous au même endroit. Donc toujours un seul onduleur.

Non, quand ça marche, je ne fait plus de mise à jour, éventuellement tous les 2 ans et quand j’ai du temps devant moi. Si je prends l’exemple du RPi zero de ma chaudière pour l’ebus, il est autonome depuis des mois et je n’y touche plus. Malgre toutes les conversions ebus/usb/rpi0/ebusd/mqtt/wifi, c’est fiable !

Si le hardware ne plante pas, il n’y a pas besoin de redémarrer électriquement

Après la solution tout en un sur un NUC est aussi séduisante. Mais, je ne suis pas assez expert pour gérer des VM ou du docker. Je n’arrive pas encore à me décider.

naboleo · Mai 28, 2021, 5:17

Proxmox, c’est à la portée de tout le monde… Une fois que la VM est en place, c’est pareil qu’une machine physique (les fonctions de backup en plus)… Si tu veux t’amuser à faire 1 VM par protocol, tu peux aussi…

alexcrp · Mai 28, 2021, 5:34

J’ai suivi avec attention les échanges.

Je peux vous faire un retour d’expérience, j’ai débuté sur Jeedom avec un Rpi 4B 4Go rev. 1.2, avec Pi OS LITE Buster 32bits sur un disque dur mSata banché en USB3 et une alimentation de 3A: je n’ai eu aucun soucis, avec Jeedom v4.

Plus récemment il y a quelques mois (avec mes galères pour faire marcher une clef gsm Huawei ), je suis passé sur un Rpi 4B 8Go rev. 1.4, avec Pi OS Buster LITE 64bits, et cela a été totalement transparent, aucun problème et config aussi stable qu’avant !

J’ai bcp de Clefs, je les ai testées de la même manière dans les 2 cas:

Zwave aeotec Gen 5
Bluetooth SENA
RFXComXL
GSM Huawei e3372
= elles sont toutes sur un seul hub USB2 (pas 3) relié à un port USB2 du Pi. Le hub est alimenté par son alim dédiée.

Avec tout ce petit monde, ma config reste stable au quotidien, et avec le Pi 8Go j’ai même gagné en ressources… (moins chaud).

Domatizer · Juin 29, 2021, 10:58

Depuis mon dernier post ici, le Pi a encore replanté plusieurs fois.
Ce fil est maintenant ouvert depuis 1 an et c’est toujours pareil.
Donc, la domotique sur RPi4, c’est vraiment terminé cette fois !!!

Ça y est ! J’ai suivi tes conseils @naboleo et j’ai installé Proxmox sur le NUC. Je ne m’attendais pas à une installation aussi rapide. J’ai réinstallé proprement Jeedom dans une VM. Pour l’instant, je reste dans une config domotique tout-en-un, car il y a un côté pratique.

Merci pour l’astuce suivante

BOMARKO · Décembre 10, 2021, 9:24

Je n’ai plus de plantage depuis que j’ai inhibé le WIFI et le BLUETOOTH sur mon RPI4B.
Coïncidence ?
Pour cela j’ai modifié le fichier /boot/config.txt :
Chercher la ligne suivante « #Additional overlays and parameters are documented /boot/overlays/README »
et ajouter les lignes suivantes à la suite:
dtoverlay=disable-wifi
dtoverlay=disable-bt