Mx 19.2 - Switchable Graphics am Laptop funktioniert nicht

grabeskuehle

Cadet 4th Year
Registriert
Okt. 2014
Beiträge
127
Hallo Leute!
Hoffe der Titel ist aussagekräftig, nun zum Problem:

Ich habe einen HP Envy M6 mit integriertem (Intel HD 4000) und dediziertem (Radeon HD 7670M) Grafikchip mit Mx Linux 19.2 am laufen.
Logischerweise möchte ich für das gelegentliche Spielchen zwischendurch die Radeon verwenden, allerdings macht mir da anscheinend kms (soweit ich das einschätzen kann) einen Strich durch die Rechnung.
Der Desktop läuft soweit ich weiß noch auf XServer und nicht Wayland.

Wenn ich xrandr --listproviders ausführe wird mir nur ein Provider angezeigt und das ist die Intel Grafik, vom Amd Chip weit und breit keine spur.
Bei lspci und inxi -v3 wird der Amd Chip allerdings aufgeführt, bei inxi steht allerdings bei Treiber n/a.
x11 läuft auf modeset.

Anzumerken ist noch das bei der vorherigen Version von Mx (müsste Mx 18 gewesen sein) noch beide Gpus in xrandr als provider angezeigt wurden.
Allerdings hatte ich da schon Probleme das switching mit Prime oder vgaswitcheroo hinzubekommen.

Habe jetzt schon alles mögliche durchprobiert, angefangen vom Treiber deinstallieren und re-installieren, komplett neu aufsetzen, probieren mit den Dateien in etc/X11/xorg.conf.d/ rumspielen etc. etc.

Das erzwingen der Amd Gpu über die Dateien in etc/X11/xorg.conf.d/ funktioniert nicht, eine xorg.conf scheint es wegen kms nicht mehr zu geben.

Hier mal was das Terminal ausspuckt:

Providers: number : 1
Provider 0: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 4 associated providers: 0 name:modesetting

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Thames [Radeon HD 7500M/7600M Series]

