+-Serie DS112+ Kein Ruhezustand seit DSM-Update

[redunzl]

Am 1.9. wurde dieser Thread geöffnet, am 2.9. morgens habe ich ein Ticket aufgemacht, am 6.9. um 4 Uhr morgens habe ich eine Mail von Synology inkl. Link zum Patch erhalten. Halte ich als Reaktionszeit für durchaus angemessen. Ich kenne Hersteller, da passiert gar nix. Vielleicht irgendwann mal. Nach über 'ner Woche hier meckern? Frühstück ans Bett?

 

[nachon]

Am 1.9. wurde dieser Thread geöffnet, am 2.9. morgens habe ich ein Ticket aufgemacht, am 6.9. um 4 Uhr morgens habe ich eine Mail von Synology inkl. Link zum Patch erhalten. Halte ich als Reaktionszeit für durchaus angemessen. Ich kenne Hersteller, da passiert gar nix. Vielleicht irgendwann mal. Nach über 'ner Woche hier meckern? Frühstück ans Bett?

Sag mal, Du hast Dich doch bzgl des Problems mit einer DS 112+ gemeldet. Hast Du denselben Patch erhalten wie die anderen? Also auch den für die 2Bay Geräte?

 

[redunzl]

Nein, mit einer 212+ (Beitrag #12). Aber wenn du den Thread durchstöberst, wirst du auch Beiträge von 112er-Usern finden, die den Patch mit Erfolg anwenden konnten.

 

[harrykausl]

Ich habe den Patch auf meiner 212+ eingespielt. Danach gingen die Platten wie gedacht in hibernate. Leider wacht das Teil immer wieder auf, ich weiss nicht warum. Danach geht es irgendwann wieder in hiberante. Es läuft kein PC, d.h. niemand greift darauf zu.

 

[elendiir]

Servus,

habe genau das gleiche Problem wie harrykausl. Patch eingespielt. Die 212+ geht wieder in den Ruhezustand wacht aber sehr häufig wieder auf. Es erfolgt dabei definitiv kein Zugriff.
Komisch ist, dass nach dem Entfernen des default getways aus der Oberfläche und dem manuellen Setzen der Route das nicht passiert ist.
Hat wer eine Idee wo ich zu suchen anfagen soll?

Danke
Elendiir

 

[Benares]

An alle, die auch noch nach Einspielen des Patches Probleme mit dem Hibernate haben:

Killt mal den den ntpd (killall ntpd), der soll die Zeitsynchronisation machen, und schaut, ob das was bringt.

Gruß Benares

 

[harrykausl]

Und wie mache ich das. Wenn ich mit telnet als root drauf gehe, findet er den Prozess nicht.

 

[nachon]

Also, nun muss ich mich auch nochmal melden und würde mich über Eure Hilfe sehr freuen.

Ich habe eine DS 111 die ebenfalls nicht in den Hibernate zu gehen scheint.
Ich habe auch schon Kontakt mit dem Support, aber die Hilfe war bisher nicht sehr fruchtbar.

Nun habe ich mal den Hibernate Debug Mode laufen lassen und etwas mitgeloggt was da so passiert.
Dabei kam folgendes:

Sep 10 14:32:09 kernel: [18163.590000] [/etc/localtime] opened by pid 8930 [u: (/var/packages/CloudStation/targ), comm: (syncd)]
Sep 10 14:32:10 kernel: [18165.320000] [/var/run] opened by pid 11897 [u: (/usr/syno/bin/photostationd), comm: (photostationd)]
Sep 10 14:32:14 kernel: [18168.640000] [/etc/localtime] opened by pid 8930 [u: (/var/packages/CloudStation/targ), comm: (syncd)]
Sep 10 14:32:19 kernel: [18173.690000] [/etc/localtime] opened by pid 8930 [u: (/var/packages/CloudStation/targ), comm: (syncd)]
Sep 10 14:32:24 kernel: [18178.740000] [/etc/localtime] opened by pid 8930 [u: (/var/packages/CloudStation/targ), comm: (syncd)]
Sep 10 14:32:26 kernel: [18180.850000] [/var/packages/MediaServer/target/etc/dmsicon48.png] opened by pid 7216 [u/var/packages/MediaServer/targe), commdms)]
Sep 10 14:32:29 kernel: [18183.790000] [/etc/localtime] opened by pid 8930 [u: (/var/packages/CloudStation/targ), comm: (syncd)]
Sep 10 14:32:30 kernel: [18185.330000] [/var/run] opened by pid 11897 [u: (/usr/syno/bin/photostationd), commphotostationd)]
Sep 10 14:32:34 kernel: [18188.840000] [/etc/localtime] opened by pid 8930 [u: (/var/packages/CloudStation/targ), commsyncd)]

