vous avez tenter sa car depuis j’ai plus de problème perso
1 « J'aime »
Oui, j’avais coché le truc, mais plantage tout de même, puis entre la distribution linux et Jeedom, qui prend vraiment le contrôle du « temps » parmi tous ces machins NTP ?
Petit coup de gueule : on est en 2020, le RPi est connu pour ne pas avoir son horloge RTC, le RPi a une distribution linux dédiée et on est encore emm.rdé par des trucs basiques.
Suite à mes dernières modifications, je n’ai pas en de plantage depuis…
Le deux mon capitaine !
- Watchdog ne se pose pas d’autre question qu’une date hors de la plage 2019 et 2040…
- La class Jeedom se base sur la config par contre
Personnellement je ne comprends pas l’intérêt que watchdog a d’arrêter le service, même s’il ne fonctionne pas… ça n’empêche pas de lancer la commande ntp toute seule. Surtout que le service est relancé ensuit
Ben j’ai viré le service NTP ! 
Amélioration côté Jeedom : Pour éviter que la database de Jeedom plante lorsque la resynchro remonte dans le temps, il faudrait que Jeedom se mette en pause et attende les quelques minutes tant que la database ne soit plus dans le passé puis reparte proprement une fois dans le présent.
Violent comme solution… Personnellement je ne penses pas que ce soit à Jeedom de gérer le ntp… Rien n’empêche de faire tourner la config avec un décalage en plus ou en moins par rapport à la réalité… Même plusieurs heures … tant que ça reste comme ça pas de souci globalement
ça risque de poser souci pour quelques fonctions (otp par exemple) mais rien d’obligatoire…et pas forcement le cas le plus présent
C’est pas aussi simple, si le décalage est de quelques secondes pourquoi pas, mais si on arrive dans des cas comme dans ce sujet de plusieurs heures… C’est juste pas possible…
Oui, mais avec le service systemd-timesyncd, cela me permet ceci
System clock synchronized: yes
NTP service: active
Le service NTP n’était pas actif par défaut
Tout à fait, c’est au système Linux d’avoir la bonne heure. J’ai re-décoché la gestion NTP dans Jeedom.
Le décalage est de quelques minutes et non pas plusieurs heures. En cas de de plantage, une attente de 3 minutes supplémentaires après le redémarrage pour avoir un Jeedom fonctionnel est acceptable. C’est toujours mieux que d’avoir un Jeedom qui reste en rade indéfiniment jusqu’au prochain reboot manuel en coupant l’alimentation.
Bonjour,
Le soucis que tu rencontres n’a rien a voir avec jeedom mais avec mariadb/mysql (jeedom s’appui dessus) et l’OS. Ce n’est pas a jeedom de gerer ce genre de soucis il n’en ai pas capable et n’en sera jamais capable.
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
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…
1 « J'aime »
@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.
1 « J'aime »
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.
Essaye le même support sur un autre pi, c’est peut être matériel…
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…
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
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…
La version 3 du RPi plante aussi pour d’autres. Voir le lien plus haut d’un autre sujet similaire.
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 ?
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 
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…
Salut,
La suite logique, c’est le nuc …