Essaye sans le wifi, la double connexion entraîne des problèmes
Au prochain plantage, je le mettrai en Wi-Fi plutôt que de le désactiver. Mais, je ne vois pas trop le rapport.
Ntp se sert du réseau et là tu as 2 adresses ip, je me dis que ça peut avoir un rapport.
J’ai déjà lu sur ce forum qu’il fallait éviter le filaire simultanément avec le wifi.
J’ai déconnecté les miens (tu as juste à commenter quelques lignes dans le wpa-supplicant puis reboot).
1 « J'aime »
Bonjour,
Ce matin pour moi tout est OK, mais en général le plantage c’est tout les deux jours ! ! !
Je suis ce post avec intérêt.
Salutations
Jean-Paul
1 « J'aime »
Moi, ça recommence. J’avais une session SSH ouverte
Message from syslogd@RPi4b-Jeedom at Nov 27 17:02:17 ...
kernel:[281868.159155] Internal error: Oops: 96000046 [#1] PREEMPT SMP
Message from syslogd@RPi4b-Jeedom at Nov 27 17:02:17 ...
kernel:[281868.159484] Code: d65f03c0 cb0803e4 f2400c84 54000080 (a9001d07)
Là, je n’en peux plus, j’ai juste envie de défoncer ce RPi4 à coup de pioche ! 
1 « J'aime »
Fais:
tail /var/log/messagesTu peux aussi regarder ton dmesg.
ps: pitié pour le pi 
Pétard c’est fou ça 
Finalement je n’ai eu ce soucis que le 23 Novembre et depuis tout est parfait.
Tant mieux car c’est ingerable ce truc.
À voir ton log, c’est fou le coup du 17 récurent quand-même 
Malheureusement, j’ai déjà regardé tous les fichiers dans /var/log/, je ne trouve pas la cause qui fait rebooter le RPi.
On voit un reboot, mais le pi n’arrive pas à démarrer correctement : plus de SSH, Jeedom reste en vrac !
1 « J'aime »
pour le 17 recurrent, c’est le RPI qui loggue sa date toute les heures à 17 minute.
Lorsque le RPI reboote, vu qu’il n’a pas d’horloge, il repart de la date inscrite dans le fichier /etc/fake-hwclock.data plutôt que 1er janvier 1970
Vu que j’ai un SSD et pas une SDcard, j’ai mis « * * * * * /sbin/fake-hwclock save » dans le crontab de root pour avoir une mise à jour toute les minutes de mon fichier /etc/fake-hwclock.data
J’aime pas les logs qui reviennent trop dans le passé 
1 « J'aime »
Ouais, quand le RPi n’est pas connecté au réseau, je comprends.
J’ai activé l’option pour qu’il démarre le système après la connexion au réseau.
SSD ou pas, ça plante exactement de la même façon.
Jeedom n’aime pas aussi !
« J’ai activé l’option pour qu’il démarre le système après la connexion au réseau. »
Je vais pas comment l’OS ne peut démarrer que quand l’OS a du réseau.
Ma remarque sur la SDcard est pour limiter un peu les écritures sur la SD card (60x moins)
L’OS démarre de toute façon, mais doit éventuellement arrêter des étapes d’init s’il n’a pas le reseau.
Durant ce temps, il a 2 dates possibles 1/1/1970 (valeur timestamp 0) ou celle du fichier susmentionné lorsqu’il arrive à l’étape de récuperer la date dans le fichier. Après lorsque le reseau sera UP, il pourra se synchroniser avec le NTP et corriger sa date. Là ou dmesg est fort, c’est que la date n’est pas loggué, mais le temps en microsecondes depuis le demarrage (compteur OS). Du coup, si on change la date, l’information de date de démarrage est correcte rétroactivement.
Un essai? faire un simple reboot n’importe quand (mais pas à la date présente dans /etc/fake-hwclock.data). Regarder la date dans les logs systems qui logguent la date…
Un deuxieme: last | grep reboot
pi@raspberrypi:~ $ last | grep reboot
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 still running
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 - 08:41 (18634+07:41)
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 - 08:41 (18634+07:41)
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 - 09:53 (18628+08:53)
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 - 09:53 (18628+08:53)
1 « J'aime »
=> C’est une nouvelle option présente dans raspi-config
Merci au passage pour l’information du x:17 minutes !
Voilà, c’est ça. Mais bon, ça plante quand même au final !!!
Bonjour @Fabrice & @Domatizer,
Avoir le réseau n’est pas une certitude que NTP mettra à jour l’heure immédiatement…
J’ai un soucis de SSD, mon raspi pert le disque SSD fréquemment, sans que je sache pourquoi → plantage OS, plus de jeedom, WAF–
J’ai donc un « dmesg -T » qui se lance toutes les minutes et s’écrit sur un second disque (pas le / vous l’avez compris) et me fait un diff et ne stocke que le diff.
Ce que je vois, c’est que l’OS boote avec l’heure du fichier, fait tout ce qu’il a à faire, et l’heure se met à jour 2 minutes après.
Si en plus, comme chez moi, lorsque l’OS reboote pour une raison indeterminée il y a un chkdsk qui se fait, l’analyse du disque augmentera d’autant la différence de temps.
reboot hier soir pour l’expliquation
1,436c1,436
< [jeu. janv. 14 21:06:17 2021] Booting Linux on physical CPU 0x0
< [jeu. janv. 14 21:06:17 2021] Linux version 5.4.83-v7l+ (dom@buildbot) (gcc version 8.4.0 (Ubuntu/Linaro 8.4.0-3ubuntu1)) #1379 SMP Mon Dec 14 13:11:54 GMT 2020
< [jeu. janv. 14 21:06:17 2021] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
[...]
< [jeu. janv. 14 21:07:14 2021] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
< [jeu. janv. 14 21:07:30 2021] v3d fec00000.v3d: MMU error from client L2T (0) at 0x13c1000, pte invalid
---
> [jeu. janv. 14 21:08:11 2021] Booting Linux on physical CPU 0x0
> [jeu. janv. 14 21:08:11 2021] Linux version 5.4.83-v7l+ (dom@buildbot) (gcc version 8.4.0 (Ubuntu/Linaro 8.4.0-3ubuntu1)) #1379 SMP Mon Dec 14 13:11:54 GMT 2020
> [jeu. janv. 14 21:08:11 2021] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
[...]
> [jeu. janv. 14 21:09:08 2021] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
> [jeu. janv. 14 21:09:24 2021] v3d fec00000.v3d: MMU error from client L2T (0) at 0x13c1000, pte invalid
Bonjour,
Alors, rapidement, j’ai eu ce cas 2 fois la semaine passée.
Je venait de passe mon Raspberry Pi OS en 64 bits sur un Raspberry Pi3B+
3 gros plantages plus tard (deux fois sans plus rien (disque certainement déconnecté) et la fois d’après, perte du réseau (Jeedom complètement fonctionnel… mais seul (donc RFXCom, Z-Wave était ok mais seul au monde).
J’ai régulièrement effectué les updates (firmware, kernel…) : mais cela n’ai rien changé. En 15 jours, je n’ai jamais dépassé les 4 jours de uptime, puis 2 puis 1…
- Je suis donc retourné en 32 bits et maintenant j’attends pour m’assurer que c’était bien cela la piste (avant le Raspberry Pi3B+ n’avait jamais eu ce plantage)
dmesg m’affichait régulièrement des Warning OTG…
Piste ou pas ? J’ai deux Pi ISO fonctionnel (sauf que le 2eme n’a pas les contrôleurs Z-wave et RFXCom) et le Pi de test à eu lui aussi 1 plantage identique (plus de réseau).
Le forum de la fondation Raspberry regorge de problème identique au miens pour ceux qui sont avec la version bêta de l’OS 64 bits (LAN / USB).
Bonjour,
J’ai moi aussi eu 2-3 plantages depuis mon passage en 64bits il y a 1 ou 2 mois.
Je suis en 4.1.17.
Parmi ces plantages, celui pdt les vacances a été étrange car comme @Fabrice, plus de réseau mais jeedom fonctionnais toujours (zwave et chauffage presque ok en rentrant ouf) et caméra ok donc que pb réseau sur le pi.
Si cela peut aider…
Bonjour,
Moi, j’ai fini par laisser tomber, un autre membre réalise un test en ce moment, il installe directement les Debian arm 64 bits (donc pas de Raspberry Pi OS).
A voir dans le temps.
Je sais pas si c’est le problème du sujet, mais au moins je ne suis pas seul à avoir ce problème (quelque part, cela me rassure)
Question alors pour @Emlivyo :
dmesg | grep -i otg
donne quoi ?
=> Moi, j’ai les 4 ports USB d’utilisé (SSD, BT, RFXCom, Z-Wave)
C’est bien ça ! Les chose devraient bouger…
Je suis resté en 32bits, le souci est toujours présent.
Ça me rassure aussi et je pense qu’on est nombreux à avoir ce problème toujours « inexpliqué ».
Il y a 2 choses :
- le reboot est aléatoire (fragilité hardware du RPi)
- Jeedom repart mal (surtout s’il y a une remontée dans le temps) alors que le reboot semble faire toutes les choses habituelles
Pour info, la commande dmesg me retourne de plus en plus de lignes (des centaines) comme ceci
[1328455.906665] xhci_hcd 0000:01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[1328455.906669] xhci_hcd 0000:01:00.0: Looking for event-dma 000000003a0b0250 trb-start 000000003a0b0290 trb-end 000000003a0b02a0 seg-start 000000003a0b0000 seg-end 000000003a0b0ff0
[1328455.907665] xhci_hcd 0000:01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[1328455.907669] xhci_hcd 0000:01:00.0: Looking for event-dma 000000003a0b0260 trb-start 000000003a0b0290 trb-end 000000003a0b02a0 seg-start 000000003a0b0000 seg-end 000000003a0b0ff0
[1328455.908670] xhci_hcd 0000:01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[1328455.908678] xhci_hcd 0000:01:00.0: Looking for event-dma 000000003a0b0270 trb-start 000000003a0b0290 trb-end 000000003a0b02a0 seg-start 000000003a0b0000 seg-end 000000003a0b0ff0
[1328455.909664] xhci_hcd 0000:01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[1328455.909669] xhci_hcd 0000:01:00.0: Looking for event-dma 000000003a0b0280 trb-start 000000003a0b0290 trb-end 000000003a0b02a0 seg-start 000000003a0b0000 seg-end 000000003a0b0ff0
Bref, ça pue !
Fabrice, j’obtiens ca:
