Beiträge von Klaang im Thema „Nach MB- und CPU-Umbau ständiger HDD/SSD-Zugriff“

    So, der "Fehler" scheint gefunden zu sein. Offensichtlich hat Beatbetrieb mit seiner Aussage, dass es sich dabei lediglich um "Lebenszeichen" der SSD handelt, wohl Recht, denn es wird ja auch nichts gelesen oder geschrieben. Ich muss hier wohl auf ein FW-Update des SanDisk-Controllers hoffen (WD ist ein Tochterunternehmen von SD), denn andere m.2 NVMe-SSDs von z. B. Samsung, Crucial usw. haben diesen Bug nicht. Woher ich das weiß? Sofern Google und DeepL richtig übersetzt haben, bin ich am Wochenende in einem russischen Forum fündig geworden, wo dieser Bug ebenfalls beschrieben wurde. Es ist also kein Problem, sondern einfach nur nervig und ich muss auch, an El Pollo Diablo , keinen Kernreaktor bauen ;) .

    So, Schnauze voll: Habe eben eine WD Black SN770 bestellt. Ist zwar PCIe-4.0-technisch nicht die Schnellste, aber wen juckt's. Mal schaun, ob mit "Blinki" dann Schluss ist. Werde dann spätestens am nächsten Wochenende berichten. Versuch mach bekanntlich kluch.

    Edit und (enttäuschende) Ergänzung: Habe die NVMe-3.0-SSD (WD Blue SN570) soeben auf/in dem m.2-PCIe 4.0-Slot (m.2_2.1) installiert. Mit dem aktuellen BIOS (3002) läuft sie zwar auch dort, aber "Blinki" ist noch immer nicht verschwunden. Na ja, scheint wohl "normal" zu sein und ich kann meine Bestellung wieder stornieren.

    Also jetzt bin ich auch bei der Antwort: "Zieh einfach den Stecker ab oder installier einfach mal alles von vorne."

    Nee, nee. Schon Albert Einstein hat erkannt, dass es keinen Sinn ergibt, ein und das selbe Experiment 100x zu wiederholen in der Hoffnung, das irgendwann mal ein anderes Ergebnis dabei rauskommt. Diese Aussage kann man auch auf unsere heutigen (politischen) Zeiten übertragen, aber das wäre jetzt maximal OT und gehört hier nicht hin.

    Ich glaube, ich bin dem Problem auf/bei reddit etwas näher gekommen. Es scheint in gewisser Weise etwas mit der MB-HW und meiner Installation zu tun zu haben. Das Asus Prime B550 Plus hat 2 m.2-Slots: 1x NVMe /PCIe 3.0 bzw./alternativ 1x SATA 3 PCIe und 1x NVMe/PCIe 4.0. Meine derzeitige NVMe-SSD (WB Blue SN570), die als Systemlaufwerk dient, ist im m.2 PCIe 3.0-Slot installiert, da sie im 4er-Slot nicht erkannt wird und dementsprechend auch nicht läuft. Der m.2 PCIe 3.0-Slot "teilt" sich jedoch den Anschluss mit den SATA 3-Ports #5 und 6 sowie den PCIe-1x-Slots 2 und 3 des MBs. An den SATA-Anschlüssen #5 und 6 ist zwar nichts angeschlossen, ebenso auch nicht an den MB-PCIe 1x-Slots des MBs, aber die SW des MBs scheint aufgrund dieser "Teilung" ständig zu überprüfen, ob an SATA #5 und 6 und/oder PCIe #2 und 3 noch was angeschlossen ist. Klingt jetzt alles sehr verwirrend? Ja, ist es vielleicht auch. Jedenfalls werde ich demnächst mal auf eine PCIe 4.0-NVMe-SSD umsteigen und die dann auch im 4er-Slot einbauen. Dann sollte das "Blinki-Problem" behoben sein.

    Der Thread hat mich jetzt dazu animiert mich anzumelden :) (lese hier im Forum schon seit einiger Zeit mit).

    Ich würde mal in die Logfiles schauen ob permanent Fehler geschrieben werden. Das hatte ich bei fehlenden Modulen.

    In einem Terminal:

    journalctl -r oder cat /var/log/syslog manuell durchsuchen

    Vielen Dank. Bei journalctl -r kommt

    Mär 17 21:50:57 K-PC systemd[1498]: Started VTE child process 6819 launched by gnome-terminal-server process 6794.

    Mär 17 21:50:57 K-PC systemd[1498]: Started GNOME Terminal Server.

    Mär 17 21:50:57 K-PC dbus-daemon[1525]: [session uid=1000 pid=1525] Successfully activated service 'org.gnome.Terminal'

    Mär 17 21:50:57 K-PC systemd[1498]: Starting GNOME Terminal Server...

    Mär 17 21:50:57 K-PC dbus-daemon[1525]: [session uid=1000 pid=1525] Activating via systemd: service name='org.gnome.Terminal' unit='gnome-terminal-server.service' requested by ':1.135' (uid=1000 pi>

    Mär 17 21:50:19 K-PC kernel: [UFW BLOCK] IN=enp6s0 OUT= MAC=33:33:00:00:00:01:3c:a6:2f:78:25:e0:86:dd SRC=fe80:0000:0000:0000:3ea6:2fff:fe78:25e0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 >

    Mär 17 21:50:06 K-PC kernel: [UFW BLOCK] IN=enp6s0 OUT= MAC=01:00:5e:00:00:01:3c:a6:2f:78:25:e0:08:00 SRC=192.168.178.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=45774 DF PROTO=2

    Mär 17 21:48:37 K-PC systemd[1498]: Started VTE child process 6735 launched by gnome-terminal-server process 6710.

    Mär 17 21:48:37 K-PC systemd[1498]: Started GNOME Terminal Server.

    Mär 17 21:48:37 K-PC dbus-daemon[1525]: [session uid=1000 pid=1525] Successfully activated service 'org.gnome.Terminal'

    Mär 17 21:48:37 K-PC systemd[1498]: Starting GNOME Terminal Server...

    Mär 17 21:48:37 K-PC dbus-daemon[1525]: [session uid=1000 pid=1525] Activating via systemd: service name='org.gnome.Terminal' unit='gnome-terminal-server.service' requested by ':1.133' (uid=1000 pi>

    Mär 17 21:48:01 K-PC kernel: [UFW BLOCK] IN=enp6s0 OUT= MAC=01:00:5e:00:00:01:3c:a6:2f:78:25:e0:08:00 SRC=192.168.178.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=45679 DF PROTO=2

    Mär 17 21:46:37 K-PC systemd[1498]: vte-spawn-61a89650-7e33-4cdb-947c-224e5df03cc4.scope: Consumed 14.020s CPU time.

    Mär 17 21:46:37 K-PC sudo[6666]: pam_unix(sudo:session): session closed for user root

    Mär 17 21:46:23 K-PC sudo[6666]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)

    Mär 17 21:46:23 K-PC sudo[6666]: juergen : TTY=pts/0 ; PWD=/home/juergen ; USER=root ; COMMAND=/usr/sbin/iotop -t -o -qqq -d .1

    Mär 17 21:45:56 K-PC kernel: [UFW BLOCK] IN=enp6s0 OUT= MAC=01:00:5e:00:00:01:3c:a6:2f:78:25:e0:08:00 SRC=192.168.178.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=6181 DF PROTO=2

    Mär 17 21:45:54 K-PC systemd[1498]: Started VTE child process 6651 launched by gnome-terminal-server process 6626.

    Mär 17 21:45:54 K-PC systemd[1498]: Started GNOME Terminal Server.

    Mär 17 21:45:54 K-PC dbus-daemon[1525]: [session uid=1000 pid=1525] Successfully activated service 'org.gnome.Terminal'

    Mär 17 21:45:54 K-PC systemd[1498]: Starting GNOME Terminal Server...

    Mär 17 21:45:54 K-PC systemd[1498]: Created slice Slice /app/org.gnome.Terminal.

    Mär 17 21:45:54 K-PC dbus-daemon[1525]: [session uid=1000 pid=1525] Activating via systemd: service name='org.gnome.Terminal' unit='gnome-terminal-server.service' requested by ':1.131' (uid=1000 pi>

    Mär 17 21:44:10 K-PC rtkit-daemon[1515]: Supervising 8 threads of 3 processes of 1 users.

    Mär 17 21:44:10 K-PC rtkit-daemon[1515]: Supervising 8 threads of 3 processes of 1 users.

    Mär 17 21:44:07 K-PC rtkit-daemon[1515]: Supervising 8 threads of 3 processes of 1 users.

    Mär 17 21:44:07 K-PC rtkit-daemon[1515]: Supervising 8 threads of 3 processes of 1 users.

    Mär 17 21:44:07 K-PC rtkit-daemon[1515]: Supervising 8 threads of 3 processes of 1 users.

    Mär 17 21:44:07 K-PC rtkit-daemon[1515]: Supervising 8 threads of 3 processes of 1 users.

    Mär 17 21:44:07 K-PC rtkit-daemon[1515]: Supervising 8 threads of 3 processes of 1 users.

    Mär 17 21:44:07 K-PC rtkit-daemon[1515]: Supervising 8 threads of 3 processes of 1 users.

    Mär 17 21:44:06 K-PC rtkit-daemon[1515]: Supervising 8 threads of 3 processes of 1 users.

    Mär 17 21:44:06 K-PC rtkit-daemon[1515]: Supervising 8 threads of 3 processes of 1 users.

    Mär 17 21:44:06 K-PC rtkit-daemon[1515]: Supervising 8 threads of 3 processes of 1 users.

    Mär 17 21:44:06 K-PC rtkit-daemon[1515]: Successfully made thread 6321 of process 6224 owned by '1000' RT at priority 10.

    Mär 17 21:44:06 K-PC rtkit-daemon[1515]: Supervising 7 threads of 2 processes of 1 users.

    Mär 17 21:44:06 K-PC rtkit-daemon[1515]: Supervising 7 threads of 2 processes of 1 users.

    Mär 17 21:44:06 K-PC rtkit-daemon[1515]: Supervising 7 threads of 2 processes of 1 users.

    Mär 17 21:44:06 K-PC rtkit-daemon[1515]: Supervising 7 threads of 2 processes of 1 users.

    Mär 17 21:44:06 K-PC rtkit-daemon[1515]: Supervising 7 threads of 2 processes of 1 users.

    Mär 17 21:44:06 K-PC rtkit-daemon[1515]: Supervising 7 threads of 2 processes of 1 users.

    Mär 17 21:43:51 K-PC kernel: [UFW BLOCK] IN=enp6s0 OUT= MAC=01:00:5e:00:00:01:3c:a6:2f:78:25:e0:08:00 SRC=192.168.178.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=65070 DF PROTO=2

    Mär 17 21:43:47 K-PC rtkit-daemon[1515]: Supervising 7 threads of 2 processes of 1 users.

    Mär 17 21:43:47 K-PC rtkit-daemon[1515]: Successfully made thread 6205 of process 1507 owned by '1000' RT at priority 5.

    Mär 17 21:43:47 K-PC rtkit-daemon[1515]: Supervising 6 threads of 2 processes of 1 users.

    Mär 17 21:43:04 K-PC rtkit-daemon[1515]: Supervising 7 threads of 2 processes of 1 users.

    Mär 17 21:43:04 K-PC rtkit-daemon[1515]: Successfully made thread 6171 of process 1507 owned by '1000' RT at priority 5.

    Mär 17 21:43:04 K-PC rtkit-daemon[1515]: Supervising 6 threads of 2 processes of 1 users.

    Mär 17 21:42:21 K-PC rtkit-daemon[1515]: Supervising 7 threads of 2 processes of 1 users.

    Mär 17 21:42:21 K-PC rtkit-daemon[1515]: Successfully made thread 6101 of process 1507 owned by '1000' RT at priority 5.

    und bei cat /var/log/syslog kommen gefühlt 30.000 Zeilen, die ich hier nicht posten kann.

    Tja, das würde dann auf eine "Eigenart" des MB-Chipsatzes hinweisen, die aber störend ist, da ich in der Horizontalen über ein recht ausgeprägtes peripheres Sehen verfüge (ca. 170°) und mich dieses permanente "Geblinke" irgendwie unterschwellig nervt. Na ja, notfalls helfen da Klebeband (für die LED) oder Scheuklappen ;) .

    Oder könnte es vielleicht sein, dass ich beim Anschluss der Pins auf dem MB + und - vertauscht habe? Aber ich glaube, dann dürfte die HDD-LED nicht funktionieren. Die Kabelanschlussstecker meines Gehäuses (be quiet Silent Base 800) sind - für mich - nicht eindeutig gekennzeichnet. Ein Stecker ist gar nicht gekennzeichnet und ein Stecker hat ein auf die Spitze gedrehtes Dreieck, was auch immer das bedeutet. Beide Kabel (+/-) sind schwaz und das Handbuch des Gehäuses sagt dazu auch nichts aus.

    Hallo Gemeinde,

    nachdem ich vor einigen Tagen von Intel auf AMD umgestiegen bin, also einen MB- und CPU-Tausch vorgenommen habe, läuft meine Kiste zwar völlig ok, aber eine Sache verstehe ich nicht. Selbst dann, wenn der Rechenknecht nur im Idle läuft, keine Musikwiedergabe, wirklich rein gar nichts und sogar stundenlang nur der Desktop angezeigt wird, keine anderen Programme gestartet oder sonstwas, habe ich permanent(!) alle 1-2 Sekunden einen kurzen SSD- oder HDD-Zugriff. Zumindest leuchtet die Laufwerkskontrollleuchte immer wieder entsprechend kurzfristig auf, siehe Video.

    Forum.mp4

    Vorher (mit Asus Z170PG und i7 6700K) hatte ich dieses "Problem" nicht. An Laufwerken angeschlossen sind 1x NVMe 3.0 SSD WD Blue SN570, 1x SATA 3 SSD Samsung QVO 960 und 1 x SATA 3 Toshiba HDD. Sind das nur Lesezugriffe (und wenn ja, was wird da permanent gelesen?) oder handelt es sich um Schreibvorgänge auf SSD? Letzteres wäre natürlich ärgerlich, weil das dann extrem auf die Lebensdauer der SSD(s) gehen würde. Es spielt auch keine Rolle, ob ich den Kernel 5.15 oder 5.19 installiert habe. Oder ist das eine "Eigenart" des B550-Chipsatzes? Vielleicht kennt von Euch ja jemand eine Antwort.