Toutes les 2^22 secondes soit en gros 1 mois 20 jours, le serveur, prend
89,06s d'avance (et est ejecté du pool donc). Les bugs se
sont produit à ces dates (et peut être avant):
12/08/2014 13:44:02
30/09/2014 02:56:06 17/11/2014 15:02:38 05/01/2015 04:14:12
22/02/2015 17:21:55
12/04/2015 07:30:46
30/05/2015 20:40:21
Je pense plutôt à un souci matériel,
Toutes les 2^22 secondes soit en gros 1 mois 20 jours, le serveur, prend
89,06s d'avance (et est ejecté du pool donc). Les bugs se
sont produit à ces dates (et peut être avant):
12/08/2014 13:44:02
30/09/2014 02:56:06 17/11/2014 15:02:38 05/01/2015 04:14:12
22/02/2015 17:21:55
12/04/2015 07:30:46
30/05/2015 20:40:21
Je pense plutôt à un souci matériel,
Toutes les 2^22 secondes soit en gros 1 mois 20 jours, le serveur, prend
89,06s d'avance (et est ejecté du pool donc). Les bugs se
sont produit à ces dates (et peut être avant):
12/08/2014 13:44:02
30/09/2014 02:56:06 17/11/2014 15:02:38 05/01/2015 04:14:12
22/02/2015 17:21:55
12/04/2015 07:30:46
30/05/2015 20:40:21
Je pense plutôt à un souci matériel,
[precisions]
> Toutes les 2^22 secondes soit en gros 1 mois 20 jours, le serveur,
> prend 89,06s d'avance (et est ejecté du pool donc). Les bugs se
> sont produit à ces dates (et peut être avant):
> 12/08/2014 13:44:02
> 30/09/2014 02:56:06 17/11/2014 15:02:38 05/01/2015 04:14:12
> 22/02/2015 17:21:55
> 12/04/2015 07:30:46
> 30/05/2015 20:40:21
et bien évidement aujourd'hui: 18/07/2015 09:48:24
[...]
>
> Je pense plutôt à un souci matériel,
Cela d'autant plus qu'en vérifiant le .bash_history de root, je sais
que le serveur ntp a été démarré pendant la période août 2014 et
aujourd'hui ce qui signifie que la période de 2^22 secondes ne vient
pas du serveur NTP mais du noyau et de la machine.
Cette période de 2^22 et le délai de 86,06s disent ils quelque chose à
quelqu'un?
François Boisson
[precisions]
> Toutes les 2^22 secondes soit en gros 1 mois 20 jours, le serveur,
> prend 89,06s d'avance (et est ejecté du pool donc). Les bugs se
> sont produit à ces dates (et peut être avant):
> 12/08/2014 13:44:02
> 30/09/2014 02:56:06 17/11/2014 15:02:38 05/01/2015 04:14:12
> 22/02/2015 17:21:55
> 12/04/2015 07:30:46
> 30/05/2015 20:40:21
et bien évidement aujourd'hui: 18/07/2015 09:48:24
[...]
>
> Je pense plutôt à un souci matériel,
Cela d'autant plus qu'en vérifiant le .bash_history de root, je sais
que le serveur ntp a été démarré pendant la période août 2014 et
aujourd'hui ce qui signifie que la période de 2^22 secondes ne vient
pas du serveur NTP mais du noyau et de la machine.
Cette période de 2^22 et le délai de 86,06s disent ils quelque chose à
quelqu'un?
François Boisson
[precisions]
> Toutes les 2^22 secondes soit en gros 1 mois 20 jours, le serveur,
> prend 89,06s d'avance (et est ejecté du pool donc). Les bugs se
> sont produit à ces dates (et peut être avant):
> 12/08/2014 13:44:02
> 30/09/2014 02:56:06 17/11/2014 15:02:38 05/01/2015 04:14:12
> 22/02/2015 17:21:55
> 12/04/2015 07:30:46
> 30/05/2015 20:40:21
et bien évidement aujourd'hui: 18/07/2015 09:48:24
[...]
>
> Je pense plutôt à un souci matériel,
Cela d'autant plus qu'en vérifiant le .bash_history de root, je sais
que le serveur ntp a été démarré pendant la période août 2014 et
aujourd'hui ce qui signifie que la période de 2^22 secondes ne vient
pas du serveur NTP mais du noyau et de la machine.
Cette période de 2^22 et le délai de 86,06s disent ils quelque chose à
quelqu'un?
François Boisson
bonjour,
serait il possible de voir du côté de adjtimex ?
bonjour,
serait il possible de voir du côté de adjtimex ?
bonjour,
serait il possible de voir du côté de adjtimex ?
Cette période de 2^22 et le délai de 86,06s disent ils quelque chose à
quelqu'un?
Cette période de 2^22 et le délai de 86,06s disent ils quelque chose à
quelqu'un?
Cette période de 2^22 et le délai de 86,06s disent ils quelque chose à
quelqu'un?
[precisions]
> Toutes les 2^22 secondes soit en gros 1 mois 20 jours, le serveur, prend
> 89,06s d'avance (et est ejecté du pool donc). Les bugs se
> sont produit à ces dates (et peut être avant):
> 12/08/2014 13:44:02
> 30/09/2014 02:56:06 17/11/2014 15:02:38 05/01/2015 04:14:12
> 22/02/2015 17:21:55
> 12/04/2015 07:30:46
> 30/05/2015 20:40:21
et bien évidement aujourd'hui: 18/07/2015 09:48:24
[...]
>
> Je pense plutôt à un souci matériel,
Cela d'autant plus qu'en vérifiant le .bash_history de root, je sais que le
serveur ntp a été démarré pendant la période août 2014 et aujourd'hui ce qui
signifie que la période de 2^22 secondes ne vient pas du serveur NTP mais du
noyau et de la machine.
Cette période de 2^22 et le délai de 86,06s disent ils quelque chose à
quelqu'un?
[precisions]
> Toutes les 2^22 secondes soit en gros 1 mois 20 jours, le serveur, prend
> 89,06s d'avance (et est ejecté du pool donc). Les bugs se
> sont produit à ces dates (et peut être avant):
> 12/08/2014 13:44:02
> 30/09/2014 02:56:06 17/11/2014 15:02:38 05/01/2015 04:14:12
> 22/02/2015 17:21:55
> 12/04/2015 07:30:46
> 30/05/2015 20:40:21
et bien évidement aujourd'hui: 18/07/2015 09:48:24
[...]
>
> Je pense plutôt à un souci matériel,
Cela d'autant plus qu'en vérifiant le .bash_history de root, je sais que le
serveur ntp a été démarré pendant la période août 2014 et aujourd'hui ce qui
signifie que la période de 2^22 secondes ne vient pas du serveur NTP mais du
noyau et de la machine.
Cette période de 2^22 et le délai de 86,06s disent ils quelque chose à
quelqu'un?
[precisions]
> Toutes les 2^22 secondes soit en gros 1 mois 20 jours, le serveur, prend
> 89,06s d'avance (et est ejecté du pool donc). Les bugs se
> sont produit à ces dates (et peut être avant):
> 12/08/2014 13:44:02
> 30/09/2014 02:56:06 17/11/2014 15:02:38 05/01/2015 04:14:12
> 22/02/2015 17:21:55
> 12/04/2015 07:30:46
> 30/05/2015 20:40:21
et bien évidement aujourd'hui: 18/07/2015 09:48:24
[...]
>
> Je pense plutôt à un souci matériel,
Cela d'autant plus qu'en vérifiant le .bash_history de root, je sais que le
serveur ntp a été démarré pendant la période août 2014 et aujourd'hui ce qui
signifie que la période de 2^22 secondes ne vient pas du serveur NTP mais du
noyau et de la machine.
Cette période de 2^22 et le délai de 86,06s disent ils quelque chose à
quelqu'un?
On 2015-07-18 14:28:46 +0200, François Boisson wrote:
Essaie de faire une recherche sur Google avec ces valeurs sous
diverses écritures. Mais j'ai l'impression que tu est le seul à avoir
ce problème, sinon il aurait été détecté, ce qui tendrait à indiquer
un problème matériel. Moi, c'était quand j'avais un Atari et un Mac
côte à côte il y a 25 ans environ: quand j'allumais mon Mac, l'Atari
passait subitement au 14 janvier 2028.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">https://lists.debian.org/
On 2015-07-18 14:28:46 +0200, François Boisson wrote:
Essaie de faire une recherche sur Google avec ces valeurs sous
diverses écritures. Mais j'ai l'impression que tu est le seul à avoir
ce problème, sinon il aurait été détecté, ce qui tendrait à indiquer
un problème matériel. Moi, c'était quand j'avais un Atari et un Mac
côte à côte il y a 25 ans environ: quand j'allumais mon Mac, l'Atari
passait subitement au 14 janvier 2028.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20150719155421.GC23007@zira.vinc17.org
On 2015-07-18 14:28:46 +0200, François Boisson wrote:
Essaie de faire une recherche sur Google avec ces valeurs sous
diverses écritures. Mais j'ai l'impression que tu est le seul à avoir
ce problème, sinon il aurait été détecté, ce qui tendrait à indiquer
un problème matériel. Moi, c'était quand j'avais un Atari et un Mac
côte à côte il y a 25 ans environ: quand j'allumais mon Mac, l'Atari
passait subitement au 14 janvier 2028.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">https://lists.debian.org/
On Sat, Jul 18, 2015 at 02:28:46PM +0200, François Boisson wrote:
> Cette période de 2^22 et le délai de 86,06s disent ils quelque chose à
> quelqu'un?
Pas spécifiquement, mais la description me rappelle un très
vieux bug que j'avais eu, où l'on ne masquait pas les
interruptions dans le traitement de l'interruption timer, et
du coup "de temps en temps", on revenait une 60e de secondes
en arrières, ce qui correspondait à 2^32 interruptions du
timer (ou 2^32 jiffies, je sais plus), dûe à un compteur qui
du coup ne gérait plus une retenue correctement (désolé de
l'imprécision, c'était il y a 15 ans...).
Du coup, peut-être tu as un compteur de 22 bits qui déborde
mal quelque part et les 86s correspondent à 2^x d'une
certaine fréquence?
On Sat, Jul 18, 2015 at 02:28:46PM +0200, François Boisson wrote:
> Cette période de 2^22 et le délai de 86,06s disent ils quelque chose à
> quelqu'un?
Pas spécifiquement, mais la description me rappelle un très
vieux bug que j'avais eu, où l'on ne masquait pas les
interruptions dans le traitement de l'interruption timer, et
du coup "de temps en temps", on revenait une 60e de secondes
en arrières, ce qui correspondait à 2^32 interruptions du
timer (ou 2^32 jiffies, je sais plus), dûe à un compteur qui
du coup ne gérait plus une retenue correctement (désolé de
l'imprécision, c'était il y a 15 ans...).
Du coup, peut-être tu as un compteur de 22 bits qui déborde
mal quelque part et les 86s correspondent à 2^x d'une
certaine fréquence?
On Sat, Jul 18, 2015 at 02:28:46PM +0200, François Boisson wrote:
> Cette période de 2^22 et le délai de 86,06s disent ils quelque chose à
> quelqu'un?
Pas spécifiquement, mais la description me rappelle un très
vieux bug que j'avais eu, où l'on ne masquait pas les
interruptions dans le traitement de l'interruption timer, et
du coup "de temps en temps", on revenait une 60e de secondes
en arrières, ce qui correspondait à 2^32 interruptions du
timer (ou 2^32 jiffies, je sais plus), dûe à un compteur qui
du coup ne gérait plus une retenue correctement (désolé de
l'imprécision, c'était il y a 15 ans...).
Du coup, peut-être tu as un compteur de 22 bits qui déborde
mal quelque part et les 86s correspondent à 2^x d'une
certaine fréquence?
* Je vais regarder si il y a une dérive de l'horloge RTC, je me demande si
ces 89,06s ne viendrait pas de là (mais théoriquement l'horloge RTC est mise
à jour toutes les 11 minutes)
* Je vais regarder si il y a une dérive de l'horloge RTC, je me demande si
ces 89,06s ne viendrait pas de là (mais théoriquement l'horloge RTC est mise
à jour toutes les 11 minutes)
* Je vais regarder si il y a une dérive de l'horloge RTC, je me demande si
ces 89,06s ne viendrait pas de là (mais théoriquement l'horloge RTC est mise
à jour toutes les 11 minutes)
Il y a un autre bug: c'était 89,06s dans ton premier message, et c'est
maintenant 86,06s!
Pour le 2^22, je ne vois pas, à part le fait que 10^22 est la plus
grande puissance de 10 tenant exactement dans un double. Mais ça
m'étonnerait qu'il y ait un lien. Ou alors un compteur sur 32 bits
incrémenté toutes les 1/1024 secondes?
Il faudrait logger le contenu de l'horloge matérielle (RTC) et de
l'horloge système juste un peu avant que le bug se produise et un
peu après.
Il y a un autre bug: c'était 89,06s dans ton premier message, et c'est
maintenant 86,06s!
Pour le 2^22, je ne vois pas, à part le fait que 10^22 est la plus
grande puissance de 10 tenant exactement dans un double. Mais ça
m'étonnerait qu'il y ait un lien. Ou alors un compteur sur 32 bits
incrémenté toutes les 1/1024 secondes?
Il faudrait logger le contenu de l'horloge matérielle (RTC) et de
l'horloge système juste un peu avant que le bug se produise et un
peu après.
Il y a un autre bug: c'était 89,06s dans ton premier message, et c'est
maintenant 86,06s!
Pour le 2^22, je ne vois pas, à part le fait que 10^22 est la plus
grande puissance de 10 tenant exactement dans un double. Mais ça
m'étonnerait qu'il y ait un lien. Ou alors un compteur sur 32 bits
incrémenté toutes les 1/1024 secondes?
Il faudrait logger le contenu de l'horloge matérielle (RTC) et de
l'horloge système juste un peu avant que le bug se produise et un
peu après.
L'heure matérielle est censée se mettre à jour toutes les 11 minutes. En fait
tout ce passe comme si la machine s'était gelée pendant ces 89,06s. On
pourrait peut être imaginer que pour une raison ou une autre, aucune
interruption n'ait été traitée pendant ce laps de temps. Maids ça me parait
tiré par les cheveux. La machine est un FitPC cadencé à 499.955MHz
L'heure matérielle est censée se mettre à jour toutes les 11 minutes. En fait
tout ce passe comme si la machine s'était gelée pendant ces 89,06s. On
pourrait peut être imaginer que pour une raison ou une autre, aucune
interruption n'ait été traitée pendant ce laps de temps. Maids ça me parait
tiré par les cheveux. La machine est un FitPC cadencé à 499.955MHz
L'heure matérielle est censée se mettre à jour toutes les 11 minutes. En fait
tout ce passe comme si la machine s'était gelée pendant ces 89,06s. On
pourrait peut être imaginer que pour une raison ou une autre, aucune
interruption n'ait été traitée pendant ce laps de temps. Maids ça me parait
tiré par les cheveux. La machine est un FitPC cadencé à 499.955MHz