Wenn der BT Adapter einfach wieder ausgeht nach dem Einstecken…

dann macht doch mal das hier:

$ sudo bluetoothctl power on ; sudo systemctl restart bluetooth

Wenn der BT Adapter einfach wieder ausgeht nach dem Einstecken…

Die Ursache könnte nämlich einfach ein kleiner Fehler beim Resume des Betriebssystems sein. Bei mir kamen z.b. im dmesg nur diese Meldungen, wenn ich den Dongle eingesteckt habe:

Abziehen des USB-Dongles:

[759687.061789] usb 1-7.4: USB disconnect, device number 47

Wieder dranstecken:

[759691.418316] usb 1-7.3: new full-speed USB device number 48 using xhci_hcd
[759691.623795] usb 1-7.3: Duplicate descriptor for config 1 interface 1 altsetting 5, skipping
[759691.639775] usb 1-7.3: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
[759691.639780] usb 1-7.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[759691.639782] usb 1-7.3: Product: USB2.0-BT
[759691.656175] Bluetooth: hci0: CSR: Setting up dongle with HCI ver=9 rev=0001
[759691.656179] Bluetooth: hci0: LMP ver=9 subver=0001; manufacturer=2279
[759691.656182] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds and force-suspending once…
[759691.656184] Bluetooth: hci0: CSR: Couldn’t suspend the device for our Barrot 8041a02 receive-issue workaround
[759691.656189] Bluetooth: hci0: HCI Delete Stored Link Key command is advertised, but not supported.
[759691.656192] Bluetooth: hci0: HCI Read Default Erroneous Data Reporting command is advertised, but not supported.
[759691.656199] Bluetooth: hci0: HCI Set Event Filter command not supported.
[759692.209297] Bluetooth: MGMT ver 1.23

Die Lichter am BT Dongle gingen sofort wieder aus und auch die BT Geräte meldeten sich natürlich nicht. Hintergrund war einfach, daß dem BT Dongle beim Suspend gesagt wurde, daß er mal runterfahren soll und das hat sich der Chip auf dem Dongle doch glatt im Stromlosmodus gemerkt 🙂  Würde man so nicht erwarten, bei etwas was man in den USB Port steckt, oder?

Mit den Kommandos:

$ sudo bluetoothctl power on ; sudo systemctl restart bluetooth

sagt man der BT Hardware, sie soll den BT Controller einschalten und vorsichtshalber bringen wir im Bluetoothstack noch mal alles auf „normal“ 😉

Und dann kommt auch bei Euch vielleicht wieder derartige Zeilen:

[759877.166735] input: Soundcore A1 (AVRCP) as /devices/virtual/input/input20
[759932.072472] input: Soundcore A1 (AVRCP) as /devices/virtual/input/input21

Gamescope geht auch ohne Steam ;)

Am Dienstag hatten wir „Gamescope“ im Fokus bei Linux am Dienstag, eine Anwendung, die uralte Spiele besser auf moderner Hardware macht, gezeigt an WinQuake von 1997.

Gamescope geht auch ohne Steam 😉

Nicht, daß es nicht bessere Games gäbe, aber wie könnte man das Können von gamescope besser zeigen, als an einem Softwarerenderer ohne HW Beschleunigung, der noch 320×240 als Auflösung erlaubt 😀

Wenn man das Spiel direkt startet, was mit Wine ohne Probleme funktioniert, wird erstmal eine Minuten lange Kaskade von Scrennresolutionwechseln durchführt, was sehr nervig ist, nur um dann Fullscreen zu haben. Das geht mit Gamescope deutlich einfacher und schneller. Das Programm stellt einen eigenen Wayland Compositor bereit, über den das Spiel läuft. So kann es trotz „Fullscreen-Request“ in einem Fenster laufen, wenn man das will.

Dieses Fenster kann beliebig groß oder klein sein.

Beispiel 1:

gamescope -b -H 1080 -W 1920 ./WINQUAKE.EXE

mit -b erreichen wir ein Borderlesswindow, -H und -W geben die maximale Auflösung des Screens an. Das Ergebnis seht Ihr hier:

640x480 auf FullHDBeispiel 2 zeigt dann das Scaling von 800×600 auf 192×1080:

gamescope -b -w 800 -h 600 -H 1080 -W 1920 ./WINQUAKE.EXE

mit -w und -h geben wir die Ausgangsgröße an und bekommen:

