Kein Spindown nach Hardwareaustausch mit aktiviertem powertop


55 posts in this topic Last Reply

Recommended Posts

Posted (edited)

Hallo, 

 

nach meinem Hardwareaustausch ist mir aufgefallen, dass meine Platten nicht mehr in den Spindown gehen. 
Wenn ich powertop --auto-tune im go file deaktiviere funktioniert es ganz normal. 
 

Komisch finde ich auch folgende Meldung beim Bootvorgang wenn ich powertop --auto-tune aktiviert habe.

 

Hat jemand eine Lösung dafür?

 

EDIT: Den Ordner /var/cache/powertop habe ich zwischenzeitlich schon mal gelöscht. Leider ohne Erfolg.

 

CF267DDC-E3F9-4690-B2C1-0CB1CA4BC919.jpeg

Edited by Anym001
Link to post
  • Replies 54
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Ich glaube die Meldung rührt eher daher, dass Powertop ursprünglich mal für Laptops gedacht war und die interne (Laptop-)Batterie getestet werden sollte. Und da der 08/15 Unraid-Server kein eingebaute

Kurze Zwischeninfo:   Habe powertop gestern Abend deinstalliert. Heute in der Nacht Spindown ganz normal.   Habe powertop heute in der Früh wieder installiert, aber ohne Befeh

Ich kann einfach nicht mehr rekonstruieren wodurch mein Spindown/-up Problem behoben wurde. Mal ging es nur mit Hilfe des SAS-Plugins, mal ohne. Und irgendwann war das Problem einfach weg. Ich konnte

Posted Images

Diverse Meldungen sind ja eigentlich normal. So viele hatte ich meine ich aber auch noch nicht.

 

1 hour ago, Anym001 said:

Den Ordner /var/cache/powertop habe ich zwischenzeitlich schon mal gelöscht. Leider ohne Erfolg.

Und was soll das bringen? Der Ordner wird ja bei jedem Neustart dadurch erstellt, dass das Nerd Pack powertop installiert.

 

Was du probieren könntest, wäre die Befehle einzeln abzusetzen. Du siehst ja hier zb eine Liste mit Befehlen:

https://forums.unraid.net/topic/98070-reduce-power-consumption-with-powertop/

 

 

Du gehst also hin und deinstalliert powertop über das Nerd Pack. Außerdem startest du den Server neu, damit keine Regeln mehr aktiv sind.

 

Nun führst du einen der Befehle aus und wartest ab, ob das nun dein Problem verursacht hat.

 

Einen Zusammenhang kann ich da aber ehrlich gesagt nicht herstellen. Der Powerstatus von SATA oder PCIe hat ja nichts mit dem Spindown Befehl von Unraid zu tun... Wäre ziemlich komisch. Oder setzt du eine SATA / HBA Karte ein?

 

Link to post
3 minutes ago, mgutt said:

Was du probieren könntest, wäre die Befehle einzeln abzusetzen.


Das werde ich mal testen. 
 

3 minutes ago, mgutt said:

Einen Zusammenhang kann ich da aber ehrlich gesagt nicht herstellen. Der Powerstatus von SATA oder PCIe hat ja nichts mit dem Spindown Befehl von Unraid zu tun... Wäre ziemlich komisch. Oder setzt du eine SATA / HBA Karte ein?


Nein verwende keine Karten, nur interne SATA Ports. 
 

Link to post

Kurze Zwischeninfo:

 

Habe powertop gestern Abend deinstalliert.

Heute in der Nacht Spindown ganz normal.

 

Habe powertop heute in der Früh wieder installiert, aber ohne Befehle auszuführen.

Spindown auch ganz normal.

 

Werde jetzt mal die Befehle einzeln absetzen und schauen wer da der Übeltäter ist.

Link to post

Ich habe den Übeltäter gefunden:

Quote

# Enable SATA link power management

for i in /sys/class/scsi_host/host*/link_power_management_policy; do

echo 'med_power_with_dipm' > $i

done

 

Hier kommt folgende Fehlermeldung im Syslog:

Quote

Jun 10 09:33:01 nas kernel: ahci 0000:00:17.0: port does not support device sleep

Jun 10 09:33:01 nas kernel: ahci 0000:00:17.0: port does not support device sleep

Jun 10 09:33:02 nas kernel: clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large:

Jun 10 09:33:02 nas kernel: clocksource: 'hpet' wd_now: 92274da6 wd_last: 91c6f146 mask: ffffffff

Jun 10 09:33:02 nas kernel: clocksource: 'tsc' cs_now: aa0ab034c867 cs_last: aa0a3983f649 mask: ffffffffffffffff

Jun 10 09:33:02 nas kernel: tsc: Marking TSC unstable due to clocksource watchdog

Jun 10 09:33:02 nas kernel: TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.

Jun 10 09:33:02 nas kernel: sched_clock: Marking unstable (46630688013441, 955547879)<-(46631645259416, -1687699)

Jun 10 09:33:02 nas kernel: clocksource: Switched to clocksource hpet

 

Hat jemand eine Idee wie ich das beheben kann?

Muss hier eine Einstellung im BIOS vorgenommen werden?

Link to post
7 minutes ago, Anym001 said:

Hat jemand eine Idee wie ich das beheben kann?

Muss hier eine Einstellung im BIOS vorgenommen werden?

Probier mal das zu deiner syslinux.cfg hinzuzufügen: "hpet=enable" (ohne Anführungszeichen) und reboote

Sieht so aus als würde irgendwas mit deiner clocksource nicht stimmen...

grafik.thumb.png.3291088a59257e7f2f54a71fe340b644.png

 

Eventuell behebt es das Problem in deinem fall wenn du die clocksource gleich auf hpet stellst.

 

EDIT: Btw das bedeuted übrigens TSC: Klick

Link to post
Posted (edited)

Der Eintrag hpet=enable hat leider nichts geholfen.

 

Wenn ich folgenden Befehl ausführe, kommt wieder die gleiche Meldung im Syslog.

Quote

# Enable SATA link power management

for i in /sys/class/scsi_host/host*/link_power_management_policy; do

echo 'med_power_with_dipm' > $i

done

 

EDIT: Interessant ist auch, dass wenn ich diesen Befehl NICHT aktiviere, ich die tiefen C-States nicht erreiche:

 

grafik.thumb.png.5034d6d9dbda8e9a29c4d14e77309571.png

 

Wenn der Befehl jedoch aktiv ist, dann bekomme ich auch unter Pkg(Hw) ca. 70-80% im C10 State.

Allerdings funktioniert halt der Spindown dann nicht mehr.

 

Edited by Anym001
Link to post
3 hours ago, Anym001 said:

Habe powertop heute in der Früh wieder installiert, aber ohne Befehle auszuführen.

 

3 hours ago, Anym001 said:

Werde jetzt mal die Befehle einzeln absetzen und schauen wer da der Übeltäter ist.

 

Die Befehle funktionieren unabhängig von powertop. Soll heißen du brauchst powertop nicht, wenn du die Befehle manuell absetzt. "powertop --auto-tune" ist nur einfach die bequemere Variante um alle diese Befehle in einem Rutsch auszuführen.

 

1 hour ago, Anym001 said:

ahci 0000:00:17.0: port does not support device sleep

Ist das die ID vom SATA Controller oder von einem bestimmten Port?

 

1 hour ago, Anym001 said:

# Enable SATA link power management

for i in /sys/class/scsi_host/host*/link_power_management_policy; do

echo 'med_power_with_dipm' > $i

done

 