Was genau macht die CloudStation da?
Ich habe die CloudStation zwar aktiviert, aber nicht einen Client eingerichtet der diese nutzt oder darauf zugreift.

Also habe ich die CloudStation deaktiviert (nicht deinstalliert).

Nun geht die DS trotzdem nicht in den Hibernate Mode, und ich habe wieder geloggt mit folgendem Ergebnis:

Sep 11 19:18:56 kernel: [21316.190000] [/etc/localtime] opened by pid 2767 [u: (scemd), comm: (scemd)]
Sep 11 19:19:50 kernel: [21370.780000] [/var/run] opened by pid 12086 [u: (/usr/syno/bin/photostationd), comm: (photostationd)]
Sep 11 19:19:56 kernel: [21376.680000] [/etc/proxy.conf] opened by pid 4115 [u: (/usr/syno/sbin/ddnsd), comm: (ddnsd)]
Sep 11 19:20:10 kernel: [21390.790000] [/var/run] opened by pid 12086 [u: (/usr/syno/bin/photostationd), comm: (photostationd)]
Sep 11 19:20:30 kernel: [21410.800000] [/var/run] opened by pid 12086 [u: (/usr/syno/bin/photostationd), comm: (photostationd)]
Sep 11 19:20:50 kernel: [21430.810000] [/var/run] opened by pid 12086 [u: (/usr/syno/bin/photostationd), comm: (photostationd)]
Sep 11 19:21:10 kernel: [21450.820000] [/var/run] opened by pid 12086 [u: (/usr/syno/bin/photostationd), comm: (photostationd)]

Aber wieso denn nun die PhotoStation?

Ich verstehe gerade nicht ganz was da passiert und wie ich das abstellen bzw. ändern kann.

Kann mir jemand helfen?

Vielen Dank.

VG

 

[Benares]

Dann ist ja erstmal gut. Hast du bei NTP (Systemeinstellungen, Regionale Optionen) irgendwas konfiguriert?

 

[Benares]

@nachon
Ohne die Cloudstation ist das Fehlerbild wie bei mir. Deaktivier erstmal das syno_hibernation_debug_tool, das funktioniert bei der 4.1er irgendwie nicht und hält nur die Platten dauerhaft wach. Bez. Hibernation bin ich immernoch auf der Suche.

Hast du NTP aktiviert, läuft bei dir der ntpd?

Gruß Benares

 

[nachon]

Das Syno_Hibernate_Debug_Tool habe ich schon deaktiviert. Hatte es nur kurzzeitig mitlaufen lassen um einen Ausschnitt zu bekommen.

Ich habe eingestellt, dass die Zeit mit einem NTP-Server synchronisiert werden soll.
In der letzten Message Datei finde ich nichts mit "NTP".

Den Patch habe ich bei mir übrigens nicht eingespielt, da ich nur eine 1-Bay Maschine habe und der Patch auch lt. Support hierfür nicht gedacht ist.

 

[Benares]

Ich habe eingestellt, dass die Zeit mit einem NTP-Server synchronisiert werden soll.
In der letzten Message Datei finde ich nichts mit "NTP"

Dann schau mal, ob ein ntpd läuft (ps | grep ntpd) und schieß in ab (killall ntpd). Bei der 4.0 hat das ein cronjob erledigt, der immernoch da ist (s. /etc/crontab), aber nicht funktioniert, weil ntpd den ntp-Port blockiert. Ohne ntpd übernimmt der cronjob wieder die Zeitsynchronisation.
Momentan hab ich den laufenden ntpd im Verdacht.

Gruß Benares

 

[Shimmy]

Hallo zusammen,

ich habe auch eine DS 212+ und habe das gleiche bekannte Problem dass diese seit dem neuen DSM Update auf 4.1 nichtmehr in den Eingestellen Ruhezustand geht.

Durch einen sehr guten Freund der die DS 212 hat und auch dieses Problem hatte, wurde ich darauf Aufmerksam gemacht, dass es dazu eine Patch gibt den man sich herunterladen kann,
und welcher genau dieses Problem behebt.
Er hat sich jedenfalls diesen Patch vom Internet geladen, diesen dann per "Manueller DSM Aktualisierung" installiert und hat seit dem genau dieses Problem mit dem Ruhezustand nichtmehr mit der DSM 4.1. Version.

Ich habe nun also von Ihm diesen Datei Patch der sich übrigens fix2BaySleep-4.1.2636 nennt bekommen, habe versucht diesen auf dem gleichen Weg wie er es gemacht hat zu Installieren doch leider funktioniert dass nicht bei mir.
Beim dem Manuellen Installieren dieses Patches muss dieser bekanntlich ausgewählt werden und anschließend kommt ein Fenster mit der Meldung "Daten werden vom Server übertragen. Bitte warten..."
Wenn diese Medlung dann vorbei ist poppt ein neues Fenster auf mit einem Balken wo der Update fortschritt angezeigt wird mit Sekunden die heruterzählen bis zum Neustart.
Mein Problem ist nun, dass diese Sekunden bei mir nicht bis zum Ende Herunterzählen, sondern bei ca. noch verbleibenden 377 Sekunden bis zu Neustart dieser so gesehn Abbricht, der NAS neu startet und ich dann wieder den "normalen" Anmeldebildschirm für meinen NAS bekomme.

Hat hier jemand evtl. genau dass gleich Problem wie ich? ...was kann ich gegen dieses so gesehene abbrechen der Installation tun? ...woran liegt dass überhaupt dass er dieses nicht vollständig durchführt? :-(

....den so gesehenen Fehler bzgl. dem Ruhezustand habe ich somit natürlich auch weiterhin noch versteht sich !!! :-(

Ich bin für jede Hilfe bzgl. dieser Probleme (Anscheineder Abbruch der Installation und nicht Funktionierender Ruhezustand) sehr Dankbar !!!!!!!!

Viele Grüße,

Shimmy

 

[Frogman]

Dass er nicht komplett bis 0 herunterzählt, muß Dich nicht beunruhigen. Letztlich ist das nur ein fester Timeout, um der Box genügend Zeit zu geben, nach dem Einspielen eines Updates neuzustarten. Sobald das erfolgt ist, wird wieder der Anmeldeschirm gezeigt.

Hast Du denn nach dem Einspielen des Patches immer noch das Problem, dass die Platten nicht in den Hibernate-Modus gehen? Was hast Du denn an zusätzlichen Paketen installiert/aktiviert?

 

[nachon]

Dann schau mal, ob ein ntpd läuft (ps | grep ntpd) und schieß in ab (killall ntpd). Bei der 4.0 hat das ein cronjob erledigt, der immernoch da ist (s. /etc/crontab), aber nicht funktioniert, weil ntpd den ntp-Port blockiert. Ohne ntpd übernimmt der cronjob wieder die Zeitsynchronisation.
Momentan hab ich den laufenden ntpd im Verdacht.

Gruß Benares

Nö.

Der Support vermutet nun die "Face Recognation", die ich aber eigentlich nicht angestellt habe. Ist die per Default aktiviert?
Ich prüfe das heute Abend nochmal.

 

[Ap0phis]

Ich habe den ntpd auch gekillt.
Nun läuft auch der tägliche ntp-sync wieder.

 

[Benares]

Mit dem Patch und dem gekillten ntpd funktioniert es bei mir wieder wie zu 4.0-Zeiten

...
Sep 11 21:51:02 scemd: SCEMD: disk 1 wake up from hibernation
Sep 11 21:51:09 scemd: SCEMD: disk 2 wake up from hibernation
Sep 11 21:51:18 scemd: net_default_gateway_set.c:36 failed to set default gateway 192.168.0.1 (-1).
Sep 11 21:51:18 scemd: net_default_gateway_set.c:36 failed to set default gateway 192.168.0.1 (-1).
Sep 12 00:00:09 kernel: [448175.000000] ata1: wake up from deepsleep, reset link now
Sep 12 00:00:09 kernel: [448175.080000] ata1: device plugged sstatus 0x123
Sep 12 00:00:09 kernel: [448178.010000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Sep 12 00:00:09 kernel: [448178.020000] ata1: edma_err_cause=00000010 pp_flags=00000000, dev connect
Sep 12 00:00:09 kernel: [448178.020000] ata1: SError: { PHYRdyChg DevExch }
Sep 12 00:00:10 ntpdate: Sync with time server 192.168.0.1 offset -0.171920 sec.
Sep 12 00:00:16 kernel: [448182.030000] ata2: wake up from deepsleep, reset link now
Sep 12 00:00:16 kernel: [448182.110000] ata2: device plugged sstatus 0x123
Sep 12 00:00:16 kernel: [448185.040000] ata2: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Sep 12 00:00:16 kernel: [448185.050000] ata2: edma_err_cause=00000010 pp_flags=00000000, dev connect
Sep 12 00:00:16 kernel: [448185.050000] ata2: SError: { PHYRdyChg DevExch }
Sep 12 00:00:19 kernel: [448188.070000] ata1: SRST failed (errno=-16)
Sep 12 00:00:19 kernel: [448188.070000] ata1: SRST fail, set srst fail flag
Sep 12 00:00:22 kernel: [448191.030000] ata1: link reset sucessfully clear error flags
Sep 12 00:00:22 kernel: [448191.070000] ata2: link is slow to respond, please be patient (ready=0)
Sep 12 00:00:22 kernel: [448191.140000] ata1.00: Disable disk write cache in EH
Sep 12 00:00:26 kernel: [448195.090000] ata2: SRST failed (errno=-16)
Sep 12 00:00:26 kernel: [448195.100000] ata2: SRST fail, set srst fail flag
Sep 12 00:00:29 kernel: [448197.870000] ata2: link reset sucessfully clear error flags
Sep 12 00:00:29 kernel: [448197.980000] ata2.00: Disable disk write cache in EH
Sep 12 00:00:30 scemd: net_default_gateway_set.c:36 failed to set default gateway 192.168.0.1 (-1).
Sep 12 00:00:30 scemd: net_default_gateway_set.c:36 failed to set default gateway 192.168.0.1 (-1).
Sep 12 03:07:17 kernel: [459403.120000] ata1: wake up from deepsleep, reset link now
Sep 12 03:07:17 kernel: [459403.200000] ata1: device plugged sstatus 0x123
Sep 12 03:07:17 kernel: [459406.130000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Sep 12 03:07:17 kernel: [459406.140000] ata1: edma_err_cause=00000010 pp_flags=00000000, dev connect
Sep 12 03:07:17 kernel: [459406.140000] ata1: SError: { PHYRdyChg DevExch }
Sep 12 03:07:24 kernel: [459410.150000] ata2: wake up from deepsleep, reset link now
Sep 12 03:07:24 kernel: [459410.230000] ata2: device plugged sstatus 0x123
Sep 12 03:07:24 kernel: [459413.160000] ata2: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Sep 12 03:07:24 kernel: [459413.170000] ata2: edma_err_cause=00000010 pp_flags=00000000, dev connect
Sep 12 03:07:24 kernel: [459413.170000] ata2: SError: { PHYRdyChg DevExch }
Sep 12 03:07:27 kernel: [459416.180000] ata1: SRST failed (errno=-16)
Sep 12 03:07:27 kernel: [459416.180000] ata1: SRST fail, set srst fail flag
Sep 12 03:07:30 kernel: [459419.190000] ata2: link is slow to respond, please be patient (ready=0)
Sep 12 03:07:30 kernel: [459419.260000] ata1: link reset sucessfully clear error flags
Sep 12 03:07:37 kernel: [459419.350000] ata1.00: Disable disk write cache in EH
Sep 12 03:07:37 kernel: [459423.210000] ata2: SRST failed (errno=-16)
Sep 12 03:07:37 kernel: [459423.220000] ata2: SRST fail, set srst fail flag
Sep 12 03:07:37 kernel: [459425.570000] ata2: link reset sucessfully clear error flags
Sep 12 03:07:37 kernel: [459425.680000] ata2.00: Disable disk write cache in EH
Sep 12 03:07:37 scemd: net_default_gateway_set.c:36 failed to set default gateway 192.168.0.1 (-1).
Sep 12 03:07:37 scemd: net_default_gateway_set.c:36 failed to set default gateway 192.168.0.1 (-1).
Sep 12 17:44:42 kernel: [512048.000000] ata1: wake up from deepsleep, reset link now
Sep 12 17:44:42 kernel: [512048.080000] ata1: device plugged sstatus 0x123
Sep 12 17:44:42 kernel: [512051.010000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
...

Der Spinup um 0 Uhr ist die ntp-Aktualisierung (cron-Job) und der Spinup um 03:07 Uhr ist DDNS-Aktualisierung nach der Zwangstrennung.

Gruß Benares

 

[Shimmy]

@ Frogman :

Ja, ich habe trotz des einspielens bzw. instalieren des Patches trotzdem dass Problem weiterhin dass er nicht in den Ruhezustand geht wie eingestellt.

Bzgl. dem Installieren des Patches noch einmal, da ist es so dass er immer ziehmlich genau bei 375-377 Sekunden noch verbleibender Zeit neu startet
bzw. dann eben auch der Anmeldebildschirm erscheint.
Du meinst dass ist kein Problem oder? ..bzw. hat er die Installation des Patches trotzdem erfolgreich abgeschlossen oder?

Zuätzliche Pakete die ich installiert habe sind folgende :
- Photostation / - Medienserver / - TimeBackup / -Audiostation / - Mailstation / -VideoStation

@ An Alle :

Was ich hier gelesen habe könnte dass Problem bzgl. dem Ruhemodus auch an dem ntpd liegen.
Da ich mich leider noch nicht so gut auskenne habe ich dazu auch Fragen:

- Was ist diese Anwendung ntpd überhaupt? ..und was aber viel wichtiger ist, wie kann ich diese ntpd anwendung überhaupt killen? ..brauche ich dafür ein zusätzliches Programm oder etc. um mir die laufenden Prozesse vom NAS anzeigen zu lassen und diese dann auch zu killen? ..oder was muss ich da machen dass ich diese killen kann?

Vielen Dank euere Hilfe !!!!!!!!!!

Gruß,

Shimmy

 

[AleksCee]

@Shimmy: ntp(d) ist network time protocol und das d steht für Dämon.
Die DS nutzt 2 Wege zum automatischen Zeit einstellen. ntpclient und ntpd neuerdings wohl auch. Der war zwar schon immer da wurde aber nur als Server verwendet wenn man die Uhren anderer Geräte, die das können, von der DS die Zeit holen lassen wollte. Jetzt nutzt man ihn wohl auch zum holen der Zeit.
Grundsätzlicher Unterschied, der Client holt die Zeit 1 mal (wenn nicht im cron manuell geändert) 1 Mal am Tag, der Dämon läuft immer und vergleicht kontinuierlich die empfangene Zeit und bildet anhand von bestimmten regeln Abweichungen und versucht so eine möglichst genaue Zeit zu ermitteln... einfach wegen der Tolleranzen im Netz... sieht du ja auch beim Ping mal bekommt man eine Antwort in 2ms mal in 10 oder 30 ms... sowas ist doof wenn die Server wirklich gleich "ticken" müssen.... daher gibt sich der ntpd da etwas mehr "Mühe".... ;-)
mein Verdacht ist auch schon länger dieser Dienst.. zum einen war er mir in der DSM4.0 nicht aufgefallen und zum anderen greift der ständig (wenn man mit strace zuguckt was er so treibt) auf /etc/proxy.conf zu... der Proxy ist ja auch neu seit der 4.1... warum er die Datei allerdings ständig sucht, auch wenn sie nicht da ist, verstehe ich nicht. soll man doch einmal gucken und sich merken das der Proxy wohl nicht genutzt wird. wie auch immer.
"killen" kannst du den ntp nur wenn du auf die DS mit telnet oder ssh drauf gehst.
wobei du das auch erstmal ohne viel fummeln von der Syno machen lassen kannst.
auf dem prompt einfach mal: /usr/syno/etc/rc.d/S23ntpd.sh stop
schreiben und dann mit: ps w |grep ntp |grep -v grep
gucken ob keine Ausgabe mehr kommt. sollte noch was kommen dann die Prozess id (die erste Nummer der Zeile vor dem ntpd) "merken" und ein kill drauf machen:
kill ID
z.B.: kill 9191919

 

[elendiir]

Servus,

jetzt muss ich mich nochmal melden.
Folgender Zustand meiner DS212+:

• DS 4.1 + Patch eingespielt
• ntpd läuft nicht
• Faceerkennung ist aus
• Kein Zugriff vom internen Netz bzw. über der Portweiterleitung meines Routers aus dem I-Net (habe zum Testen die DS nur am Router angesteckt und dabei alle Portweiterleitungen deaktiviert)
• am USB-Port hängt eine externe 2.5 Zoll HD
• laufende Dienste: Photo Station, Time Backup, Medienserver, Audio Station und VPN Server

Die DS geht nach 10 Minuten auch brav in den Ruhezustand (erweiterter Ruhezustand). Dummerweise wird dieser durch irgendein Ergebnis regelmäßig (etwa 30 Minuten) unterbrochen.

In /var/log/messages finden sich die folgenden Meldungen:

Sep 13 08:58:55 scemd: net_default_gateway_set.c:36 failed to set default gateway 192.168.178.1 (-1).

Sep 13 09:33:59 kernel: [56983.180000] ata2: wake up from deepsleep, reset link now
Sep 13 09:33:59 kernel: [56983.240000] ata2: device plugged sstatus 0x123
Sep 13 09:33:59 kernel: [56986.190000] ata2: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Sep 13 09:33:59 kernel: [56986.200000] ata2: edma_err_cause=00000010 pp_flags=00000000, dev connect
Sep 13 09:33:59 kernel: [56986.200000] ata2: SError: { PHYRdyChg DevExch }
Sep 13 09:34:06 kernel: [56990.210000] ata1: wake up from deepsleep, reset link now
Sep 13 09:34:06 kernel: [56990.270000] ata1: device plugged sstatus 0x123
Sep 13 09:34:06 kernel: [56993.220000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Sep 13 09:34:06 kernel: [56993.230000] ata1: edma_err_cause=00000010 pp_flags=00000000, dev connect
Sep 13 09:34:06 kernel: [56993.230000] ata1: SError: { PHYRdyChg DevExch }
Sep 13 09:34:09 kernel: [56996.240000] ata2: SRST failed (errno=-16)
Sep 13 09:34:09 kernel: [56996.240000] ata2: SRST fail, set srst fail flag
Sep 13 09:34:11 kernel: [56997.820000] ata2: link reset sucessfully clear error flags
Sep 13 09:34:19 kernel: [56999.250000] ata1: link is slow to respond, please be patient (ready=0)
Sep 13 09:34:19 kernel: [57003.270000] ata1: SRST failed (errno=-16)
Sep 13 09:34:19 kernel: [57003.270000] ata1: SRST fail, set srst fail flag
Sep 13 09:34:19 kernel: [57005.750000] ata1: link reset sucessfully clear error flags
Sep 13 09:34:20 scemd: net_default_gateway_set.c:36 failed to set default gateway 192.168.178.1 (-1).
Sep 13 09:34:20 scemd: net_default_gateway_set.c:36 failed to set default gateway 192.168.178.1 (-1).

Sep 13 10:49:13 kernel: [61495.590000] ata2: wake up from deepsleep, reset link now
Sep 13 10:49:24 kernel: [61495.650000] ata2: device plugged sstatus 0x123
Sep 13 10:49:24 kernel: [61498.600000] ata2: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Sep 13 10:49:24 kernel: [61498.610000] ata2: edma_err_cause=00000010 pp_flags=00000000, dev connect
Sep 13 10:49:24 kernel: [61498.610000] ata2: SError: { PHYRdyChg DevExch }
Sep 13 10:49:24 kernel: [61502.620000] ata1: wake up from deepsleep, reset link now
Sep 13 10:49:24 kernel: [61502.680000] ata1: device plugged sstatus 0x123
Sep 13 10:49:24 kernel: [61505.630000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Sep 13 10:49:24 kernel: [61505.640000] ata1: edma_err_cause=00000010 pp_flags=00000000, dev connect
Sep 13 10:49:24 kernel: [61505.640000] ata1: SError: { PHYRdyChg DevExch }
Sep 13 10:49:24 kernel: [61508.670000] ata2: SRST failed (errno=-16)
Sep 13 10:49:24 kernel: [61508.670000] ata2: SRST fail, set srst fail flag
Sep 13 10:49:24 kernel: [61510.190000] ata2: link reset sucessfully clear error flags
Sep 13 10:49:26 kernel: [61511.600000] ata1: link is slow to respond, please be patient (ready=0)
Sep 13 10:49:30 kernel: [61515.680000] ata1: SRST failed (errno=-16)
Sep 13 10:49:30 kernel: [61515.680000] ata1: SRST fail, set srst fail flag
Sep 13 10:49:32 kernel: [61518.100000] ata1: link reset sucessfully clear error flags
Sep 13 10:49:33 scemd: net_default_gateway_set.c:36 failed to set default gateway 192.168.178.1 (-1).
Sep 13 10:49:33 scemd: net_default_gateway_set.c:36 failed to set default gateway 192.168.178.1 (-1).

Sep 13 11:18:26 kernel: [63249.770000] ata1: wake up from deepsleep, reset link now

(Die Leerzeilen habe ich zur besseren Lesbarkeit zwischen den Blöcken eingefügt)

Noch eine Idee was ich Testen könnte?

Danke,
Elendiir