WInquake komplett im Fenster.Was bei Winquake nicht klappt, weil es Softwarerendering macht, aber bei andere Spielen könnte es was nutzen:

– Die Umwandlung in HDR

gamescope –hdr-enabled –hdr-itm-enabled -b -w 800 -h 600 -H 1080 -W 1920 spiel.exe

– Skalierung mit NIS oder FSR

gamescope -F nis -b -w 800 -h 600 -H 1080 -W 1920 spiel.exe

Statt „nis“ dann einfach fsr angeben.

Gamescope gibt es bei Fedora und wahrscheinlich allen Major Distros im normalen Repo.

NVRM: gpuHandleSanityCheckRegReadError_GM107

Wenn Ihr mal so einen Fehler bei einer NVIDIA Karte:

… 1 Millionen Zeilen davor…
Dec 27 12:28:45 eve kernel: NVRM: gpuHandleSanityCheckRegReadError_GM107: Possible bad register read: addr: 0x110100, regvalue: 0xbadf5620, error code: Unknown SYS_PRI_ERROR_CODE
Dec 27 12:28:45 eve kernel: NVRM: gpuHandleSanityCheckRegReadError_GM107: Possible bad register read: addr: 0x110100, regvalue: 0xbadf5620, error code: Unknown SYS_PRI_ERROR_CODE
… und noch ein paar mal danach…

im Massen, und ich meine wie in „Sand-am-Meer“ oder „Sterne im All“ im Log seht und Euer Desktop nicht laden will, dann habt Ihr vermutlich ein PCI-Powerproblem an der Grafikkarte. Die GPU Kann dann nicht initialisiert werden und der Treiber wirft dann mit solchen Fehlern um sich und ich meine echt eine 7 stellige Zahl an Zeilen.

Ich habe gestern neues RAM in den PC eingesetzt und danach gabs keine Bootprobleme. Aber um das einsetzen zu können, mußten erst mal Stecker gezogen und Sache gereinigt werden:

Alle Jahre wieder…

Dabei „könnte“ es zu einem Steckerproblem gekommen sein, deswegen nicht mehr genug Saft an der Graka an kam.

Mein Ansatz war, weil der PC ja ansonsten noch lief, sonst wäre ich nicht an den Fehler gekommen, mal das Netzteil prüfen, gucken was passiert, wenn eine andere Graka drin ist usw.. Dafür mußten alle Stecker vom Netzteil ab, dann wurde auf Netzteil Kurzschluss gelauscht ( das könnte knistern ) und dann wurde alles wieder zusammen gebaut und nach und nach angeschlossen, um die defekte Komponente zu finden.

Klingt gut, so steht es im 1×1 der PC Reparatur, aber da bis auf das Bild vorher alles da war ohne rumzuzicken, lag das Augenmerk natürlich auf der Graka, auch wenn wirklich alle Stecker vom Netzteil ab waren, und was soll ich Euch sagen.. er bootete, als wenn nie was gewesen wäre. Vielleicht ist das auch nur die Ruhe vor dem Sturm und ich brauche bald ein neues Netzteil. Ihr werdet es erfahren.

Nachtrag: 31.12.2025

Neben den „Verkabelungsproblemen“ kam noch ein anderer Faktor hinzu. Das Alte RAM hatte „Aussetzer“, spricht, es war entweder inkonsequent defekt, oder mit Spannung unterversorgt, was bei RAM Bausteinen schon mal passieren kann, wenn die Stromversorgung des Mainboards knapp ist. Deswegen kann man im BIOS den Rambänken mehr Spannung geben, was zu mehr Leistung führt und die „Aussetzer“, die meist einen Reset auslösen, minimieren. So war das bei meinem alten RAM auch. 1.430V auf dem DDR4-3200 Ramriegel war im Bios eingestellt, womit die „Aussetzer“ auf wenige Tage im Jahr beschränkt waren. Die „Aussetzer“ waren auch ein Grund für neues Ram 😉

Wenn man vergißt das wieder auf Standard zu setzen, dann bekommen die neuen, dickeren RAM Streifen zu viel Energie und können zu a) mehr Stromverbrauch führen und b) selbst wieder Aussetzer auslösen. Und das ist dann auch passiert. Seit die Spannung im Bios auf Normal zurückgesetzt wurde, läuft der Rechner mit dem neuen Ram wieder zuverlässig. Ob die Resets jetzt auch aufgehört haben, kann nur die Zukunft zeigen.