Dieses Kommando aktiviert auf allen SATA Ports "DIPM", also das "Device Initiated Power Management" und damit darf das angeschlossene SATA Device den SATA Port in den Standby versetzen. Damit das geht, muss man ALPM im BIOS aktivieren, wobei ich eigentlich davon ausging, dass das automatisch durch CEC 2019 passiert. Check mal im BIOS unter Peripherals > SATA And RST Configuration > Aggressive LPM Support. Das muss auf Enabled stehen.

 

Link to post
Posted (edited)

Hab jetzt mal ALPM im BIOS aktiviert.

 

Danach neugestartet und den Befehl von neuem ausgeführt.

Quote

# Enable SATA link power management

for i in /sys/class/scsi_host/host*/link_power_management_policy; do

echo 'med_power_with_dipm' > $i

done

 

Folgende Fehlermeldungen tretten nach wie vor auf:

Quote

Jun 10 11:29:21 nas kernel: ahci 0000:00:17.0: port does not support device sleep

Jun 10 11:29:51 nas kernel: clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large:

Jun 10 11:29:51 nas kernel: clocksource: 'hpet' wd_now: 4bf26bf4 wd_last: 4b77793e mask: ffffffff

Jun 10 11:29:51 nas kernel: clocksource: 'tsc' cs_now: ec47463090 cs_last: ebd080bfed mask: ffffffffffffffff

Jun 10 11:29:51 nas kernel: tsc: Marking TSC unstable due to clocksource watchdog

Jun 10 11:29:51 nas kernel: TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.

Jun 10 11:29:51 nas kernel: sched_clock: Marking unstable (232689669255, 3609899)<-(232694936383, -1657210)

Jun 10 11:29:51 nas kernel: clocksource: Switched to clocksource hpet

 

Folgende Fehlermeldung habe ich gerade noch bekommen:

Quote

Jun 10 11:36:01 nas ntpd[1741]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

 

Ich denke, dass ist direkt der SATA Controller.

grafik.png.0e96e0f6e340e7e8cbcbb38fbfe34407.png

 

Nach wie vor kein Spindown.

 

Habe im BIOS über die Einstellung ALPM gesehen, dass man unter SATA Mode Selection auch etwas umstellen kann. (AHCI und Intel RST Premium With Intel Optane System Acceleration)

Kann es eventuell noch an dieser Einstellung liegen?

 

EDIT: Habe das BIOS nochmal auf Standardeinstellungen zurückgesetzt und folgendes verändert:

1. M.I.T. -> Advanced Frequency Settings -> Advanced CPU Settings -> C-Stats Control -> Enabled

2. Periphers -> Storage Mode for MiniSAS HD -> 4xSATA

3. Periphers -> SATA And RST Configuration -> ALPM -> Enabled

4. Chipset -> Audio Controller -> Disabled

5. BIOS -> Windows 8/10 Features -> Other OS

6. Power -> AC Back -> Always On

7. Power -> CEC 2019 Ready -> Enabled

 

BIOS Version F2c

Edited by Anym001
Link to post
2 hours ago, Anym001 said:

den Befehl von neuem ausgeführt.

...

Folgende Fehlermeldungen treten nach wie vor auf:

Ja moment. Die Fehlermeldungen kommen ja vor der Ausführung des Befehls. Welche Fehler kommen denn durch den Befehl? Weil da muss ja eigentlich irgendwas kommen, wenn deswegen der Spindown nicht mehr geht.

 

EDIT: Die Fehlermeldung habe ich bei meinem Testaufbau auch:

image.thumb.png.ada3827de6cb217bbe54fe2ea1087b9e.png

 

2 hours ago, Anym001 said:
Quote

Jun 10 11:36:01 nas ntpd[1741]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

 

Die Meldung hat glaube ich jeder.

 

3 hours ago, Anym001 said:

Jun 10 11:29:51 nas kernel: clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large:

Jun 10 11:29:51 nas kernel: clocksource: 'hpet' wd_now: 4bf26bf4 wd_last: 4b77793e mask: ffffffff

