Livrables ARM en attente : Raspberry PI 3 HS

Donc ce n’est pas tant la PoW qui prend tout le CPU qu’une boucle infinie sur la gestionnaire de preuve.

Tu es bien sûr de tourner sur 1.6.4 ? duniter --version te permettra de t’en assurer. Car ce bug n’est pas spécifique à un Raspberry PI ou ARM.

Oui, c’est bien la 1.6.4

Peux-tu partager les fichiers wotb.bin et duniter.db de ton dossier ~/.config/duniter/duniter_default/ ?

C’est un peux gros… je t’envoie un lien par MP–>Done

Est-ce que le problème se présente systématiquement ?

C’est-à-dire, est-ce que si tu :

  • fais un “Reset data”
  • stoppes Duniter
  • redémarres Duniter
  • resynchronise

Vois-tu toujours le même message “The proof-of-work generation was canceled: Document already under treatment” ?

Oui!.

C’est un “oui” vérifié ça, vraiment ?

Oui!
Quand ça plante, je reset tout et je recommence tout. C’est ma procédure. Si tu veux que je fasse une 3eme fois depuis hier (parce que chez moi ça prend plus d’une heure), dit le moi mais le résultat sera invariablement le même.

J’avais lancé une synchro sur mon Raspi avant de t’écrire le message, et tu m’as répondu avant qu’il ait fini. Je me suis donc permis de douter.

Mais si tu dis que tu as déjà eu 2 fois précisément ce message “The proof-of-work generation was canceled: Document already under treatment” dès la fin de synchro avec cette procédure, alors ça me va.

Je ne voudrais pas que tu me dises « Oui » pour m’amener sur une fausse piste, qui me ferait perdre un temps précieux :slight_smile:

Je continue à investiguer, alors.

1 Like

Pas de problème.
Si tu souhaite que je fasse des essais spécifiques, dit le moi.
Pour être parfaitement exacte, je refait un duniter wizard network juste après un duniter reset all (et non un duniter reset data).

OK. Ça ne devrait rien changer.

Bonne nouvelle : je reproduis sur mon Raspberry PI.

2 Likes

Depuis le correctif du CPU bloqué à 100% et la communication IPC rétablie, je n’ai pas réussi à reproduire le bug The proof-of-work generation was canceled: Document already under treatment.

Il y a certainement un lien, bien que je ne vois pas précisément lequel.

Je vais donc faire une version, j’attendrai davantage de retours avant de m’y pencher à nouveau.

1 Like

Je suis parfois un peu perdu. Je ne sais pas quel est le meilleur endroit pour toi pour qu’on te fasse des retours et qu’on t’aide au maximum. (Ou du moins, qu’on te complique pas la tâche.) :slight_smile:

Fausse joie, problème à nouveau reproduit dans d’autres conditions. Je vais bien finir par trouver l’origine …

Hello

Alternatiba étant passé, j’espère avoir à nouveau du temps pour aider à creuser tout ça sur ma Brique Internet. Attention par contre, Yunohost n’est pas encore compatible Stretch donc dans un premier temps je serai sur Jessie.

A suivre dans quelques semaines !

Squeeek tout fatigué de ses 4 jours de fous

3 Likes

Tant que c’est dans la catégorie Dev, c’est parfait :slight_smile:

D’après ce que j’ai pu vérifier, tu peux contourner le problème en désactivant BMA :

duniter config --nobma

Puis tu redémarres ton nœud avec duniter webrestart. Ne change pas la configuration réseau dans la WebUI, car ce processus force le déclenchement du bug.

Pour info, j’ai un nœud qui tourne depuis ce matin, d’abord sur ğ1-test et maintenant sur ğ1, et le cpu est bien plafonné. J’ai réussi à calculer un bloc sur chaque chaîne.

3 Likes

C’est bon, le problème est résolu en version 1.6.6.

1 Like

Merci,
Je suis en train d’installer la version 1.6.6 et de synchroniser le noeud :slight_smile: