Hallo manjaro2017,
ich will ja nichts ausschliessen, aber wenn es an Grub liegt, dann bist Du einer von hundert Geschätzt 99% haben dieses Problem nicht, warum sollte also dein Grub anders reagieren?
Ich denke immer noch an den Tipp von Blueriver mit haveged, vielleicht ist da was schief gelaufen. Poste mal die Ausgabe von
Er meldet sich automatisch an.
Vom Grub bis Desktop 3 Min
● haveged.service - Entropy Harvesting Daemon
Loaded: loaded (/usr/lib/systemd/system/haveged.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2019-06-30 19:51:57 CEST; 3min 20s ago
Docs: man:haveged(8)
Process: 435 ExecStartPre=/usr/bin/sysctl -w kernel.random.write_wakeup_threshold=1024 (code=exited, status=0/SUCCESS)
Main PID: 440 (haveged)
Tasks: 1 (limit: 4915)
Memory: 3.7M
CGroup: /system.slice/haveged.service
└─440 /usr/bin/haveged --Foreground --verbose=1
Jun 30 19:51:57 pc systemd[1]: Starting Entropy Harvesting Daemon...
Jun 30 19:51:57 pc sysctl[435]: kernel.random.write_wakeup_threshold = 1024
Jun 30 19:51:57 pc systemd[1]: Started Entropy Harvesting Daemon.
Jun 30 19:51:57 pc haveged[440]: haveged: listening socket at 3
Jun 30 19:51:58 pc haveged[440]: haveged: ver: 1.9.4; arch: x86; vend: ; build: (gcc 8.2.0 ITV); collect: 128K
Jun 30 19:51:58 pc haveged[440]: haveged: cpu: (VC); data: 64K (V); inst: 64K (V); idx: 39/40; sz: 52825/52825
Jun 30 19:51:58 pc haveged[440]: haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B): last entropy estimate 7.99935
Jun 30 19:51:58 pc haveged[440]: haveged: fills: 0, generated: 0
Habe grad ein anderes Problem komme in Linux nicht mehr rein.
Habe Dosbox gestartet und es ging in den fullscreen ich kam leider nicht raus und hab den pc resetet.
Danach ist er neugestartet und wenn ich die Maus sehe geht der Monitor in den Standby aber der pc arbeitet weiter das hört man. Und dann kann ich nichts mehr machen.
Windows läuft ohne Probleme
manjaro2017 hat geschrieben: ↑Montag 1. Juli 2019, 18:25
Habe grad ein anderes Problem komme in Linux nicht mehr rein.
Habe Dosbox gestartet und es ging in den fullscreen ich kam leider nicht raus und hab den pc resetet.
Danach ist er neugestartet und wenn ich die Maus sehe geht der Monitor in den Standby aber der pc arbeitet weiter das hört man. Und dann kann ich nichts mehr machen.
Eine Aufgabe gut zu lösen ist erheblich besser als viele Probleme zu leugnen.
manjaro2017 hat geschrieben: ↑Dienstag 2. Juli 2019, 10:01Wie nett
Überrascht?
Außer "funktioniert nicht" lieferst du doch gar keine brauchbaren Infos.
Du hast dir nicht mal die Mühe gemacht auf tty1 nachzusehen, was systemd macht bevor dein Desktop sichbar wird.
manjaro2017 hat geschrieben: ↑Dienstag 2. Juli 2019, 10:01Wie nett
Überrascht?
Außer "funktioniert nicht" lieferst du doch gar keine brauchbaren Infos.
Du hast dir nicht mal die Mühe gemacht auf tty1 nachzusehen, was systemd macht bevor dein Desktop sichbar wird.
MfG
Und wie kann ich da nach sehen mit welchen befehl hast du mir leider nicht gesagt
Graphics:
Device-1: AMD Juniper XT [Radeon HD 5770] vendor: PC Partner Limited
driver: radeon v: kernel bus ID: 02:00.0
Device-2: AMD Juniper XT [Radeon HD 5770] vendor: PC Partner Limited
driver: radeon v: kernel bus ID: 03:00.0
Obwohl für Linux-Spieler zu diesem Zeitpunkt nicht besonders relevant, verzichtet AMD auf ihr CrossFire-Branding und nennt es einfach nur ihre mGPU-Technologie.
Der Begriff mGPU ist nur eine Abkürzung für Multi-GPU. Sie verzichten auf ihr Multi-GPU "CrossFire"-Branding, da sich der Ansatz bei der Nutzung mehrerer GPUs durch Spiele ändert. Traditionelles CrossFire, ähnlich wie NVIDIAs SLI, hat sich auf Spielprofile verlassen, um das Rendering über mehrere Grafikkarten hinweg zu nutzen. Das war mit Direct3D 11 und früher (und OpenGL), während mit Direct3D 12 die Verantwortung für das Multi-GPU-Handling auf den Entwickler abgewälzt wird, mit den D3D12-APIs für implizite und explizite Multi-Adapter-Unterstützung. Somit ist es wirklich nicht mehr "CrossFire", sondern nur noch mGPU für zukünftige Spiele.
Vulkan ähnelt Direct3D 12, da die Verantwortung für die Handhabung von Multi-GPUs dem Spieleentwickler über Erweiterungen für die Verwaltung von Ressourcen und das Rendering über mehrere GPUs hinweg überlassen wird.
Wenn es um die CrossFire-Unterstützung unter Linux geht, haben die RadeonSI+AMDGPU- oder AMDGPU-PRO-Stacks diese nicht im herkömmlichen Sinne unterstützt. Mit dem ehemaligen Catalyst/fglrx-Treiberstapel gab es OpenGL CrossFire-Unterstützung, aber es war weitgehend nutzlos und nicht viele Spielprofile wurden unter Linux unterstützt, so dass die Vorteile minimal waren. Aber mit dem Vulkan-Support gibt es den genannten Support, aber es ist eine Frage der Zeit, wann Spieleentwickler anfangen, ihren Renderern Multi-GPU-Vulkan-Unterstützung hinzuzufügen.....
Es gibt nichts, was jemanden daran hindert, OpenGL CrossFire-Unterstützung zum Open-Source AMD Linux Grafikstapel hinzuzufügen, aber es wird wahrscheinlich nie kommen.
Übersetzt mit www.DeepL.com/Translator