mesa problem

dragan · 2024-01-02 19:07:07

seth wrote:

As pointed out, "nvidia_drm.fbdev=1" still has some issues (you seem to be hitting them) and is NOT required to avoid the simpledrm device

Did you mean that we can skip nvidia_drm.fbdev=1 and just set the nvidia_drm.modeset=1 in the kernel command line?

(btw. I'm having the same issues as OP, I was just late to realize, my tty consoles are not showing at all, I removed all xf86-video-*, no errors in the logs that I could spot)

seth · 2024-01-02 20:36:34

@gugah, yes: https://archlinux.org/packages/extra/x8 … deo-intel/
The question what drivers (and by inference mesa) version you use hinges on the hardware, in doubt open a new thread (since "fix my setup" is off topic here) and post your xorg log there.

@questionask, you don't need nor want xf86-video-vesa, you don't have to do anything else but I do not expect it to fix your very client specific problem.
We'll /need/ a backtrace from keepassx to gage what's going on there.

@dragan, yes. "nvidia_drm.modeset=1" is (for now) enough to block the simpledrm device. The fbdev feature is new and perhaps done a bit hasty because of the general simpledrm situation - and apparently not bug free, so w/ the described symptoms, I'd revert that and rely on just completely blocking the simpledrm device for now (and o/c test whether the current/new problems go away w/ the fbdev support)

Lone_Wolf · 2024-01-03 12:42:02

Ignore please

Last edited by Lone_Wolf (2024-01-03 12:43:38)

questionask · 2024-01-03 18:55:44

seth wrote:

@questionask, you don't need nor want xf86-video-vesa, you don't have to do anything else but I do not expect it to fix your very client specific problem.
We'll /need/ a backtrace from keepassx to gage what's going on there.

I removed xf86-video-vesa and updated my system, and keepassxc runs now. I don't know what caused the problem.

seth · 2024-01-03 20:54:47

mesa 23.3.2-2 fixed the swrast bug by reverting the offending upstream commit (upstream has meanwhile reverted, too) so if you got hit by that, this is implicitly fixed.
The remaining question (for you) would be why you're running into this at all or, since the swrast error seems to have been triggered from the outside, whether the bug spilled into other places of mesa as well.
A coredump from the issue might in this case help the mesa developers to better understand the actual problem.

questionask · 2024-01-04 07:12:20

@seth: I would be happy to provide a coredump to help the mesa developers, but how can I get one about an issue a few days ago?

rwprime · 2024-01-04 08:14:13

3:12 AM 1-4-24 Still Mesa problems. I updated a brand new install of Arch/Openbox/Tint2, rebooted, ran Kmahjongg and got the following:
kmahjongg Enter
MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
glx: failed to create drisw screen
failed to load driver: zink

Hope that helps the people working on it.

Lone_Wolf · 2024-01-04 08:34:03

ZINK requires a working vulkan driver (can be swrast) .

Post your xorg log and the output of pacman -Qs vulkan .

seth · 2024-01-04 08:34:20

@questionask, I linked you https://wiki.archlinux.org/title/Core_d … _core_dump a couple of times
Coredumps are typically preserved, check "coredumpctl"

@rwprime, that has probably nothing to do w/ this thread
You're for some reason using OpenGL over vulkan but don't have a usable vulkan installation.
https://wiki.archlinux.org/title/OpenGL … kan_(Zink)

Please open a new thread and post your xorg log, system journal, "glxinfo -B" (though it's probably just gonna yell an error), "printenv" and "vulkaninfo" there.

questionask · 2024-01-04 09:11:41

@seth: Sorry. I get "No coredumps found." for keep

thonker · 2024-01-09 01:11:24

archsoft wrote:

Solved and successfully running mesa 1:23.3.2-1 on Thinkpad T480 with i5-8250U CPU (CPU Gen 8, GPU Gen 9).
I switched Xorg driver from "intel" to "modesetting". However, the wrong AccelMethod gave me more segfaults.

Interestingly, I also run T480 and arch, I tried a lot of variants for the whole graphics stack and vaapi, GuC on/off, fastboot, modesetting/intel (xf86), mesa-dri direct or ddx, for vaapi libva and intel, tried glamour accel and iris. Basically a lot of mixing.

For some reason, after update I notice +1.5/2W on my video decoding. I distinctively remember my mpv sitting around 3-4W while locally streaming from NFS a tv series.

I tried downgrading everything to the same as it was (sadly didn't to a snapshot or anything), downgraded kernel too, but I don't notice any better battery life sadly. No idea what went wrong.. Even reinstalled Arch.

Have you noticed any battery life changes on your machine? How much do you average when watching a local mpv video, x264 or x265 with vaapi accel? Mine is between 5W and 6.5W now. Used to be 3-4W.

When browsing the web with firefox I used to get around 4W, now it's more like 4.5W-5W.

When watching youtube, used to get around 8W, now it's about 10.5W.

Generally whatever is graphical Xorg seems to be more active, I noticed it consuming about 5% more cpu. Pretty weird..

And I run tlp and undervolt, throttled for thinkpad machines cpu control and generally optimized the laptop to the best of my ability.

How's your power consumption? (typically upower or powertop will show you the drain on battery). I'd be really appreciative if you could measure it and we can compare our machines.

raphaelabb · 2024-01-11 14:52:11

seth wrote:

downgrading is the only option
No, it's not.
Block the simpledrm device and this isn't about "fiddling with grub" - you want to have KMS enabled anyway (and doing so in the kernel commandline will let the kernel know that you're not interested in the simpledrm device)
Downgrading/pinning a package in isolation will definitively get you in trouble sooner or later on a rolling release. It's the worst possible approach here.

Well, I understand downgrading may be problematic but it is not that bad in that case. Downgraded the package, did not update the system a few days (since the issue concerned a lot of people using nvidia, mesa devs did not take long to correct) and then updated the package to the corrected version. I did not have time to mess around with kernel parameters. Was I wrong?

seth · 2024-01-11 14:57:48

Yes.
1. "you want to have KMS enabled anyway"
2. "did not have time to mess around with kernel parameters" - what would have taken you certainly a grand total of 30 seconds; I see.
3. "sooner or later" playing russian roulette will put a bullet into your head. Itr wasn't a smart idea because you got away with it on the first round.

raphaelabb · 2024-01-19 18:08:19

seth wrote:

3. "sooner or later" playing russian roulette will put a bullet into your head. Itr wasn't a smart idea because you got away with it on the first round.

I've been doing that for years with hplip (waiting for the aur hplip-plugin update), still waiting for the bullet in my head.

seth · 2024-01-19 20:46:27

seth originally wrote:

Downgrading/pinning a package in isolation will definitively get you in trouble sooner or later on a rolling release.

Not sure whether you missed it, but I addressed your DM about your/the specific hplip situation in a necrobump to your related thread: https://bbs.archlinux.org/viewtopic.php … 8#p2143628
This is very much case-by-case and details matter.

SneakyLittleman · 2024-02-13 17:56:32

Necroposting.
Updating to mesa 24 also broke my i915 (4600 igpu)/nouveau/GDM/Wayland setup today.
No clear error message in Xorg.0.log.
Still investigating.

WorMzy · 2024-02-13 18:45:20

SneakyLittleman wrote:

Necroposting.

Don't do that.

https://wiki.archlinux.org/title/Genera … bumping%22

Closing.

Arch Linux

#76 2024-01-02 19:07:07

Re: mesa problem

#77 2024-01-02 20:36:34

Re: mesa problem

#78 2024-01-03 12:42:02

Re: mesa problem

#79 2024-01-03 18:55:44

Re: mesa problem

#80 2024-01-03 20:54:47

Re: mesa problem

#81 2024-01-04 07:12:20

Re: mesa problem

#82 2024-01-04 08:14:13

Re: mesa problem

#83 2024-01-04 08:34:03

Re: mesa problem

#84 2024-01-04 08:34:20

Re: mesa problem

#85 2024-01-04 09:11:41

Re: mesa problem

#86 2024-01-09 01:11:24

Re: mesa problem

#87 2024-01-11 14:52:11

Re: mesa problem

#88 2024-01-11 14:57:48

Re: mesa problem

#89 2024-01-19 18:08:19

Re: mesa problem

#90 2024-01-19 20:46:27

Re: mesa problem

#91 2024-02-13 17:56:32

Re: mesa problem

#92 2024-02-13 18:45:20

Re: mesa problem

Board footer