System: Host: wakeymx Kernel: 4.19.0-9-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0
parameters: BOOT_IMAGE=/boot/vmlinuz-4.19.0-9-amd64
root=UUID=2bcbfc6f-7bb8-4c04-8c3e-4296bee2c566 ro quiet splash
Desktop: Xfce 4.14.2 tk: Gtk 3.24.5 info: xfce4-panel wm: xfwm4 dm: LightDM 1.26.0
Distro: MX-19.2_x64 patito feo May 31 2020 base: Debian GNU/Linux 10 (buster)
Machine: Type: Laptop System: Hewlett-Packard product: HP ENVY m6 Notebook PC
v: 088A120000305910000620100 serial: <filter> Chassis: type: 10 serial: <filter>
Mobo: Hewlett-Packard model: 18A5 v: 73.50 serial: <filter> UEFI: Insyde v: F.25
date: 01/21/2013
Battery: ID-1: BAT1 charge: 41.9 Wh condition: 51.2/51.2 Wh (100%) volts: 11.5/11.1
model: 13-24 MO06062 type: Li-ion serial: <filter> status: Discharging
CPU: Topology: Dual Core model: Intel Core i5-3230M bits: 64 type: MT MCP arch: Ivy Bridge
family: 6 model-id: 3A (58) stepping: 9 microcode: 21 L2 cache: 3072 KiB
flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 20753
Speed: 1197 MHz min/max: 1200/2600 MHz Core speeds (MHz): 1: 1198 2: 1197 3: 1198
4: 1197
Vulnerabilities: Type: itlb_multihit status: KVM: Vulnerable
Type: l1tf mitigation: PTE Inversion
Type: mds mitigation: Clear CPU buffers; SMT vulnerable
Type: meltdown mitigation: PTI
Type: spec_store_bypass
mitigation: Speculative Store Bypass disabled via prctl and seccomp
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW,
STIBP: conditional, RSB filling
Type: srbds status: Vulnerable: No microcode
Type: tsx_async_abort status: Not affected
Graphics: Device-1: Intel 3rd Gen Core processor Graphics vendor: Hewlett-Packard driver: i915
v: kernel bus ID: 00:02.0 chip ID: 8086:0166
Device-2: AMD Thames [Radeon HD 7500M/7600M Series] vendor: Hewlett-Packard
driver: N/A bus ID: 01:00.0 chip ID: 1002:6840
Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa
resolution: 1366x768~60Hz
OpenGL: renderer: Mesa DRI Intel Ivybridge Mobile v: 4.2 Mesa 18.3.6 compat-v: 3.0
direct render: Yes
Audio: Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Hewlett-Packard
driver: snd_hda_intel v: kernel bus ID: 00:1b.0 chip ID: 8086:1e20
Sound Server: ALSA v: k4.19.0-9-amd64
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
vendor: Hewlett-Packard driver: r8169 v: kernel port: 2000 bus ID: 07:00.2
chip ID: 10ec:8168
IF: eth0 state: down mac: <filter>
Device-2: Intel Centrino Wireless-N 2230 driver: iwlwifi v: kernel port: 2000
bus ID: 08:00.0 chip ID: 8086:0887
IF: wlan0 state: up mac: <filter>
Drives: Local Storage: total: 111.79 GiB used: 7.83 GiB (7.0%)
ID-1: /dev/sda vendor: Samsung model: SSD 750 EVO 120GB size: 111.79 GiB block size:
physical: 512 B logical: 512 B speed: 6.0 Gb/s serial: <filter> rev: 1B6Q scheme: GPT
RAID: Hardware-1: Intel 82801 Mobile SATA Controller [RAID mode] driver: ahci v: 3.0
port: 4060 bus ID: 00:1f.2 chip ID: 8086.282a rev: 04
Partition: ID-1: / raw size: 109.51 GiB size: 107.29 GiB (97.97%) used: 7.83 GiB (7.3%) fs: ext4
dev: /dev/sda2
ID-2: swap-1 size: 2.00 GiB used: 0 KiB (0.0%) fs: swap swappiness: 15 (default 60)
cache pressure: 100 (default) dev: /dev/sda3
Sensors: System Temperatures: cpu: 62.0 C mobo: N/A
Fan Speeds (RPM): N/A
Repos: No active apt repos in: /etc/apt/sources.list
Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
1: deb http://deb.debian.org/debian buster-updates main contrib non-free
Active apt repos in: /etc/apt/sources.list.d/debian.list
1: deb http://deb.debian.org/debian buster main contrib non-free
2: deb http://deb.debian.org/debian-security buster/updates main contrib non-free
Active apt repos in: /etc/apt/sources.list.d/mx.list
1: deb http://mirror.digitalnova.at/mxlinux/packages/mx/repo/ buster main non-free
No active apt repos in: /etc/apt/sources.list.d/various.list
Info: Processes: 205 Uptime: 28m Memory: 7.69 GiB used: 578.1 MiB (7.3%) Init: SysVinit
v: 2.93 runlevel: 5 default: 5 Compilers: gcc: 8.3.0 alt: 8 Shell: bash v: 5.0.3
running in: quick-system-in inxi: 3.0.36

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Thames [Radeon HD 7500M/7600M Series] [1002:6840] (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Radeon HD 7670M [103c:18a5]
Flags: fast devsel, IRQ 7
Memory at 40000000 (64-bit, prefetchable) [disabled] [size=256M]
Memory at 60000000 (64-bit, non-prefetchable) [disabled] [size=128K]
I/O ports at 3000 [disabled]
Expansion ROM at 60020000 [disabled] [size=128K]

Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
Capabilities: [150] Advanced Error Reporting
Kernel modules: radeon

dmesg |grep radeon
[ 1.973162] [drm:radeon_init [radeon]] ERROR No UMS support in radeon module!
[ 5.068793] [drm:radeon_init [radeon]] ERROR No UMS support in radeon module!
Spuckt den gleichen Fehler aus wie da, wo ich die Radeon in den xorg.conf.d Files erzwingen wollte.
Ergibt allerdings keinen Sinn für mich, da doch beim Booten inzwischen KMS verwendet wird!?

Die switching Funktion mit Prime oder vgaswitcheroo ist mir eh schon egal, von mir aus soll die Amd Gpu halt dauerhaft aktiviert bleiben, aber ich bin mit meinem Latein am Ende.

Erfahrungen? Ideen?

Liebe Grüße, Wakey


Edit: Das Bios bietet leider keine Einstellungen bezüglich der Grafikchips.
 

Anhänge

  • dmesg.txt
    63,9 KB · Aufrufe: 309
  • Xorg.0.log.txt
    39,8 KB · Aufrufe: 300
Zuletzt bearbeitet: (Nachtrag)
Kannst du das nicht bios-seitig steuern, dass die dedizierte Grafik immer aktiv ist? Einige Laptops bieten diese Einstellung (z.B. mein P50). Anzumerken ist hier, dass die externen Anschlüsse in meinem Fall über die dedizierte Grafikkarte laufen. Über die Intel HD bekomme ich auf dem HDMI kein Bild, soweit ich das verstanden habe.

Bei einigen Geräten war das bei Windows auch so, dass über die Energiesparprofile gesteuert wurde. Einige Laptop funktionieren dann wiederum nur mit Stromkabel mit der dedizierten Grafikkarte
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: grabeskuehle
Den Gedanken hatte ich auch schon, leider bietet das UEFI keinerlei Einstellung diesbezüglich.
Ob das Ladegerät dran ist macht keinen Unterschied soweit ich das feststellen konnte.
 
Zuletzt bearbeitet:
  • Hast du eine spezial MX Version installiert ("AHS"?) - lt distrowatch verwenden beide normal 4.19 es sei denn es wurde angepasst
  • unter /dev/dri/ sollten mehrere cards auftauchen (hier noch 18er Version testen) - hier hakt es vermutlich
  • Konfigurationsdateien von MX 18 und MX 19 vergleichen : bei xorg, vainfo, glxgears zB via
DRI_PRIME=1 GALLIUM_HUD=fps glxgears und DRI_PRIME=1 vainfo
DRI_PRIME funktioniert bei mehreren card einträgen und steuert die zusatz-gpu an
  • Logdatei von xorg fehlt
  • Kernel-Bootlog fehlt (dmesg)
  • steht der AMD Treiber irgendwie auf einer Blacklist - kernel cmdline prüfen

Code:
sudo lspci -v -nn -s 01:00.0
zeigt zB "Kernel driver in use:" an für die AMD Grafikkarte (-s parameter)

- Bug bei MX Linux anlegen - Stichwort "Regression" / Forum / Paketbetreuer dort kontaktieren

Alte MX Downloadlinks unter distrowatch funktionieren für MX18.3
 
  • Gefällt mir
Reaktionen: grabeskuehle
lokon schrieb:
Hast du eine spezial MX Version installiert ("AHS"?) - lt distrowatch verwenden beide normal 4.19 es sei denn es wurde angepasst
Soweit ich weiß die ganz normale aktuelle x64 version von derren Website https://mxlinux.org/download-links/
Möglich das mir beim Downloaden ein Fehler passiert ist.
Allerdings war die Installation vor dem jetztigen neu aufsetzen schon 19.2 und da ganz sicher die "nicht AHS" Version.


lokon schrieb:
unter /dev/dri/ sollten mehrere cards auftauchen (hier noch 18er Version testen) - hier hakt es vermutlic
Hier wird nur nur eine angezeigt, card0.
Kann ich beim 18er auch eine LiveSession verwenden?


lokon schrieb:
  • Logdatei von xorg fehlt
  • Kernel-Bootlog fehlt (dmesg)
  • steht der AMD Treiber irgendwie auf einer Blacklist - kernel cmdline prüfen
Werden nachgereicht, siehe Hauptpost.
 
Eine 18er Livesession sollte gehen, weil die Treiber von Intel und AMD im Kernel integriert sind und nicht zusätzlich installiert werden müssen.
Ergänzung ()

cat /proc/cmdline für Kernel-Commandline

Beim Grub-Menü kannst du die Bootparameter - u.a. die Kernel-Commandline - editieren, ohne das die Änderungen gespeichert werden.

google meint: nomodeset entfernen, radeon.modeset=0 hinzufügen

Eventuell sind modulparameter über Dateien in /etc/modprobe.d eingebunden - nachsehen
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: grabeskuehle und Linuxfreakgraz
lokon schrieb:
Beim Grub-Menü kannst du die Bootparameter - u.a. die Kernel-Commandline - editieren, ohne das die Änderungen gespeichert werden.

google meint: nomodeset entfernen, radeon.modeset=0 hinzufügen
nomodeset war in jedem Fall nicht drin, radeon.modeset=0 hab ich versucht, hat leider nichts geändert.

lokon schrieb:
Eventuell sind modulparameter über Dateien in /etc/modprobe.d eingebunden - nachsehen
Hatte ich schon nachgeguckt und jetzt nochmal überprüft, nichts drin was irgendwie die Grafik beeinflussen sollte.

Hab jetzt die Livesession mit Mx 18.3 versucht und siehe da.... es funktioniert!
xrandr zeigt beide provider an, inxi -v3 zeigt auch an das der radeon treiber geladen wurde und DRI_PRIME=1 GALLIUM_HUD=fps glxgears hat auch einwandfrei funktioniert.

Vermutlich also wirklich ein Bug, werde den morgen reporten.
Sollte ich in der Zwischenzeit einfach auf 18.3 downgraden, oder können wir uns dort vielleicht nützliche Infos für die Lösung rausholen?
 
- Kernelversion - welche in 18.3 und 19.2

Im "einfachsten" Fall wurde:
  • im Kernel etwas verändert [1]
  • oder die Konfiguration ist anders [2]
  • MX Linux hat eigene Patches die abweichen [3]

  • Kernelversion von 19.2 in 18.3 ausprobieren [1]
  • Kernelkonfiguration prüfen ( zcat /proc/config.gz > kernelconf_geht/ICODE] jeweils, dann Ausgabe von [ICODE]diff -p kernelconf_geht kernelconf_fehler für Unterschiede = Punkt [2]
  • Kernel commandline vergleichen, Modulparameterverzeichnis
  • komplettes dmesg vergleichen/ansehen, nicht nur die Radeonzeilen (ohne grep)

Was ist der Output von dmesg beim hinzufügen der radeon cmdline ?
Was ist der Output von dmesg bei 18.3 ? [1]
Output von Xorg.log bei 18.3 ?


dein gepostetes dmesg oben hat eine normale cmdline
Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-9-amd64 root=UUID=2bcbfc6f-7bb8-4c04-8c3e-4296bee2c566 ro quiet splash

auch zu [1] / [3] : Vanilla Kernel installieren oder anderen Kernel (antix ? liquorix ? "mainline" ?) - keine Ahnung welche bei MX lauffähig sind

Man könnte mit anderen LiveCDs/USBStick von Debian und darauf basierend Ubuntu prüfen wie dort die Hardwareerkennung ist.

Output von glxinfo -B bzw. DRI_PRIME=1 glxinfo -B posten bzw prüfen ob die unterschiedlichen Treiber geladen sind. (intel i915<-> radeon) , mit lsmod prüfen ob module geladen sind

PS: Beim Uploaden von Logs die Dateinamen ändern, damit die MX Version erkennbar ist : dmesg_mx18_3.txt , dmesg_mx19_2_modcmdline.txt

PPS: [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.
steht in deiner dmesg -> gibt es ein Bios Update für den Laptop ?
Keine Ahnung ob das für dieses Problem eine Rolle spielt. (Taucht die Zeile im funktionierenden Fall auf? ...)
 
  • Gefällt mir
Reaktionen: Linuxfreakgraz
Habe nun eine erstaunlich einfache Lösung gefunden.
Der Radeon Treiber lies sich mit dem Befehl "sudo modprobe radeon modeset=1" im laufenden Betrieb nachladen, dann funktionieren auch PRIME und GALLIUM_hud.
Diesen Befehl habe ich dann in die Datei rc.local eingetragen und et voila, der Radeon Treiber startet nun beim hochfahren mit!
Auch in xrandr --listproviders wird die Radeon gleich nach dem hochfahren jetzt korrekt als zweiter Provider angezeigt.

Weiß zwar immer noch nicht was es mit dem "ERROR No UMS support in radeon module!" Fehler auf sich hat, aber zumindest funktioniert jetzt alles wie es soll.
Vielleicht hilft dieser Post ja irgendwann jemand anderem weiter :-)

PS: Google ist für solche Probleme wirklich ein schlechter Ratgeber.
Gerade nomodeset oder radeon.modeset=0 waren die verkehrten Befehle, womit sich X gar nicht mehr starten lies.
Bin Quasi nur durch Zufall durch rumprobieren auf die Lösung gekommen.
 
  • Gefällt mir
Reaktionen: Linuxfreakgraz
Zurück
Oben