Scemd

[Johnito]

Salut,

Je m'occupe de quelques NAS, et un DS212 me donne du fil à retordre. Au fil des heures, le process SCEMD sature ses 512Mo de RAM jusqu’à finalement rendre le NAS incapable de répondre. Il ne reste alors plus qu'a rebooter la machine au bouton. Voilà quelques captures illustrant la prise de poids du processus au fil des heures et un extrait de /var/log/messages :

9h08 - 2.6Mo et 21% de la RAM totale du NAS occupée

11h20 - 53Mo et 44% de la RAM totale du NAS occupée

14h40 - 118Mo et 68% de la RAM totale du NAS occupée

Je ne vais pas au délà, parce-qu’a partir de 75/80% de RAM occupée DSM devient très dur à utiliser. J'ai beau redémarrer et arrêter un maximum de services, rien à faire toujours le même problème. Voilà un extrait de log qui semble montrer un problème, que je suis ma foi incapable de comprendre:

Dec 17 13:37:50 kernel: [16796.480000] ata1: wake up from deepsleep, reset link now
Dec 17 13:37:50 kernel: [16796.560000] ata1: device plugged sstatus 0x123
Dec 17 13:37:50 kernel: [16799.490000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Dec 17 13:37:50 kernel: [16799.500000] ata1: edma_err_cause=00000010 pp_flags=00000000, dev connect
Dec 17 13:37:50 kernel: [16799.500000] ata1: SError: { PHYRdyChg DevExch }

Dec 17 13:37:57 kernel: [16803.510000] ata2: wake up from deepsleep, reset link now
Dec 17 13:37:57 kernel: [16803.590000] ata2: device plugged sstatus 0x123
Dec 17 13:37:57 kernel: [16806.520000] ata2: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Dec 17 13:37:57 kernel: [16806.530000] ata2: edma_err_cause=00000010 pp_flags=00000000, dev connect
Dec 17 13:37:57 kernel: [16806.530000] ata2: SError: { PHYRdyChg DevExch }

Dec 17 13:38:00 kernel: [16809.550000] ata1: SRST failed (errno=-16)
Dec 17 13:38:00 kernel: [16809.550000] ata1: SRST fail, set srst fail flag
Dec 17 13:38:01 kernel: [16810.650000] ata1: link reset sucessfully clear error flags
Dec 17 13:38:07 kernel: [16812.500000] ata2: link is slow to respond, please be patient (ready=0)

Dec 17 14:06:28 kernel: [18514.530000] ata1: wake up from deepsleep, reset link now
Dec 17 14:06:28 kernel: [18514.610000] ata1: device plugged sstatus 0x123
Dec 17 14:06:28 kernel: [18517.540000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Dec 17 14:06:28 kernel: [18517.550000] ata1: edma_err_cause=00000010 pp_flags=00000000, dev connect
Dec 17 14:06:28 kernel: [18517.550000] ata1: SError: { PHYRdyChg DevExch }

Dec 17 14:06:35 kernel: [18521.560000] ata2: wake up from deepsleep, reset link now
Dec 17 14:06:35 kernel: [18521.640000] ata2: device plugged sstatus 0x123
Dec 17 14:06:35 kernel: [18524.570000] ata2: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Dec 17 14:06:35 kernel: [18524.580000] ata2: edma_err_cause=00000010 pp_flags=00000000, dev connect
Dec 17 14:06:35 kernel: [18524.580000] ata2: SError: { PHYRdyChg DevExch }

Dec 17 14:06:38 kernel: [18527.600000] ata1: SRST failed (errno=-16)
Dec 17 14:06:38 kernel: [18527.600000] ata1: SRST fail, set srst fail flag
Dec 17 14:06:41 kernel: [18530.550000] ata2: link is slow to respond, please be patient (ready=0)
Dec 17 14:06:41 kernel: [18530.680000] ata1: link reset sucessfully clear error flags

Dec 17 14:28:47 kernel: [19853.150000] ata1: wake up from deepsleep, reset link now
Dec 17 14:28:47 kernel: [19853.230000] ata1: device plugged sstatus 0x123
Dec 17 14:28:47 kernel: [19856.160000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Dec 17 14:28:47 kernel: [19856.170000] ata1: edma_err_cause=00000010 pp_flags=00000000, dev connect
Dec 17 14:28:47 kernel: [19856.170000] ata1: SError: { PHYRdyChg DevExch }

Dec 17 14:28:54 kernel: [19860.180000] ata2: wake up from deepsleep, reset link now
Dec 17 14:28:54 kernel: [19860.260000] ata2: device plugged sstatus 0x123
Dec 17 14:28:54 kernel: [19863.190000] ata2: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Dec 17 14:28:54 kernel: [19863.200000] ata2: edma_err_cause=00000010 pp_flags=00000000, dev connect
Dec 17 14:28:54 kernel: [19863.200000] ata2: SError: { PHYRdyChg DevExch }

Dec 17 14:28:57 kernel: [19866.220000] ata1: SRST failed (errno=-16)
Dec 17 14:28:57 kernel: [19866.220000] ata1: SRST fail, set srst fail flag
Dec 17 14:28:58 kernel: [19867.560000] ata1: link reset sucessfully clear error flags
Dec 17 14:29:04 kernel: [19869.170000] ata2: link is slow to respond, please be patient (ready=0)

SRST fail, SError: { PHYRdyChg DevExch }, exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen ...

Une idée ? Le NAs utilise la dernière version de DSM 4.1 et n’exécute aucun paquet à part PhotoStation et Transmission. J'ajoute que le problème se produit également quand les deux paquets sont stoppés. Et que le test rapide SMART dans DSM ne détecte aucune erreur sur les disques.

Merci beaucoup,

Johnito

Modifié le 10 février 2013 par Johnito

[Johnito]

P'tit up ... Personne n'a d'idées ?

Modifié le 19 décembre 2012 par Johnito

[Dex]

Bonjour,

Si tu fais une recherche sur google avec "SError: { PHYRdyChg DevExch" ça semble être, je dis bien semble, lié au disque.

Tu as activé l'hibernation sur le NAS ? un test smart donne quoi ?

A+

David

[Johnito]

Merci pour la réponse. J'ai fait un test SMART sans erreurs sur les deux disques, je vais l'ajouter au post initial.

- L'hibernation (+ hibernation avancée) est activée. J'ai testé en désactivant l'hibernation avancée puis rebooté sans résultats.

- Je viens d'essayer en coupant complètement l'hibernation et cette fois le process ne semble plus grossir. Ca viendrait donc bien de ça, ou de quelque-chose de voisin lié à DSM.

Ca m'ennuie pas mal de désactiver la mise en veille du NAS ... enfin, disons que je sens que ça ne va pas plaire à son propriétaire. Syno vient de sortir une MAJ mineure de DSM 4.1, je reboote, et je teste à nouveau les trois situations (hibernation avancée, hibernation, rien) et je viendrais reporter l'avancement :-)

Modifié le 19 décembre 2012 par Johnito

[jfd]

Hello,

si t'es en raid, surtout ne pas mettre l'hibernation, au reveil, il peut y avoir un problème d'écriture que le NAS n'arrive pas à résoudre ou mal. personnellement, cela a mal fini avec un nas totalement bloqué à tenter de synchroniser ses disques avec une disponibilité de plus en plus courte puis une panne totale du volume (pas des disques)

En effet, le problème s'amplifie au fur et à mesures des écritures.

PAr ailleurs, il y a déjà une conversation sur ce sujet, qui semble montrer un problème dsm 4.1 avec l'hibernation , je te laisse découvrir, car le fil fait 3 pages et c'est noyé dedans

Enfin le propriétaire a deux solutions

Soit, il fait comme moi, il l'eteind car après tout, ce n'est qu'un pc

soit il a besoin d'une bonne disponibilité et il le laisse allumé normalement comme toute machine professionnelle qui se respecte.

S'il est radin, il peut calculer la différence de coût permanent/hibernation qui revient à une petite poignée d'euros sur l'année, cela le rassurera

A+

Modifié le 20 décembre 2012 par jfd

[knel]

Bonjour à tous,

Pas de suite sur ce sujet ? Même si on peut en effet enlever l'hibernation, ceci est quand même un bug...

Vous l'aurez deviné, je rencontre le même souci. A priori, même cause, même symptôme.

Ah petite précision quand même : je n'ai rien changé à ma config d'hibernation (à part un passage récent à 3h au lieu de 2) et depuis des mois il était comme ça sans aucun soucis. Les seuls changements récents sont donc ce paramètre (3h au lieu de 2), l'installation de "Serveur Multimédia" et le test de "Time backup" (désactivé depuis).

Cdt

KNel

Modifié le 8 février 2013 par knel

[Johnito]

Salut,

Pardon pour ne pas avoir donné l'épilogue. En fait, une fois passé le nouveau DSM bêta (4.2) le problème à tout simplement disparu : j'ai pu réactiver l'hibernation (même avancée) sans rencontrer de problèmes. Les logs ne font état d'aucun souci et la mise en veille fonctionne.

Je ne sais pas si la v4.2 comportait un correctif, une MAJ quelconque qui s'est averée salvatrice ou bien si le simple fait de mettre à jour le système à flush quelque-chose qui posait problème. Bref, mon passage en 4.2 a arrangé le problème du NAS sans que je ne sache l'expliquer.

Modifié le 7 juillet 2013 par Johnito