Jun 10 11:29:51 nas kernel: clocksource: 'tsc' cs_now: ec47463090 cs_last: ebd080bfed mask: ffffffffffffffff

Jun 10 11:29:51 nas kernel: tsc: Marking TSC unstable due to clocksource watchdog

Nach meiner Recherche kommt dieser Fehler zustande, weil der Kernel die CPU auf ihre Genauigkeit hin testet. Dh er erkennt die CPU Frequenz, mist dann die Zeit und bei Bedarf passt er die Frequenz minimal an, so dass der Timer 100%-tig stimmt. Siehe auch das Ergebnis von meinem Testaufbau mit einem C246N-WU2:

image.thumb.png.ef6fbc054c5a006dc8c6f135af3045ee.png

 

In deinem Fall meldet er "skew is too large". Daraus schließe ich, dass er die Frequenz nicht anpassen kann, weil er sonst irgendein Limit überschreiten würde.

 

Das bringt mich gleich zur Frage: Wie vertrauenswürdig ist die Quelle deiner CPU?

 

Ich habe beim Testaufbau übrigens deine BIOS Einstellungen übernommen bis auf "C-Stats Control". Das habe ich nicht. Allerdings hat mein Mainboard auch noch das BIOS F1. Daher bestünde auch die Möglichkeit, dass das neueste BIOS evtl einen Bug hat? Oder der durch das BIOS der CPU eingeflößte Microcode?!

 

Ich habe mich nicht getraut ein Update zu machen, weil Gigabyte nur das F2c zum Download anbietet. Eventuell kannst du ja mal bei Gigabyte fragen ob die dir das F1 für ein Downgrade schicken würden.

 

20 hours ago, Anym001 said:

meine Platten nicht mehr in den Spindown gehen

Kannst du eigentlich die Platten nach Ausführung des Befehls über das Dashboard in den Spindown schicken?

 

4 hours ago, Anym001 said:

EDIT: Interessant ist auch, dass wenn ich diesen Befehl NICHT aktiviere, ich die tiefen C-States nicht erreiche:

Das kann gut sein. Hattest du denn die anderen Befehle bereits ausgeführt, so dass bei Powertop im letzten Tab alles andere außer SATA auf "Good" stand?

Link to post
9 minutes ago, mgutt said:

Welche Fehler kommen denn durch den Befehl? Weil da muss ja eigentlich irgendwas kommen, wenn deswegen der Spindown nicht mehr geht.

 

Wenn ich den Befehl über Userscripts ausführe, kommt danach diesmal im Syslog folgendes.

