Was sagt der gesunde Menschenverstand? Mal eine andere Maus versuchen.
Wenn's das nächste mal passiert werde ich mal die vom alten PC einstecken und schauen ob sich so was bewegt.. Da aber der 2te Bildschirm mit den Tradingdaten auch eingefroren ist denke ich ist es ein anderes Problem und es ist ne Kabelmaus..
Handelt es sich dabei um ein Notebook oder einen Desktop PC ? Wenn auch der Resetschalter/Knopf nicht mehr funktioniert, hat das ganze kaum was mit der Software zu tun.
Und übrigens, kalte Lötstellen sind kein Mythos.
Handelt es sich dabei um ein Notebook oder einen Desktop PC ? Wenn auch der Resetschalter/Knopf nicht mehr funktioniert, hat das ganze kaum was mit der Software zu tun.
Es ist ein kein Notebook oder ähnliches.. Er ist über Nacht wieder stehen geblieben und habe die Maus umgesteckt und danach war sie dann auch dunkel geblieben. Auch die Tastatur reagierte nicht mehr. Und ja der Resetknopf auch wieder nicht, nur langes drücken des Start Knopfes. Er war also stehen geblieben in der Nacht und damit hat es nichts mit anklicken mit der Maus zu tun. Er war ja alleine..
Betriebssystem: openSUSE Leap 15.6
KDE-Plasma-Version: 5.27.11
KDE-Frameworks-Version: 5.115.0
Qt-Version: 5.15.12
Kernel-Version: 6.4.0-150600.23.30-default (64-bit)
Grafik-Plattform: X11
Prozessoren: 12 × AMD Ryzen 5 8500G w/ Radeon 740M Graphics
Speicher: 30,6 GiB Arbeitsspeicher
Grafikprozessor: AMD Radeon Graphics
Hersteller: ASUS
Midi Tower mit:
ASUS Prime B650-Plus
Kingston Fury 2x 16GB DDR5 5200MT/s CL40 - 40 - 40 2.25V XMP Diese habe ich bei Digitec gebraucht gekauft aber von Digitec qualitätsgeprüft..
12x AMD Ryzen 5 8500G mit integriertem Radeon 740M Grafik
Festplatten:
KINGSTON SFYRDK2000G = 1,8 TiB Internes Laufwerk (nvme1n1)
Samsung SSD 870 EVO 1TB = 931,5 GiB Internes Laufwerk (sda1)
Samsung SSD 870 EVO 1TB = 931,5 GiB Internes Laufwerk (sdb)
KINGSTON SNV2S250G = 232,9 GiB Internes Laufwerk (nvme0n1p1)Was mir beim durchschauen noch auffällt:
Dieses System hat eine niedrige HSI-Sicherheitsstufe.
» https://fwupd.github.io/hsi.html#low-security-level
Dieses System hat HSI-Laufzeitprobleme.
» https://fwupd.github.io/hsi.html#hsi-runtime-suffix
Bereit …: 0%
Host-Sicherheitskennung: HSI:0! (v1.9.10)
HSI-1
✔ BIOS Firmware-Aktualisierungen:Aktiviert
✔ Abgesicherte Plattform: Gesperrt
✔ Unterstützte CPU: Ungültig
✔ UEFI-Bootdienst-Variablen: Gesperrt
✘ TPM v2.0: Nicht gefunden
HSI-2
✔ SPI-Schreibschutz: Aktiviert
✔ IOMMU: Aktiviert
✔ Fehlerdiagnose der Plattform: Gesperrt
HSI-3
✘ SPI-Wiederholungsschutz: Nicht unterstützt
✘ DMA-Schutz vor dem Booten: Deaktiviert
✘ Im Leerlauf anhalten: Deaktiviert
✘ Im RAM anhalten: Aktiviert
HSI-4
✘ Prozessor-Rückrollschutz: Deaktiviert
✘ Verschlüsselter RAM: Nicht unterstützt
Laufzeit-Suffix -!
✔ fwupd-Plugins: Unverdorben
✔ Linux-Kernel: Unverdorben
✘ Linux-Kernel-Sperrung: Deaktiviert
✘ Linux-Auslagerung: Entschlüsselt
✘ Sicherer UEFI-Boot: DeaktiviertKann es an den gebrauchten RAM's liegen?
Habe die Kiste wie immer selber gebaut.
Schon mal vielen Dank für Eure Tipps und Bemühungen mir zu helfen.
Kann es an den gebrauchten RAM's liegen?
Habe die Kiste wie immer selber gebaut.
Wenn selbst gebaut, und du die nötigen Hardware-Kenntnisse hast, wer soll dir dann helfen?
Kann es an den gebrauchten RAM's liegen?
Zunächst solltest du überprüfen, mit welchen Taktraten die RAMs überhaupt betrieben werden sollen; ggf. heruntertakten!
Sollte es daran nicht liegen, könntest du im Ausschlussverfahren testen, ob einer der Riegel nicht so funktioniert wie er sollte. Dass alle 2 oder 4 Riegel gleichzeitig defekt sind, wäre statistisch sehr unwahrscheinlich. Also mal nur einen einzelnen Riegel testen, usw.
ich hatte vor vielen Jahren ein ähnliches Verhalten. Problem trat sporadisch und kaum reproduzierbar auf. Ursache war damals eine volle Root-Partition, oder besser gesagt sie ist durch LOG-Dateien, Snapshots und tmp-Dateien voll geworden. Je nachdem was lief bzw. gemacht wurde, hat es unterschiedlich lange bis zum Einfrieren gedauert...
ich hatte vor vielen Jahren ein ähnliches Verhalten. Problem trat sporadisch und kaum reproduzierbar auf. Ursache war damals eine volle Root-Partition, oder besser gesagt sie ist durch LOG-Dateien, Snapshots und tmp-Dateien voll geworden. Je nachdem was lief bzw. gemacht wurde, hat es unterschiedlich lange bis zum Einfrieren gedauert...
Das hatte ich auch mal vor Jahren, bei mir wars die /home Platte. Nun dies kanns diesmal nicht sein da alles fast leer ist jetzt noch am Anfang.
Zunächst solltest du überprüfen, mit welchen Taktraten die RAMs überhaupt betrieben werden sollen; ggf. heruntertakten!
Sollte es daran nicht liegen, könntest du im Ausschlussverfahren testen, ob einer der Riegel nicht so funktioniert wie er sollte. Dass alle 2 oder 4 Riegel gleichzeitig defekt sind, wäre statistisch sehr unwahrscheinlich. Also mal nur einen einzelnen Riegel testen, usw.
Die Idee ist mir gestern auch noch gekommen, habe dann mal im Bios manuel die Taktrate auf den maximalen Sollwert der RAM's gestellt. Habe mir gedacht das es ja möglich ist das der Bios die selbst übertaktet, da ja die Boards immer Werbung fürs gamen machen und das Overclock original auf Auto ist. Habe an so Sachen nie was verändert da ich davon wenig Ahnung habe und bis jetzt haben die Grundeinstellungen im Bios immer funktioniert gehabt. Nun das manuelle eintellen der Taktrate auf 5200 hat nun zur Folge das alles schwarz bleibt! So ein Mist.. Ich komme nun nicht mal mehr in den Bios. Wahrscheinlich wird es einen Jumper auf dem Mainboard haben um den Bios zu reseten?
