You are not logged in.
@cgm999, remove that package - you've been running on software emulation so far…
@itsspelled*llama* , yes, looks like a generic bug that prefers zink over llvmpipe, so whenever that would have been called (vmware, the unintentional software rasterizer or apparently nouveau at least on hybrid systems) you got hit with this.
Last edited by seth (2025-05-26 15:36:39)
Offline
@seth:
So if is not going to use the intel driver,what pkg for video should I have in my case with just Intel vga card ?
Offline
On that old of a system, you *can* use the intel ddx, but you'll likely need mesa-amber to make it work right. You're usually better off with the modesetting ddx that comes with xorg server.
https://wiki.archlinux.org/title/Intel_graphics
Last edited by Scimmia (2025-05-26 16:10:16)
Offline
I tried to remove the pkg (-intel) and reinstalled mesa , no change, X does not start, I need to killall -9 Xorg from some other session
I downgrade mesa to prev 1:25.0.5-1 as a workaround..
Last edited by cgm999 (2025-05-26 17:04:52)
Offline
@itsspelled*llama*
, yes, looks like a generic bug that prefers zink over llvmpipe, so whenever that would have been called (vmware, the unintentional software rasterizer or apparently nouveau at least on hybrid systems) you got hit with this.
Thanks! \o/ I will wait for a patch confirmation and report when I can. Hopefully this fixes the many graphical glitches/bugs I have in the meantime. ^^ (Also, to confirm, I have nouveau on the affected computer)
(I am French, so it's spelled lama for us )
Offline
Interesting, what's the english translation of "noob"?
@cgm999, Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General
(if you have a config file explicitly referencing the intel driver it'll fail to start when removing that package but keeping the config)
Offline
In Xorg.log there was nothing usefull. I even compared with previous mesa..
What did help was strace , (strace -f -o /tmp/.strace.x startx) . and from some root terminal I started before "sleep 10;killall -9 Xorg" .
looking in the strace log I found a leftover in /usr/share/drirc.d/ , 01-no-iris.conf or something like that,which had inside i915.so.
I moved that to some other folder , and now startx works with latest mesa , victory !!
Hope this helps others, at least as a general method
Offline
I haven't seen my own post in a while, I was a bit busy for the past few days. I "solved" (avoided is more fitting) my original problem the same day I posted it by using a live installation of arch to copy the files into a different hard drive and than proceeding to reinstall arch. I'm sorry for not marking the thread as solved earlier (I just forgot). Despite that, I'm glad that other people found this thread useful (and though I can't check whether your tips could've helped me or not, I will keep the suggestions you gave to others in mind, in case I need them).
P.S. Should I mark this thread as solved? I'm not sure because it seems like a few people are still struggling with a similar issue.
Offline
Did you (already) update that re-installation to the buggy mesa version?
Offline
Today I noticed that the Arch Linux repository had been updated with mesa version 25.1.1-2. This version, as with Version 25.1.1-1, locks up my hybrid- graphics equipped computer. I have another computer that does not have hybrid graphics. It does not lock up with either mesa Version 25.1.1-1 or 25.1.1-2. Neither computer is running a virtual machine.
By lock up, I mean that after GRUB has finished, the Linux boot process continues until applicaton 'org.gnome.Shell.desktop' fails to register. At this stage the sreen goes black with an unblinking cursor at top left. If I wait about 90 seconds the cursor starts to blink and I can press Ctrl + Alt + F3 to reach the Linux command prompt and log in.
Details of both computers are:
Hybrid graphics Lenovo P16v
$ glxinfo -B | grep "OpenGL version string"
OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.0.5-arch1.1
$ inxi -G
Graphics:
Device-1: Intel Meteor Lake-P [Intel Graphics] driver: i915 v: kernel
Device-2: NVIDIA AD107GLM [RTX 500 Ada Generation Laptop GPU]
driver: nouveau v: kernel
Device-3: Syntek Integrated Camera driver: uvcvideo type: USB
Display: wayland server: Xwayland v: 24.1.6 compositor: gnome-shell
v: 48.2 driver: X: loaded: modesetting gpu: i915
resolution: no compositor data resolution: 3840x2400
API: EGL v: 1.5 drivers: iris,nouveau,swrast
platforms: gbm,wayland,x11,surfaceless,device
API: OpenGL v: 4.6 compat-v: 4.3 vendor: intel mesa v: 25.0.5-arch1.1
renderer: Mesa Intel Graphics (MTL)
Info: Tools: api: eglinfo,glxinfo x11: xprop
No hybrid graphics Lenovo T580
$ glxinfo -B | grep "OpenGL version string"
OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.1.1-arch1.2
$ inxi -G
Graphics:
Device-1: Intel UHD Graphics 620 driver: i915 v: kernel
Device-2: Azurewave Integrated Camera driver: uvcvideo type: USB
Display: wayland server: Xwayland v: 24.1.6 compositor: gnome-shell
v: 48.2 driver: gpu: i915 resolution: no compositor data
resolution: 3840x2160
API: EGL v: 1.5 drivers: iris,swrast
platforms: gbm,wayland,x11,surfaceless,device
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 25.1.1-arch1.2
renderer: Mesa Intel UHD Graphics 620 (KBL GT2)
Info: Tools: api: eglinfo,glxinfo x11: xprop
This link https://gitlab.archlinux.org/archlinux/ … ote_272975 says the bug has been fixed. I wonder if that fix applies only to the vm problem. Has anybody found that mesa Version 25.1.1-2 has fixed the problem for hybrid graphics computers?
Offline
Nope, still not fixed even on normal Nvidia platforms, i just formatted and installed again using archinstall, same problem, waiting with top left cursor, i wonder why this happens.
By the way after downgrading to 1.25.0-5 and updating to normal packages doesnt affect and usable again, the problem happens me on after the install, cannot use the system, i hate this type of things when developers arent testing the updates fully for bugs.
Offline
*Normal nvidia platform = desktop computers
Tested on Acer Nitro 5 AN515-58 fresh install Arch Linux, still same problem, hybrid and nvidia only, same problem, stuck at top left cursor
Offline
Please post your complete system journal for the affected boot, eg.
sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st
for the previous ("-1") one.
Offline
@seth I'm assuming that you were asking me for a journal dump of the installation that failed using mesa-1:25.1.1-2.
It's here: http://0x0.st/83Dz.txt.
I noticed a ZINK error in there:
11:20:22 P16v org.gnome.Shell.desktop[882]: MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
.
Offline
Yup and that seems like the problem hasn't actually been addressed?
Edit: https://gitlab.archlinux.org/archlinux/ … ote_274215
And fwwi, you might want to install nvidia(-open) and nvidia-utils and add "nvidia_drm.modeset=1" to teh kernel parameters, sidesetepping nouveau, avoiding the useless simpledrm device and for all we can tell there's no problem w/ intel.
Doesn't help w/ virtualbox, though.
Last edited by seth (2025-05-31 08:05:35)
Offline
The arch bug has been explicitly narrowed to virtio and the upstream patch only works around that w/o adressing the offending mesa commit itself.
Does
export MESA_LOADER_DRIVER_OVERRIDE=llvmpipe
somewhere in /etc/profile* (or your preferred way to export global environment variables) work around this?
Offline
@seth adding the variable to /etc/environment solved the issue, at least for me. Thank you!
Offline
Great, just as a cross-test, does "export LIBGL_KOPPER_DISABLE=true" *instead* of MESA_LOADER_DRIVER_OVERRIDE fix work around it?
Offline
The arch bug has been explicitly narrowed to virtio and the upstream patch only works around that w/o adressing the offending mesa commit itself.
Hello,
Thanks for the followup!
However, am I correct in my understanding that this doesn't solve the issue for nouveau users with recent nvidia cards?
I saw that someone posted another ticket: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13317
I guess I could install the nvidia drivers, but it's a bit sad to have to use those, especially since it involves tinkering and may break some other stuff. (Alternatively, I could disable the card, but if I need it in the future, I'd rather have a working solution to the issue)
Again, thanks to the people helping around and maintaining everything. <3
PS:
Interesting, what's the english translation of "noob"?
Clearly "bleu" ^^
Offline
The offending patch wasn't reverted and for all accounts, the kopper patch (which is in the repo mesa version) doesn't fix the situation for nouveau.
That's why someone™ filed that other bug.
In the meantime, explicitly selecting llvm should work around the situation, I don't expect LIBGL_KOPPER_DISABLE=true to do anything, but it would be nice to for someone else™ to test it
Offline
For affected nouveau users:
Try "export NOUVEAU_USE_ZINK=0
Also:
Does any of you (affected nouveau users) use X11? Do you have xf86-video-nouveau installed?
Edit: also
pacman -Qs vulkan
Last edited by seth (2025-06-06 19:49:06)
Offline
@seth LIBGL_KOPPER_DISABLE=true doesn't cause the freeze for me, but instead leads to this error
X.Org X Server 1.21.1.16
X Protocol Version 11, Revision 0
Current Operating System: Linux 6.14.9-arch1-1 #1 SMP PREEMPT_DYNAMIC x86_64
Current version of pixman: 0.46.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/tocic/.local/share/xorg/Xorg.0.log"
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
(EE)
(EE) Backtrace:
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 0: /usr/lib/Xorg (?+0x0) [0x55b8b4b38f7c]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 1: /usr/lib/libc.so.6 (?+0x0) [0x7f1d32b30ef0]
(EE)
(EE) Segmentation fault at address 0x0
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/home/tocic/.local/share/xorg/Xorg.0.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
Offline
For affected nouveau users:
Try "export NOUVEAU_USE_ZINK=0Also:
Does any of you (affected nouveau users) use X11? Do you have xf86-video-nouveau installed?Edit: also
pacman -Qs vulkan
Will check, try and report back on Tuesday, thanks!
(Just to confirm: for the export try, we should update mesa, export (is there a generic place where we have to export?), then reboot?)
Offline
/etc/profile or a(n executable script in) /etc/profile.d gets sourced pretty much everywhere, for details see https://wiki.archlinux.org/title/Environment_variable
@tocic you end up w/ zink regardless of kopper.
Do you struggle w/ nouveau or vmware?
pacman -Qs vulkan
and for nouveau please also try to "export NOUVEAU_USE_ZINK=0"
Offline