Beide HDD`s waren im Spindown, und durch den Befehl wurde die Parity aufgeweckt, die zweite Disk schläft noch.

Außerdem spuckt die Parity nun eine Warnung für einen Command Timeout aus. (War vorher nicht)

 

grafik.thumb.png.23fd1379d6bfcf3b753957775caac507.png

 

13 minutes ago, mgutt said:

Wie vertrauenswürdig ist die Quelle deiner CPU?

 

Die Quelle dieser CPU bist du. ^^

 

14 minutes ago, mgutt said:

Daher bestünde auch die Möglichkeit, dass das neueste BIOS evtl einen Bug hat? Oder der durch das BIOS der CPU eingeflößte Microcode?!

 

Ich habe mir das F1 weggesichert, bevor ich auf F2c gewechselt bin.

Das müsste ich eigentlich drüber bügeln können oder?

 

14 minutes ago, mgutt said:

Kannst du eigentlich die Platten nach Ausführung des Befehls über das Dashboard in den Spindown schicken?

 

Ja manuell geht.

 

15 minutes ago, mgutt said:

Hattest du denn die anderen Befehle bereits ausgeführt, so dass bei Powertop im letzten Tab alles andere außer SATA auf "Good" stand?

 

Ja alles außer SATA steht aktuell auf "Good".

Folgendes ist aktuell im go file aktiv:

Quote

# Runtime PM for PCI devices
for i in /sys/bus/pci/devices/????:??:??.?/power/control; do
    echo 'auto' > $i
done
# Runtime PM for port ata od PCI devices
for i in /sys/bus/pci/devices/????:??:??.?/ata*/power/control; do
    echo 'auto' > $i
done
# Autosuspend for USB device
for i in echo /sys/bus/usb/devices/*/power/control; do
    echo 'auto' > $i
done
# Disable wake on lan
for i in /sys/class/net/eth?; do
    ethtool -s  $(basename $i) wol d
done
# VM writeback timeout
for i in /proc/sys/vm/dirty_writeback_centisecs; do
    echo '1500' > $i
done
# Runtime PM for disk
for i in /sys/block/sd*/device/power/control; do
    echo 'auto' > $i
done

 

 

Link to post
13 minutes ago, Anym001 said:

Die Quelle dieser CPU bist du. ^^

 

😅

 

14 minutes ago, Anym001 said:

Ich habe mir das F1 weggesichert, bevor ich auf F2c gewechselt bin.

Das müsste ich eigentlich drüber bügeln können oder?

🤷‍♂️

Link to post
5 hours ago, ich777 said:

hpet=enable

 

hpet ist beim OP enabled - muss somit nicht in die syslinux. hpet wurde gewählt nachdem tsc als unstabil markiert wurde. Das Thema habe ich bei mir nur durch neue Hardware beheben können. Da half bei mir nichts Anderes.

 

Folgende Befehle helfen den Überblick zu verschaffen - ich glaube aber nicht, dass es etwas mit dem Spindown zu tun hat. Das System wird nur langsamer TSC ist m.W. die schnellste Clock zum Synchronisieren z.B. von Threads, da er im Prozessor selbst als Zähler steckt:

 

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

 

Link to post
Posted (edited)
31 minutes ago, mgutt said:
46 minutes ago, Anym001 said:

Ich habe mir das F1 weggesichert, bevor ich auf F2c gewechselt bin.

Das müsste ich eigentlich drüber bügeln können oder?

🤷‍♂️

 

Ich habe jetzt mal dem Gigabyte Support geschrieben, ob man das machen kann.

Hätte wahrscheinlich gar nicht updaten sollen....

 

10 minutes ago, hawihoney said:

Das Thema habe ich bei mir nur durch neue Hardware beheben können. Da half bei mir nichts Anderes.

 

Na super...

Hab die Hardware gerade erst bekommen und eingebaut. ^^

Wobei wenn das Thema mit dem Spindown nichts zu tun hat, kann ich das ja auch vernachlässigen oder?

 

10 minutes ago, hawihoney said:

Folgende Befehle helfen den Überblick zu verschaffen

 

grafik.png.1b3a86df0e0bed93cebde772fe7e6add.png

 

Edited by Anym001
Link to post
40 minutes ago, Anym001 said:

Wobei wenn das Thema mit dem Spindown nichts zu tun hat, kann ich das ja auch vernachlässigen oder?

 

Ja, meiner Meinung nach hat das eine (SpinDown) mit dem anderen (Clocksource) nichts zu tun.

 

Bei Dir ist aktuell TSC aktiv - sehr gut. Wenn dem Kernel TSC zu unstabil wird, dann wechselt er auf HPET, der ist auch noch sehr gut. Wenn das auch noch gegen ACPI_PM gewechselt würde bekämst Du ein Problem. Die Performance fällt dann drastisch. Bei mir ging es auf 1/3 runter. Das sehe ich bei Dir derzeit aber nicht.

 

Was den Mist mit dem Spindown/-up angeht: Keine Ahnung. Ich hatte selbst seit 6.9.x damit zu kämpfen. Im Moment läuft es, selbst ohne SAS-Plugin.

Link to post
7 minutes ago, mgutt said:

Die Platten waren aber 1:1 auch im alten Server oder? Und da hattest du bereits 6.9.2?

 

Ich kann einfach nicht mehr rekonstruieren wodurch mein Spindown/-up Problem behoben wurde. Mal ging es nur mit Hilfe des SAS-Plugins, mal ohne. Und irgendwann war das Problem einfach weg. Ich konnte das Problem auch in Unraid VMs sehen, die haben bei mir nur screen als Erweiterung, sonst nix. Docker System und VM System sind dort abgeschaltet. Kein Cache/Pool, keine User Shares. Die LSI Firmwares sind alle auf dem letzten Stand.

 

Die Probleme starteten mit 6.9.x, mit alter und neuer Hardware (nur die ersten 1-2 Tage). Frag mich nicht wieso, im Moment habe ich weder Spindown/-up Probleme noch Clocksource Probleme. Und meine Konfiguration, die ist unverändert seit langem.

 

Allerdings habe ich wieder das sekündliche Festplatten Blip an den Drive-Carriers. Als würden die HBA sekündliche abfragen ob die Platten noch da sind. Das kannte ich früher nur bei einem gestoppten Array. Die Carrier flashten dann im Sekundentakt. Ich habe dann eine alte Platte rausgezogen, eine neue reingeschoben, die lief dann an und flashte ebenfalls im Sekundentakt. Nach dem Start des Arrays war das dann wieder weg. Das habe ich seit 6.9 (alte und neue Hardware) nun auch bei gestartetem Array. Ich hatte das mal als Bug gemeldet, dann war es durch SAS-Plugin weg und irgendwann wieder da.

 

Langsam glaube ich an Wasseradern oder Erdstrahlen ...

 

 

Link to post
43 minutes ago, hawihoney said:

Ja, meiner Meinung nach hat das eine (SpinDown) mit dem anderen (Clocksource) nichts zu tun.

 

Bei Dir ist aktuell TSC aktiv - sehr gut. Wenn dem Kernel TSC zu unstabil wird, dann wechselt er auf HPET, der ist auch noch sehr gut.

 

Okay super gut zu wissen.

 

23 minutes ago, mgutt said:

Die Platten waren aber 1:1 auch im alten Server oder? Und da hattest du bereits 6.9.2?

 

Ja die HDD's waren 1:1 verbaut.

6.9.2 hatte ich auch. Ohne Probleme.

Das einzige was ich getauscht hab sind die SATA Kabel. Da hab ich die mitgelieferten vom C246N-WU2 genommen.

Das könnte ich eventuell noch versuchen zu tauschen auf die vorherigen Kabeln.

Link to post

Wenn der Befehl abgesetzt wurde, check mal bitte ob der Read / Write der Platten im Dashboard steigt (also alle 30 Minuten mal schauen). Unraid nutzt diese Zahlen um zu erkennen ob die Platten gerade genutzt werden oder nicht.

Link to post
On 6/9/2021 at 6:57 PM, Anym001 said:

Komisch finde ich auch folgende Meldung beim Bootvorgang wenn ich powertop --auto-tune aktiviert habe.

 

Hier mein Testaufbau: 😁

image.thumb.png.24f02308b193608e0f08097384de96b0.png

 

Powertop Ergebnis:

powertop --auto-tune
modprobe cpufreq_stats failedLoaded 0 prior measurements
RAPL device for cpu 0
RAPL device for cpu 0
Devfreq not enabled
glob returned GLOB_ABORTED
 the port is sda
 the port is sdb
 the port is sdc
 the port is sdd
 the port is sde
Leaving PowerTOP

 

Einziger Unterschied zu dir ist, dass ich keine Parity ausgewählt habe:

image.thumb.png.0c09617a1e6c07af27789bf5c0fa4aae.png

 

Aktueller Verbrauch 8,8W. Wenn ich eine Platte hochfahre 15,37W. Während die läuft steht bei powertop "C9 (pc9)   86.5%". Das hatte ich noch nie ^^

 

Das F1 BIOS sichern geht nur über Windows oder?

Usage :
    efiflash [Input or Output File Name] [Command]..

   Switch options for Efiflash.exe:
    /C - Clear DMI data. (default: Keep DMI data)
    /S - Save Original BIOS Image to Disk
    /R - Reboot System after BIOS Update
    /DB- Update both main & backup BIOS

 

 

Link to post

Habe jetzt folgendes gemacht:

- Server runtergefahren

- Kabel ausgetauscht (die zuvor bei den HDDs verbaut waren)

- BIOS auf F1 zurückgesetzt (Downgrade mit meinem gespeicherten BIOS hat funktionier =D )

- powertop --auto-tune im go file eingetragen und die "einzelnen" Befehle deaktiviert

- Spindown time auf 15min gestellt

 

Folgende Meldung beim Booten:

IMG_0994.thumb.JPG.6b4b3aee67abaa32ac269d50f1185a78.JPG

 

powertop Übersicht: (Alle Werte auf "Good")

powertop.thumb.png.95f7370f1688ca074448abe2dab9bbb8.png

 

Komischerweise deaktiviert er jetzt wieder tsc:

tsc.png.dabb156f81d3610e08a11122da426873.png

 

Anscheinend gibt es hier Probleme mit den C10 States?

https://bugzilla.kernel.org/show_bug.cgi?id=203183

 

Folgende Meldungen im Syslog fallen mir auf:

syslog.png.08fea5f24cfed653c0a21820bef0c736.png

 

Auch interessant ist:

Habe den Server um 07:23 Uhr gestartet.

Jetzt ist es 08:18 Uhr.

Uptime im Unraid Dashboard lautet 21min. -> WTF?!?

 

Die Platten gehen leider nach wie vor nicht in den Spindown.

 

07:35 Uhr

0735.thumb.png.50ab98115d59de2db4e044e57e0561cb.png

 

07:58 Uhr

0758.thumb.png.1d18272599f183609606f2423f0be9a9.png

 

08:15 Uhr

0815.thumb.png.042281f2061c7b6e66fa595eaf6ef64e.png

 

 

 

Link to post

...was bedeutet denn die Angabe im startlog

file will be loaded after taking minimum number of measurements with battery only

 

ich nutze den apcd nicht, sondern NUT für meine eaton USV....da gibt es sowas nicht.

Evtl. also eine Problem mit dem apcd bzw. dessen config?...vielleicht muss der apcd "angelernt" werden?

@Anym001ich nehme an, die USV läuft im Netz- und nicht Batterie-Betrieb?

 

 

Link to post
Posted (edited)
1 hour ago, Ford Prefect said:

@Anym001ich nehme an, die USV läuft im Netz- und nicht Batterie-Betrieb?


Ich hab gar keine USV. ^^
 

Kurzes Update:

Hab den Server jetzt mal ca. 3-4 Stunden mit aktiviertem powertop laufen lassen. 
Irgendwann ist er dann doch in den Spindown gegangen. Das scheint also zu funktionieren.

 

Was jedoch eigenartig ist, dass die Uhrzeiten überhaupt nicht zusammenpassen. (Deshalb wahrscheinlich auch der Spindown erst irgendwann)

Und das der RAM Fehler auswirft. (Siehe Screenshot)

Bin gerade dabei einen Memtest durchzuführen. Vielleicht liegt es ja daran. 
 

EDIT:

Bei aktiviertem powertop wechselt er zu hpet. 
Wenn ich ohne powertop starte, bleibt er bei tsc. 
 

 

1462A7B1-DF19-489D-AB97-F66721E0E2D3.png

Edited by Anym001
Link to post

Da sind auch noch zwei Sachen nicht in Ordnung:

 

image.png.b03cf394d8b55f12d17c19f74bca17c9.png

 

Hast du vnstatd über Nerd Pack installiert? So einen ähnlichen Fall hatten wir erst die Tage:

 

Und die rclone-Meldung musst du wissen. Hast du da evtl noch Befehle in der Go File oder ein Script, das bei Array-Start ausgeführt wird?

 

3 hours ago, Anym001 said:

Anscheinend gibt es hier Probleme mit den C10 States?

 

Eventuell mal im BIOS auf C8 limitieren, aber ich denke da ist was anderes das Problem.

 

4 hours ago, Anym001 said:

Habe den Server um 07:23 Uhr gestartet.

Jetzt ist es 08:18 Uhr.

Uptime im Unraid Dashboard lautet 21min. -> WTF?!?

Ja da stimmt irgendwas nicht mit dem Zeitmesser. Auf mich wirkt das wie ein Hardware-Problem. Vielleicht sollte man doch mal die CPU oder das Board tauschen. Wenn du magst kann ich dir mein Test-Board senden, wo der i3-8100 und ein 16GB Modul installiert ist. Dann hättest du einen 1:1 Vergleich. Sollte es damit gehen, könntest du den 8100 dann ja mal bei deinem Board testen und dann wissen wir ja ob es an der Hardware liegt. Schick mir dazu dann bitte noch mal eine E-Mail.

 

Kann sowas auch durch ein defektes Netzteil entstehen? Also wegen zu geringer Spannung? Das könnte dann ja sogar den RAM-Fehler erklären. Teste vielleicht auch mal ein anderes Netzteil. Einfach zur Sicherheit.

Link to post
1 hour ago, mgutt said:

Hast du vnstatd über Nerd Pack installiert?


Glaub nicht, müsste ich mal nachsehen. 
Momentan läuft der Memtest. 
 

1 hour ago, mgutt said:

Und die rclone-Meldung musst du wissen. Hast du da evtl noch Befehle in der Go File oder ein Script, das bei Array-Start ausgeführt wird?


Das Mount Script für rclone wird beim Array Start ausgeführt. 
Werde ich mir mal in Ruhe ansehen. 
 

1 hour ago, mgutt said:

Eventuell mal im BIOS auf C8 limitieren, aber ich denke da ist was anderes das Problem.


Das hätte ich schon versucht. 
Wird jedoch irgendwie überschrieben. 
Server mit powertop gestartet und danach wieder ins BIOS -> C10 war wieder aktiv

 

1 hour ago, mgutt said:

Ja da stimmt irgendwas nicht mit dem Zeitmesser. Auf mich wirkt das wie ein Hardware-Problem. Vielleicht sollte man doch mal die CPU oder das Board tauschen. Wenn du magst kann ich dir mein Test-Board senden, wo der i3-8100 und ein 16GB Modul installiert ist. Dann hättest du einen 1:1 Vergleich. Sollte es damit gehen, könntest du den 8100 dann ja mal bei deinem Board testen und dann wissen wir ja ob es an der Hardware liegt. Schick mir dazu dann bitte noch mal eine E-Mail.


Komisch das das aber nur auftritt wenn powertop aktiv ist? 
 

1 hour ago, mgutt said:

Kann sowas auch durch ein defektes Netzteil entstehen? Also wegen zu geringer Spannung? Das könnte dann ja sogar den RAM-Fehler erklären. Teste vielleicht auch mal ein anderes Netzteil. Einfach zur Sicherheit.


Das gleiche Netzteil war auch schon bei den “alten” Komponenten verbaut. Hier gab es keine Fehler. 
 

Hier mal der Zwischenbericht des Memtest: (Kann das jemand interpretieren?)

Meiner Meinung nach gab es zwar Fehler, die aber durch ECC korrigiert wurden und somit keine Fehler sind. Verstehe ich das richtig?

 

C891E644-CAEA-4F32-99A9-9D70B0004E88.jpeg

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.