Aller au contenu

Mon Syno (212+) Ne Passe Plus En Mode "sleep" Depuis L'upgrade


gspock

Messages recommandés

  • Réponses 56
  • Créé
  • Dernière réponse

Meilleurs contributeurs dans ce sujet

Bonjour,

J'ai également ce pb et je pensais que cela venais des constants flux engendrés par le protocole AFP. J'ai essayé de téléchargé le patch à l'adresse donnée sur ce fil mais une page s'affiche me disant que je n'ai pas le droit d'ouvrir la page. Faut il obligatoirement un logiciel FTP pour télécharger ce patch ?

Merci.

Lien vers le commentaire
Partager sur d’autres sites

Je viens d'essayer avec un logiciel de FTP il semblerait que l'accès au ftp ne fonctionne pas. QQun pourrait me confirmer cela ? Savez vous où l'on peut trouver ce patch ?

Merci.

Je n'ai pas eu besoin de logiciel FTP, j'ai utilisé le lien que tu trouveras ici : http://forum.synology.com/enu/viewtopic.php?f=83&t=56069&start=45

Lien vers le commentaire
Partager sur d’autres sites

Je viens d'essayer avec un logiciel de FTP il semblerait que l'accès au ftp ne fonctionne pas. QQun pourrait me confirmer cela ? Savez vous où l'on peut trouver ce patch ?

Merci.

Si ça peux t'aider, voici un lien dropbox avec la patch en question : http://db.tt/ds0mFly7

GS

Modifié par gspock
Lien vers le commentaire
Partager sur d’autres sites

Pour votre info j'ai lancé le patch sur mon DS212, ça marche ! Il se remet bien en veille. Problème résolu.

Bonjour,

Je reviens suite à l'application du patch de mise en veille. Effectivement cela fonctionne bien mais la sortie de veille est plutôt difficile. En effet les disques dur moulinent à fond pendant environ 5 minutes avec ces erreurs dans le log :

Sep 11 13:41:33 kernel: [17027.700000] ata1: wake up from deepsleep, reset link now

Sep 11 13:41:33 kernel: [17027.780000] ata1: device plugged sstatus 0x123

Sep 11 13:41:33 kernel: [17030.710000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen

Sep 11 13:41:33 kernel: [17030.720000] ata1: edma_err_cause=00000010 pp_flags=00000000, dev connect

Sep 11 13:41:33 kernel: [17030.720000] ata1: SError: { PHYRdyChg DevExch }

Sep 11 13:41:40 kernel: [17034.730000] ata2: wake up from deepsleep, reset link now

Sep 11 13:41:40 kernel: [17034.810000] ata2: device plugged sstatus 0x123

Sep 11 13:41:40 kernel: [17037.740000] ata2: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen

Sep 11 13:41:40 kernel: [17037.750000] ata2: edma_err_cause=00000010 pp_flags=00000000, dev connect

Sep 11 13:41:40 kernel: [17037.750000] ata2: SError: { PHYRdyChg DevExch }

Sep 11 13:41:46 kernel: [17043.750000] ata2: link is slow to respond, please be patient (ready=0)

Sep 11 13:41:51 kernel: [17047.770000] ata2: SRST failed (errno=-16)

Sep 11 13:41:51 kernel: [17047.770000] ata2: SRST fail, set srst fail flag

Sep 11 13:41:51 kernel: [17048.690000] ata2: link reset sucessfully clear error flags

Perso je comprends pas ces erreurs. Le bruit que fond les disques me donnent l'impression qu'ils vont bientôt rendre l'âme, Ce qui serait vraiment pas de bol puisque ils ont seulement 1 mois qu'ils ont été vérifiés avant la première installation de DSM 4.0. Du coup j'ai fait pour voir un S.M.A.R.T rapide ce jour et rien d'anomal. J'avais pas ce phenomène sous DSM 4.0. Après ces fameuses 5 minutes tout fonctionne normalement.

Ce que je vais faire : Dézinguer le système et faire une réinstallation vierge de la version DSM 4.1 et tester la mise en veille sans appliquer le patch pour voir dans un premier temps (Si c'est comme windows faire évoluer une version du système des fois c'est pas au point).

Lien vers le commentaire
Partager sur d’autres sites

hello,

j'ai remarqué un autre truc bizarre après avoir activé l'historique d'utilisation du moniteur de ressource (dans "paramètres avancés"). La cpu apparait comme étant sollicitée quasiment à 100% tout le long de la veille, avec la répartition suivante 40% pour l'utilisateur et 57% pour le système.

avez vous remarqué la même chose ?

Lien vers le commentaire
Partager sur d’autres sites

Bon, je crois que le terme technique pour ce problème est: ça déconne total.

Synology est au courant du problème, ils bossent dessus j'en suis sur. En attendant, j'ai pris l'option de prendre mon mal en patience et de vivre sans hibernation.

Quand on voit tous les trucs qu'il y a à régler avec la 4.1...

Par contre, je suis intéressé par le retour de Crawler suite à une installation à propre, est-ce que ça règle le problème ?

Lien vers le commentaire
Partager sur d’autres sites

Salut,

Est-ce que tu as essayé d'activer l'historique d'utilisation du moniteur de ressource (dans "paramètres avancés") ?Tu me diras si chez toi aussi, le moniteur de ressource t'affiche 100% de cpu enregistrés tout le long de la durée de veille du syno ? C'est plus un problème au niveau du moniteur de ressource qu'au niveau de la mise en veille car le syno ne chauffe pas alors que le ventilo est arrêté. J'ai déjà ouvert un incident chez Synology pour leur signaler ce petit bug.

Pour ma part depuis la mise en place du patch je n'ai plus de problème d'hibernation, pas d'erreurs dans les logs... j'espère que ça ne cache pas autre chose !

Lien vers le commentaire
Partager sur d’autres sites

Bonjour à tous,

Voici mon retour après une réinstallation de DSM4.1 sur mon DS 212 :

Dans un premier temps j'ai donc écrasé les partitions de mes deux disques dur avec windows et réinstallé DSM 4.1. Le résultat reste le même pas de mise en veille, même en ayant pris soin de mettre l'indexation en cours sur pause.

Reste à essayer avec la ligne de commande et ensuite le patch, surtout pour regarder si les disques moulinent encore comme précisé plus haut dans mon post.

Lien vers le commentaire
Partager sur d’autres sites

Salut,

Est-ce que tu as essayé d'activer l'historique d'utilisation du moniteur de ressource (dans "paramètres avancés") ?Tu me diras si chez toi aussi, le moniteur de ressource t'affiche 100% de cpu enregistrés tout le long de la durée de veille du syno ? C'est plus un problème au niveau du moniteur de ressource qu'au niveau de la mise en veille car le syno ne chauffe pas alors que le ventilo est arrêté. J'ai déjà ouvert un incident chez Synology pour leur signaler ce petit bug.

J'ai bien activé l'historique d'utilisation du moniteur de ressources, et comme toi pendant la veille je suis à 98% d'utilisation du processeur, avec 2 courtes baisses à 2% en l'espace de 20h d'hibernation.

Par contre je ne sais pas comment se comportait le moniteur de ressources en DSM 4.0 ni en DSM 4.1 avant utilisation du patch (avec la commande Telnet).

Lien vers le commentaire
Partager sur d’autres sites


×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.