[ISSUE] Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[ISSUE] Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

New issue by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434

Description:
### Is this a new report?

Yes

### System Info

Void 6.6.63_1 x86_64 GenuineIntel uptodate rFFFF

### Package(s) Affected

`corectrl-1.4.1_1`

### Does a report exist for this bug with the project's home (upstream) and/or another distro?

None Found. 

### Expected behaviour

No segmentation faults given a compatible ABI interface. 

### Actual behaviour

Since Mesa update https://github.com/void-linux/void-packages/commit/027f896d1e685149c377a72ea0ceddf7d48d7431 I'm getting segmentation faults with Corectrl, and noticed that `configure_args = -Ddri3=enabled` was removed with no apparent reason that I could find. This could impact further applications, and that missing argument may be unintentional. 

### Steps to reproduce

Update to Mesa 24.3.1 https://github.com/void-linux/void-packages/commit/027f896d1e685149c377a72ea0ceddf7d48d7431

Run Corectrl in a terminal

Amid other generic Qt5 error, notice the segmentation faul at the end:

`
[09-12-24 19:24:34.442][I] No translation found for locale en_US
[09-12-24 19:24:34.442][I] Using en_EN translation.
QSystemTrayIcon::setVisible: No Icon set
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
zsh: segmentation fault  corectrl
`

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529036340

Comment:
@SpidFightFR 

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529042306

Comment:
fwiw, that removal is not the reason things are segfaulting, as the [changelog](https://docs.mesa3d.org/relnotes/24.3.0.html) indicates that flag was removed:

> - meson: delete dri3 build option

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[SpidFightFR]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

New comment by SpidFightFR on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529046693

Comment:
> ### Is this a new report?
> 
> Yes
> 
> ### System Info
> 
> Void 6.6.63_1 x86_64 GenuineIntel uptodate rFFFF
> 
> ### Package(s) Affected
> 
> `corectrl-1.4.1_1`
> 
> ### Does a report exist for this bug with the project's home (upstream) and/or another distro?
> 
> None Found. 
> 
> ### Expected behaviour
> 
> No segmentation faults given a compatible ABI interface. 
> 
> ### Actual behaviour
> 
> Since Mesa update https://github.com/void-linux/void-packages/commit/027f896d1e685149c377a72ea0ceddf7d48d7431 I'm getting segmentation faults with Corectrl, and noticed that `configure_args = "-Ddri3=enabled"` was removed with no apparent reason that I could find. This could impact further applications if resulted in changes to the ABI interface, and that missing argument may be unintentional. 
> 
> ### Steps to reproduce
> 
> Update to Mesa 24.3.1 https://github.com/void-linux/void-packages/commit/027f896d1e685149c377a72ea0ceddf7d48d7431
> 
> Run Corectrl in a terminal
> 
> Amid other generic Qt5 error, notice the segmentation faul at the end:
> 
> `
> [09-12-24 19:24:34.442][I] No translation found for locale en_US
> [09-12-24 19:24:34.442][I] Using en_EN translation.
> QSystemTrayIcon::setVisible: No Icon set
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> zsh: segmentation fault  corectrl
> `

On 24.3.0, this argument was removed from the build options.

Either they re-added it in 24.3.1 (which i'll recheck) or it got replaced by another opt, or it is a bug within mesa itself. 

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529047516

Comment:
> fwiw, that removal is not the reason things are segfaulting, as the [changelog](https://docs.mesa3d.org/relnotes/24.3.0.html) indicates that flag was removed:
> 
> > * meson: delete dri3 build option

I of course meant "No reasons that I could find amond Void devs". Will be changing spelling soon. 

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529050456

Comment:
in fact, dri3 is now always enabled: https://gitlab.freedesktop.org/mesa/mesa/-/commit/8f6fca89aa1812b03da6d9f7fac3966955abc41e

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529054673

Comment:
Could be a bug in Mesa then, I am absolutely sure it was only Mesa to update, and I started my Void Box only a few minutes ago after keeping it off for 20+ hours. 

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[SpidFightFR]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

New comment by SpidFightFR on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529056880

Comment:
> > fwiw, that removal is not the reason things are segfaulting, as the [changelog](https://docs.mesa3d.org/relnotes/24.3.0.html) indicates that flag was removed:
> > > * meson: delete dri3 build option
> 
> I of course meant "No reasons that I could find amond Void devs". Will be changing spelling soon.

no worries, though i shared the same thoughts as you when i made the original PR for 24.3.0.

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529054673

Comment:
Could be a bug in Mesa then, I am absolutely sure it was only Mesa to update, and I started my Void Box only a few minutes ago after keeping it off for 20+ hours (No segmentation fauls before, and no relevant updates to Corectrl in weeks).
Other apps/binaries may be affected, in every case, if ABI changed, intentionally or not.

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[SpidFightFR]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

New comment by SpidFightFR on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529061184

Comment:
> Could be a bug in Mesa then, I am absolutely sure it was only Mesa to update, and I started my Void Box only a few minutes ago after keeping it off for 20+ hours (No segmentation fauls before, and no relevant updates to Corectrl in weeks). Other apps/binaries may be affected, in every case, if ABI changed, intentionally or not.

I'll keep an eye out on the different issues tab and stuff. just in case.

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529061286

Comment:
> > > fwiw, that removal is not the reason things are segfaulting, as the [changelog](https://docs.mesa3d.org/relnotes/24.3.0.html) indicates that flag was removed:
> > > > * meson: delete dri3 build option
> > 
> > 
> > I of course meant "No reasons that I could find amond Void devs". Will be changing spelling soon.
> 
> no worries, though i shared the same thoughts as you when i made the original PR for 24.3.0.

I just typed the issue very fast cause I'm in a hurry, and It may have sounded wrong. Thanks for your understanding. 

If we find other apps/binaries being segfaulted, it may be prudent to reverse Mesa though, knowing it can be a pain (Well, it's also a pain to downgrade so many packages, I'm getting a list right now)

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529047516

Comment:
> fwiw, that removal is not the reason things are segfaulting, as the [changelog](https://docs.mesa3d.org/relnotes/24.3.0.html) indicates that flag was removed:
> 
> > * meson: delete dri3 build option

I of course meant "No reasons that I could find among Void devs". Will be changing spelling soon. 

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[SpidFightFR]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

New comment by SpidFightFR on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529066577

Comment:
> > > > fwiw, that removal is not the reason things are segfaulting, as the [changelog](https://docs.mesa3d.org/relnotes/24.3.0.html) indicates that flag was removed:
> > > > > * meson: delete dri3 build option
> > > 
> > > 
> > > I of course meant "No reasons that I could find amond Void devs". Will be changing spelling soon.
> > 
> > 
> > no worries, though i shared the same thoughts as you when i made the original PR for 24.3.0.
> 
> I just typed the issue very fast cause I'm in a hurry, and It may have sounded wrong. Thanks for your understanding.
> 
> If we find other apps/binaries being segfaulted, it may be prudent to reverse Mesa though, knowing it can be a pain (Well, it's also a pain to downgrade so many packages, I'm getting a list right now)

that is okay really, the faster we identify problems, the better.
I do prefer the way you opened the issue, even if it may be a false positive, rather than letting an important bug pass through in production.

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[SpidFightFR]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

New comment by SpidFightFR on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529068580

Comment:
I'll update it on my production machine. and check what may happen.

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529108184

Comment:
STATUS UPDATE:

Just ran the following (Github is ignoring formatting)

`
sudo xdowngrade 
/var/cache/xbps/mesa-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-dri-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-dri-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-libgallium-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-libgallium-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-vulkan-overlay-layer-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-vulkan-overlay-layer-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-vulkan-radeon-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-vulkan-radeon-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libglapi-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libglapi-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libgbm-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libgbm-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libOSMesa-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libOSMesa-32bit-24.2.7_1.x86_64.xbps 
`
And...`Corectrl` was correctly launched with no segmentation fault errors. Running in userspace tray right now with no apparent problems, GPU fans were also correctly manipulated by the application. 

I'm guessing something happened with the ABI.

If we can't find other apps affected, I'll open an issue on Corectrl's repo. 

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529108184

Comment:
STATUS UPDATE:

Just ran the following (Github is ignoring formatting)

`
sudo xdowngrade 
/var/cache/xbps/mesa-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-dri-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-dri-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-libgallium-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-libgallium-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-vulkan-overlay-layer-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-vulkan-overlay-layer-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-vulkan-radeon-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-vulkan-radeon-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libglapi-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libglapi-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libgbm-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libgbm-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libOSMesa-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libOSMesa-32bit-24.2.7_1.x86_64.xbps 
`

And...`Corectrl` was correctly launched with no segmentation fault errors. Running in userspace tray right now with no apparent problems, GPU fans were also correctly manipulated by the application. 

I'm guessing something happened with the ABI.

If we can't find other apps affected, I'll open an issue on Corectrl's repo. 

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529108184

Comment:
STATUS UPDATE:

Just ran the following (Github is ignoring formatting)

`
sudo xdowngrade 
/var/cache/xbps/mesa-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-dri-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-dri-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-libgallium-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-libgallium-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-vulkan-overlay-layer-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-vulkan-overlay-layer-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-vulkan-radeon-24.2.7_1.x86_64.xbps 
/var/cache/xbps/mesa-vulkan-radeon-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libglapi-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libglapi-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libgbm-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libgbm-32bit-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libOSMesa-24.2.7_1.x86_64.xbps 
/var/cache/xbps/libOSMesa-32bit-24.2.7_1.x86_64.xbps 
`

And...`Corectrl` was correctly launched with no segmentation fault errors. Running in userspace tray right now with no apparent problems, GPU fans were also correctly manipulated by the application. 

I'm guessing something happened with Mesa's ABI.

If we can't find other apps affected, I'll open an issue on Corectrl's repo. 

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[EnumuratedDev]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

New comment by EnumuratedDev on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529136973

Comment:
I've had multiple programs affected by this issue. FIrefox, alacritty, discord (through flatpak) and more. Downgrading fixed all issues. I believe this is related to this mesa issue https://gitlab.freedesktop.org/mesa/mesa/-/issues/12253

Re: Removal of -Ddri3=enabled from Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529162444

Comment:
> I've had multiple programs affected by this issue. FIrefox, alacritty, discord (through flatpak) and more. Downgrading fixed all issues. I believe this is related to this mesa issue https://gitlab.freedesktop.org/mesa/mesa/-/issues/12253

Seems only to affect AMD Polaris-based GPUs, which is indeed what I am using (Hey, don't judge me, those monster GPUs they make today don't fit in my pc case).

Re: Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[SpidFightFR]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

New comment by SpidFightFR on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529311584

Comment:
> > I've had multiple programs affected by this issue. FIrefox, alacritty, discord (through flatpak) and more. Downgrading fixed all issues. I believe this is related to this mesa issue https://gitlab.freedesktop.org/mesa/mesa/-/issues/12253
> 
> Seems only to affect AMD Polaris-based GPUs, which is indeed what I am using (Hey, don't judge me, those monster GPUs they make today don't fit in my pc case).

indeed it didn't noticed it in my testing, i guess RDNA3 GPUs aren't affected somehow... My apologies for that.

Re: Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2529437539

Comment:
> > > I've had multiple programs affected by this issue. FIrefox, alacritty, discord (through flatpak) and more. Downgrading fixed all issues. I believe this is related to this mesa issue https://gitlab.freedesktop.org/mesa/mesa/-/issues/12253
> > 
> > 
> > Seems only to affect AMD Polaris-based GPUs, which is indeed what I am using (Hey, don't judge me, those monster GPUs they make today don't fit in my pc case).
> 
> indeed it didn't noticed it in my testing, i guess RDNA3 GPUs aren't affected somehow... My apologies for that.

It's fine. they're adding OpenGL 4.6 API, so they're bound to have lots of regressions before they stabilize, and we can't ask maintainers to do all the tests that mesa-dri devs should be doing in the first place. 

Re: Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications On AMD Polaris-based GPUs

[sofijacom]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

New comment by sofijacom on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2530509953

Comment:
AMD Radeon processor

After updating Mesa 24.3.1 the system stopped loading, the screen is black, it no longer responds to anything.

Re: Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications On AMD Polaris-based GPUs

[biopsin]

[-- Attachment #1: Type: text/plain, Size: 225 bytes --]

New comment by biopsin on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2530790599

Comment:
I have one AMD pc with Polaris 20 RX570 which I will manage to test later today..

Re: Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications On AMD Polaris-based GPUs

[sofijacom]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

New comment by sofijacom on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2530509953

Comment:
AMD Radeon 

After updating Mesa 24.3.1 the system stopped loading, the screen is black, it no longer responds to anything.

Re: Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications On AMD Polaris-based GPUs

[risusinf]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

New comment by risusinf on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2531208914

Comment:
> AMD Radeon
> 
> After updating Mesa 24.3.1 the system stopped loading, the screen is black, it no longer responds to anything.

Same with A8-9600 integrated graphics. Fixed by downgrading.

`sudo xdowngrade /var/cache/xbps/mesa-24.2.7_1.x86_64.xbps /var/cache/xbps/mesa-dri-24.2.7_1.x86_64.xbps /var/cache/xbps/libglapi-24.2.7_1.x86_64.xbps /var/cache/xbps/mesa-libgallium-24.2.7_1.x86_64.xbps /var/cache/xbps/libgbm-24.2.7_1.x86_64.xbps`

Re: Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications On AMD Polaris-based GPUs

[SpidFightFR]

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

New comment by SpidFightFR on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2531226008

Comment:
@classabbyamp maybe it's best to revert my changes, wait for things to calm down?

Re: Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications On AMD Polaris-based GPUs

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 227 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2531549900

Comment:
or maybe the patch from upstream could be tested

either way, make a pr please

Re: Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications On AMD Polaris-based GPUs

[naneros]

[-- Attachment #1: Type: text/plain, Size: 254 bytes --]

New comment by naneros on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2531565740

Comment:
AMD Radeon RX 580
Firefox segmentation fault, supertuxkart black screen.
Downgrading to 24.2.7 fix problems.

Re: Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications On AMD Polaris-based GPUs

[SpidFightFR]

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

New comment by SpidFightFR on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2531689282

Comment:
> or maybe the patch from upstream could be tested
> 
> either way, make a pr please

I'm at work right now, could you please send the link to the patch so that i can check it as soon as possible to make the pr please?

Re: Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications On AMD Polaris-based GPUs

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2532102894

Comment:
> > or maybe the patch from upstream could be tested
> > either way, make a pr please
> 
> I'm at work right now, could you please send the link to the patch so that i can check it as soon as possible to make the pr please?

Further segfaults issues are flooding the issues tab, and don't seem related to this specific bug:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/12275 (Segfault on Nvidia Quadro)
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12283 (Segfault with Gnome-Shell on Intel Integrated Graphics)

With this many segfaults on all available GPU vendors, I would begin to doubt this is a problem limited to Polaris architecture. 
I would say it may be safer to just revert for now, and wait for `Mesa` to cook-up a little their next update. As I said before, they're working on the OpenGL 4.6 API, and thus they're bound to have lots of regressions before stabilizing. Besides, I don't think anyone specifically requesting those OpenGL 4.6 API changes expect them to be finalized already. 

Re: Mesa 24.3.1 Update May Be Causing Segmentation Faults In Some Applications On AMD Polaris-based GPUs

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2532102894

Comment:
> > or maybe the patch from upstream could be tested
> > either way, make a pr please
> 
> I'm at work right now, could you please send the link to the patch so that i can check it as soon as possible to make the pr please?

Further segfaults issues are flooding the issues tab, and don't seem related to this specific bug:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/12275 (Segfault on Nvidia Quadro)
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12283 (Segfault with Gnome-Shell on Intel Integrated Graphics)

With this many segfaults on all available GPU vendors, I would begin to doubt this is a problem limited to Polaris architecture (Though it's probably a multi-bug release due to fundamental ABI changes). 
I would say it may be safer to just revert for now, and wait for `Mesa` to cook-up a little their next update. As I said before, they're working on the OpenGL 4.6 API, and thus they're bound to have lots of regressions before stabilizing. Besides, I don't think anyone specifically requesting those OpenGL 4.6 API changes expect them to be finalized already. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2532338488

Comment:
> Further segfaults issues are flooding the issues tab, and don't seem related to this specific bug:
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/12275 (Segfault on Nvidia Quadro) https://gitlab.freedesktop.org/mesa/mesa/-/issues/12283 (Segfault with Gnome-Shell on Intel Integrated Graphics)
> 
> With this many segfaults on all available GPU vendors, I would begin to doubt this is a problem limited to Polaris architecture (Though it's probably a multi-bug release due to fundamental ABI changes). I would say it may be safer to just revert for now, and wait for `Mesa` to cook-up a little their next update. As I said before, they're working on the OpenGL 4.6 API, and thus they're bound to have lots of regressions before stabilizing. Besides, I don't think anyone specifically requesting those OpenGL 4.6 API changes expect them to be finalized already.

OK, those issues seem confirmed, and we're already seeing devolopers commenting, and horror screenshoots. Definitively, there's ABI changes that broke support on multiple architectures, and they don't seem intentional, nor Mesa developers mentioned dropping support for any architecture. I changed the title accordingly. 

I will keep the issue open even after a revert-pull (Which is looking more likely now, unless mainteners want to pull from upstream at least 3 fixes), since we'll probably need some extensive testing on whatever `Mesa 24.3.2`+ package will need to be made after Mesa devs actually can cook-up some fixes, doubt they'll be staying long on `Mesa 24.3.1` with all those bugs cropping up. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2532338488

Comment:
> Further segfaults issues are flooding the issues tab, and don't seem related to this specific bug:
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/12275 (Segfault on Nvidia Quadro) https://gitlab.freedesktop.org/mesa/mesa/-/issues/12283 (Segfault with Gnome-Shell on Intel Integrated Graphics)
> 
> With this many segfaults on all available GPU vendors, I would begin to doubt this is a problem limited to Polaris architecture (Though it's probably a multi-bug release due to fundamental ABI changes). I would say it may be safer to just revert for now, and wait for `Mesa` to cook-up a little their next update. As I said before, they're working on the OpenGL 4.6 API, and thus they're bound to have lots of regressions before stabilizing. Besides, I don't think anyone specifically requesting those OpenGL 4.6 API changes expect them to be finalized already.

OK, those issues seem confirmed, and we're already seeing devolopers commenting, and horror screenshoots. Definitively, there's ABI changes that broke support on multiple architectures, and they don't seem intentional, nor Mesa developers mentioned dropping support for any architecture. I changed the title accordingly. 

I will keep the issue open even after a revert-pull (Which is looking more likely now, unless mainteners want to pull from upstream at least 3 fixes), since we'll probably need some extensive testing on whatever `Mesa 24.3.2`+ package will need to be made after Mesa devs actually can cook-up some fixes, doubt they'll be staying long on `Mesa 24.3.1` with all those bugs cropping up. 

I ask mantainers to link this issue to pull request meant to revert/fix those bugs for easier tracking, if possible. 

Anyone else is free to link this issue to Mesa gitlab devs in case they need more info/testing.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2532338488

Comment:
> Further segfaults issues are flooding the issues tab, and don't seem related to this specific bug:
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/12275 (Segfault on Nvidia Quadro) https://gitlab.freedesktop.org/mesa/mesa/-/issues/12283 (Segfault with Gnome-Shell on Intel Integrated Graphics)
> 
> With this many segfaults on all available GPU vendors, I would begin to doubt this is a problem limited to Polaris architecture (Though it's probably a multi-bug release due to fundamental ABI changes). I would say it may be safer to just revert for now, and wait for `Mesa` to cook-up a little their next update. As I said before, they're working on the OpenGL 4.6 API, and thus they're bound to have lots of regressions before stabilizing. Besides, I don't think anyone specifically requesting those OpenGL 4.6 API changes expect them to be finalized already.

OK, those issues seem confirmed, and we're already seeing devolopers commenting, and horror screenshoots. Definitively, there's ABI changes that broke support on multiple architectures, and they don't seem intentional, nor Mesa developers mentioned dropping support for any architecture. I changed the title accordingly. 

I will keep the issue open even after a revert-pull (Which is looking more likely now, unless maintainers want to pull from upstream at least 3 fixes), since we'll probably need some extensive testing on whatever `Mesa 24.3.2`+ package will need to be made after Mesa devs actually can cook-up some fixes, doubt they'll be staying long on `Mesa 24.3.1` with all those bugs cropping up. 

I ask mantainers to link this issue to pull request meant to revert/fix those bugs for easier tracking, if possible. 

Anyone else is free to link this issue to Mesa gitlab devs in case they need more info/testing.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[biopsin]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

New comment by biopsin on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2532474573

Comment:
> I have one AMD pc with Polaris 20 RX570 which I will manage to test later today..
Unfortunatly I cant tickle a segfault testing in general, firefox & webgl, a game .. 
Im down with downgrade util this pans out, seems they have their hands full for the time being.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[zlice]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

New comment by zlice on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2533377232

Comment:
[drifix.patch.txt](https://github.com/user-attachments/files/18087966/drifix.patch.txt)

Does this fix anything for anyone? Sure mesa crew would like to know if so

Ser also posted this patch with a PR near the bottom of that first issue 12253

[drifix-simon.patch.txt](https://github.com/user-attachments/files/18087981/drifix-simon.patch.txt)

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[hvraven]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

New comment by hvraven on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2535435694

Comment:
Hit the same bug with a RX480. Added the patch (downloaded directly from gitlab) to the mesa 24.3.1 pkg and can confirm it fixes the issue.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2537032745

Comment:
> Hit the same bug with a RX480. Added the patch (downloaded directly from gitlab) to the mesa 24.3.1 pkg and can confirm it fixes the issue.

Very well, but it would be prudent, as mentioned here https://github.com/void-linux/void-packages/pull/53470#issuecomment-2536910845, to just wait for a potential .2 future version, given that multiple architectures across multiple vendors are affected. 

I won't be closing the issue for now (If that's okay with maintainers, of course), since we've hit a good amount of potential testers for when a .2 future version hits, whenever it happens, to which we'll have to eventually update anyway. 

@SpidFightFR Thanks for the downgrade (Tested on 2 Void boxes, it just _werks_). 
And I noticed you were apologizing at https://github.com/void-linux/void-packages/pull/53453#issue-2731123155. I just wanted to tell you that your work has been excellent so far, and you shouldn't feel the need to apologize in this particular occasion. You did nothing wrong, it's just that Mesa devs released an update that probably should have been baked-in a little more. You did well, regardless. 
As always, I would like to thank you, the rest of the Void Linux team, and everyone else from the userbase for their efforts and continued support. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2532102894

Comment:
> > or maybe the patch from upstream could be tested
> > either way, make a pr please
> 
> I'm at work right now, could you please send the link to the patch so that i can check it as soon as possible to make the pr please?

Further segfaults issues are flooding the issues tab, and don't seem related to this specific bug:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/12275 (Segfault on Nvidia Quadro)
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12283 (Segfault with Gnome-Shell on Intel Integrated Graphics)

With this many segfaults on all available GPU vendors, I would begin to doubt this is a problem limited to Polaris architecture (Though it's probably a multi-bug release due to fundamental ABI changes). 
I would say it may be safer to just revert for now, and wait for `Mesa` to cook-up a little their next update. As I said before, they're working on the OpenGL 4.6 API, and thus they're bound to have lots of regressions before stabilizing. Besides, I don't think anyone specifically requesting those OpenGL 4.6 API changes expects them to be finalized already. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[SpidFightFR]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

New comment by SpidFightFR on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2537095387

Comment:
@TeusLollo Hey, thanks for your message, it truly means a lot.
Although, I'm not officially a maintainer for mesa, i do try my best to keep it updated within void repos, as much as possible. Because it means a lot in my personal usage.

I'll keep an eye out for the next minor release of mesa's 24.3 branch.
In the meantime, there should be one or so new releases into 24.2 branch, so i'll make sure to take these into account.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2560317747

Comment:
users affected by this, please test this: https://github.com/void-linux/void-packages/pull/53601

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2563706977

Comment:
Hey I'm not sure if related or not, but there has been a serious bug with amdgpu and mesa. See the issues here: https://gitlab.freedesktop.org/drm/amd/-/issues

Multiple reports of people's machines just freezing. In my case, the wayland session is usable for ~20 mins then everything locks up. I just use the TTY now on that machine.

I tried using older kernel's 6.6, 6.10, 6.11. I tried downgrading amdgpu from 20240909_1 to 20241110_1 and 20240909_1. I tried switching to onboard integrated graphics (also AMD) and not using the graphics card.
Still the issue persists. The computer is near unusable. Not sure what else to try.
I'm using Wayland.

```
VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 32 [Radeon RX 7700 XT / 7800 XT] (rev c8)
VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raphael (rev c1)
```

So I suspect the problem is with the recent mesa upgrade 24.2.8_2. I tried downgrading my mesa but there are so many confusing dependencies that it's very difficult.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2563997175

Comment:
> So I suspect the problem is with the recent mesa upgrade 24.2.8_2. I tried downgrading my mesa but there are so many confusing dependencies that it's very difficult.

Do this:

`sudo xbps-install -Syu xtools`
`ls  /var/cache/xbps/ | grep "mesa"`
`sudo xdowngrade /var/cache/xbps/mesa-(whatever1) /var/cache/xbps/mesa-(whatever2) /var/cache/xbps/mesa-(whatever3)...`

Basically, after you have ensured to have `xtools` on your machine (Which you need to use `xdowngrade`), you use `ls` to list all your `mesa` packages currently in `/var/cache/xbps` (Remember that `xbps` does not provide online downgrades unless it's done by upstream, you physically require obsolete packages in your cache for them to be downgraded), and then you list them after `xdowngrade` to downgrade each and everyone of them. There are safety measures in place, thus, if you happen to attempt to only downgrade some, `xdowngrade` will throw you an error and tell you what's missing, it's relatively safe. 

Obviously, if you already cleared your cache, you won't have any obsolete packages in your cache, and thus this method will be unavailable. 

The manual entry here: https://docs.voidlinux.org/xbps/advanced-usage.html

As for me, I may be able to test this in a few days, because, you know, end of the year with family and stuff, and it's gonna take a while do compile, install, and perform broad tests, assuming it all goes well. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2563997175

Comment:
> So I suspect the problem is with the recent mesa upgrade 24.2.8_2. I tried downgrading my mesa but there are so many confusing dependencies that it's very difficult.

Do this:

`sudo xbps-install -Syu xtools`
`ls  /var/cache/xbps/ | grep "mesa"`
`sudo xdowngrade /var/cache/xbps/mesa-(whatever1) /var/cache/xbps/mesa-(whatever2) /var/cache/xbps/mesa-(whatever3)...`

Basically, after you have ensured to have `xtools` on your machine (Which you need to use `xdowngrade`), you use `ls` to list all your `mesa` packages currently in `/var/cache/xbps` (Remember that `xbps` does not provide online downgrades unless it's done by upstream, you physically require obsolete packages in your cache for them to be downgraded), and then you list them after `xdowngrade` to downgrade each and everyone of them. There are safety measures in place, thus, if you happen to attempt to only downgrade some, `xdowngrade` will throw you an error and tell you what's missing, it's relatively safe. 

Obviously, if you already cleared your cache, you won't have any obsolete packages in your cache, and thus this method will be unavailable. 

The manual entry here: https://docs.voidlinux.org/xbps/advanced-usage.html

It may not be related, though, AMD has an history of hard freezes on multiple occasions, although, you never know if a segmentation fault in a wayland-based WM could actually trigger a display freeze. 

As for me, I may be able to test this in a few days, because, you know, end of the year with family and stuff, and it's gonna take a while do compile, install, and perform broad tests, assuming it all goes well. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564330183

Comment:
I try to downgrade mesa, but it says I need to downgrade libglapi. I try to downgrade libglapi, but it says I need to downgrade mesa.

```
~#  xdowngrade /var/cache/xbps/mesa-24.2.7_1.x86_64.xbps 
index: added `mesa-24.2.7_1' (x86_64).
index: 1 packages registered.
MISSING: libglapi-24.2.7_1
Transaction aborted due to unresolved dependencies.
~# xdowngrade /var/cache/xbps/libglapi-24.2.7_1.x86_64.xbps 
index: added `libglapi-24.2.7_1' (x86_64).
index: 1 packages registered.
libglapi-24.2.7_1 in transaction breaks installed pkg `libOSMesa-24.2.8_2'
libglapi-24.2.7_1 in transaction breaks installed pkg `mesa-24.2.8_2'
libglapi-24.2.7_1 in transaction breaks installed pkg `mesa-libgallium-24.2.8_2'
Transaction aborted due to unresolved dependencies.
```

TBH I think void should just downgrade mesa/amdgpu. There's something very clearly massively broken in this latest release. People are reporting their systems just freezing and requiring a hard reboot.

https://gitlab.freedesktop.org/drm/amd/-/issues

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 530 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564331156

Comment:
do all the downgrades in 1 command.

> TBH I think void should just downgrade mesa/amdgpu. There's something very clearly massively broken in this latest release. People are reporting their systems just freezing and requiring a hard reboot.

we are not using the latest release. we already downgraded back to 24.2.x from that. which version are people reporting causes freezes?

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564337714

Comment:
> I try to downgrade mesa, but it says I need to downgrade libglapi. I try to downgrade libglapi, but it says I need to downgrade mesa.

You can add multiple arguments in succession. Thus, `xdowngrade /var/cache/xbps/mesa-24.2.7_1.x86_64.xbps  /var/cache/xbps/libglapi-24.2.7_1.x86_64.xbps` (All in the same line at the same time) and so on. 
There is no hard limit to the number of arguments you can assign to a command. 
That should fix it, although you will probably have to downgrade more packages than `mesa` & `libglapi`, but it should be easy enough (`xbps` will tell you). 
This downgrade failsafe is in place because `mesa` packages of differing version mya not play nicely together, although results may vary. 

> TBH I think void should just downgrade mesa/amdgpu. There's something very clearly massively broken in this latest release. People are reporting their systems just freezing and requiring a hard reboot.
> 
> https://gitlab.freedesktop.org/drm/amd/-/issues

We, in fact, have already downgraded. We were on `mesa-24.3.*` and that's when I and other users noticed the great segfaults cascade. If you can confirm, after downgrading, that the issue is gone, and can manage to get the output of whatever wayland-based window manager you are using (It depends on the window manager, each and everyone are a bit different, use `man` to access their built-in manual), you will can see your yourself if it's a segfault error, or something else entirely. 

BTW, keep in mind that AMD-based GPUs have an history of hard-freezes that is not related to `mesa`, it goes back and forth with each release and major updates on the kernel-level AMD driver (Which is not handled by `mesa` developers), and it may be related to `linux-firmware-amd` (Which is closed-source) not playing very nicely with such driver updates. A good approach is to use a tool like `corectrl` to block GPU performance to a fixed level (Low, high performance modes, or other approaches were you select a given GPU frequency and block it from downscaling or upscaling), which on my systems has avoided those entirely. 

https://gitlab.freedesktop.org/drm/amd/-/issues/960
https://bugs.archlinux.org/task/68396
https://bugs.archlinux.org/task/68424
https://bugs.archlinux.org/task/68402
https://gitlab.freedesktop.org/drm/amd/-/issues/716

Also, ensure that `linux-firmware-amd` is up-to-date

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564337714

Comment:
> I try to downgrade mesa, but it says I need to downgrade libglapi. I try to downgrade libglapi, but it says I need to downgrade mesa.

You can add multiple arguments in succession. Thus, `xdowngrade /var/cache/xbps/mesa-24.2.7_1.x86_64.xbps  /var/cache/xbps/libglapi-24.2.7_1.x86_64.xbps` (All in the same line at the same time) and so on. 
There is no hard limit to the number of arguments you can assign to a command. 
That should fix it, although you will probably have to downgrade more packages than `mesa` & `libglapi`, but it should be easy enough (`xbps` will tell you). 
This downgrade failsafe is in place because `mesa` packages of differing version may not play nicely together, although results may vary. 

> TBH I think void should just downgrade mesa/amdgpu. There's something very clearly massively broken in this latest release. People are reporting their systems just freezing and requiring a hard reboot.
> 
> https://gitlab.freedesktop.org/drm/amd/-/issues

We, in fact, have already downgraded. We were on `mesa-24.3.*` and that's when I and other users noticed the great segfaults cascade. If you can confirm, after downgrading, that the issue is gone, and can manage to get the output of whatever wayland-based window manager you are using (It depends on the window manager, each and everyone are a bit different, use `man` to access their built-in manual), you will can see your yourself if it's a segfault error, or something else entirely. 

BTW, keep in mind that AMD-based GPUs have an history of hard-freezes that is not related to `mesa`, it goes back and forth with each release and major updates on the kernel-level AMD driver (Which is not handled by `mesa` developers), and it may be related to `linux-firmware-amd` (Which is closed-source) not playing very nicely with such driver updates. A good approach is to use a tool like `corectrl` to block GPU performance to a fixed level (Low, high performance modes, or other approaches were you select a given GPU frequency and block it from downscaling or upscaling), which on my systems has avoided those entirely. 

https://gitlab.freedesktop.org/drm/amd/-/issues/960
https://bugs.archlinux.org/task/68396
https://bugs.archlinux.org/task/68424
https://bugs.archlinux.org/task/68402
https://gitlab.freedesktop.org/drm/amd/-/issues/716

Also, ensure that `linux-firmware-amd` is up-to-date

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564417446

Comment:
Thank you so much, that's very helpful.

I had these lock up issues a year ago, but then they went away. But they would happen maybe every 8 hours. This reoccurrence is now more quicker like 30 mins or so.

Unfortunately I tried downgrading but it didn't go away. The system still freezes. I tried these combos:

Linux kernel 6.10:
```
~# xdowngrade /var/cache/xbps/linux-firmware-amd-20241110_1.x86_64.xbps
~# xdowngrade mesa-24.2.7_1.x86_64.xbps libglapi-24.2.7_1.x86_64.xbps libOSMesa-24.2.7_1.x86_64.xbps mesa-libgallium-24.2.7_1.x86_64.xbps libgbm-24.2.7_1.x86_64.xbps libgbm-devel-24.2.7_1.x86_64.xbps
```

Kernel 6.6:
```
~# xdowngrade linux-firmware-amd-20240909_1.x86_64.xbps
~# xdowngrade mesa-24.2.6_1.x86_64.xbps libglapi-24.2.6_1.x86_64.xbps libOSMesa-24.2.6_1.x86_64.xbps mesa-libgallium-24.2.6_1.x86_64.xbps libgbm-24.2.6_1.x86_64.xbps libgbm-devel-24.2.6_1.x86_64.xbps MesaLib-devel-24.2.6_1.x86_64.xbps
```

Is there anything I'm missing? When I downgrade firmware, do I need to run anything else? Could there be another component causing the issue?

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564417446

Comment:
Thank you so much, that's very helpful.

I had these lock up issues a year ago, but then they went away.

When they were happening, they would happen maybe every 8+ hours. This reoccurrence is now more quicker like 30 mins or so.

Unfortunately I tried downgrading but it didn't go away. The system still freezes. I tried these combos:

Linux kernel 6.10:
```
~# xdowngrade /var/cache/xbps/linux-firmware-amd-20241110_1.x86_64.xbps
~# xdowngrade mesa-24.2.7_1.x86_64.xbps libglapi-24.2.7_1.x86_64.xbps libOSMesa-24.2.7_1.x86_64.xbps mesa-libgallium-24.2.7_1.x86_64.xbps libgbm-24.2.7_1.x86_64.xbps libgbm-devel-24.2.7_1.x86_64.xbps
```

Kernel 6.6:
```
~# xdowngrade linux-firmware-amd-20240909_1.x86_64.xbps
~# xdowngrade mesa-24.2.6_1.x86_64.xbps libglapi-24.2.6_1.x86_64.xbps libOSMesa-24.2.6_1.x86_64.xbps mesa-libgallium-24.2.6_1.x86_64.xbps libgbm-24.2.6_1.x86_64.xbps libgbm-devel-24.2.6_1.x86_64.xbps MesaLib-devel-24.2.6_1.x86_64.xbps
```

Is there anything I'm missing? When I downgrade firmware, do I need to run anything else? Could there be another component causing the issue?

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564417446

Comment:
Thank you so much, that's very helpful.

I had these lock up issues a year ago, but then they went away.

When they were happening, they would happen maybe every 8+ hours. This reoccurrence is now more quicker like 30 mins or so.

Unfortunately I tried downgrading but it didn't go away. The system still freezes. I tried these combos:

Linux kernel 6.10:
```
~# xdowngrade /var/cache/xbps/linux-firmware-amd-20241110_1.x86_64.xbps
~# xdowngrade mesa-24.2.7_1.x86_64.xbps libglapi-24.2.7_1.x86_64.xbps libOSMesa-24.2.7_1.x86_64.xbps mesa-libgallium-24.2.7_1.x86_64.xbps libgbm-24.2.7_1.x86_64.xbps libgbm-devel-24.2.7_1.x86_64.xbps
```

Kernel 6.6:
```
~# xdowngrade linux-firmware-amd-20240909_1.x86_64.xbps
~# xdowngrade mesa-24.2.6_1.x86_64.xbps libglapi-24.2.6_1.x86_64.xbps libOSMesa-24.2.6_1.x86_64.xbps mesa-libgallium-24.2.6_1.x86_64.xbps libgbm-24.2.6_1.x86_64.xbps libgbm-devel-24.2.6_1.x86_64.xbps MesaLib-devel-24.2.6_1.x86_64.xbps
```

Is there anything I'm missing? When I downgrade firmware, do I need to run anything else? Could there be another component causing the issue?

Based off your advice, I tried underclocking the GPU but it didn't work either.

```
~# cd /sys/class/drm/card0/device
/sys/class/drm/card0/device# echo low > power_dpm_force_performance_level 
/sys/class/drm/card0/device# echo balanced > power_dpm_state 
/sys/class/drm/card0/device# cd ../../card1/device
/sys/class/drm/card1/device# echo low > power_dpm_force_performance_level 
/sys/class/drm/card1/device# echo balanced > power_dpm_state 
```

https://wiki.gentoo.org/wiki/AMDGPU#Frequent_and_Sporadic_Crashes

Still got the crash though.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564577075

Comment:
> Thank you so much, that's very helpful.
> 
> I had these lock up issues a year ago, but then they went away.
> 
> When they were happening, they would happen maybe every 8+ hours. This reoccurrence is now more quicker like 30 mins or so.
> 
> Unfortunately I tried downgrading but it didn't go away. The system still freezes. I tried these combos:

Every time the AMDGPU kernel driver is worked upon (Usually to add support for newer GPUs), something like this happens. It comes and goes, and it's been like this for years.

> ~# cd /sys/class/drm/card0/device
> /sys/class/drm/card0/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card0/device# echo balanced > power_dpm_state 
> /sys/class/drm/card0/device# cd ../../card1/device
> /sys/class/drm/card1/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card1/device# echo balanced > power_dpm_state 
> ```
> 
> https://wiki.gentoo.org/wiki/AMDGPU#Frequent_and_Sporadic_Crashes
> 
> Still got the crash though.

I did not to say to attempt any undervolting (Which should not be attempted unless you really know what you're doing). Also, the commands you're listing here are not about undervolting, but about indexing available GPU power states (Again, avoid attempting underclocking). 
Remember also that kernel parameters are needed at boot for (Most of) these to work, otherwise the GPU will just ignore those, but won't output that they're being ignored, and you'll be thinking it's working while it's not. 

No, I was writing about doing this: 

https://linuxreviews.org/HOWTO_undervolt_the_AMD_RX_4XX_and_RX_5XX_GPUs

But not the undervolting part, the "The Quick And Easy Way To Manually "Undervolt" AMD GPUs" (Which, again, is not "undervolting", but fixing GPU clock states, that's why they put it in the ""). 
Basically, look at the section for "HOWTO Limit The GPU To A Certain Set Of GPU Clock States" (But remember that you'll need to inject kernel parameters for this to work). 
Then, limit the GPU clock state to ONE specific clock state (It's all in the guide). It's critical for it to be ONE clock state, for whatever reason, that black screen is triggered by the GPU switching clock states on the fly. 

Again, much easier to just get `corectrl` and do it from there. It'll also let you see quite clearly if you've injected kernel paramters correctly. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 2689 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564577075

Comment:
> Thank you so much, that's very helpful.
> 
> I had these lock up issues a year ago, but then they went away.
> 
> When they were happening, they would happen maybe every 8+ hours. This reoccurrence is now more quicker like 30 mins or so.
> 
> Unfortunately I tried downgrading but it didn't go away. The system still freezes. I tried these combos:

Every time the AMDGPU kernel driver is worked upon (Usually to add support for newer GPUs), something like this happens. It comes and goes, and it's been like this for years. Remember that the AMDGPU driver is shared by many GPU adapters (Like, tens of those), thus one bug will affacted multi-generation adapters.

> ~# cd /sys/class/drm/card0/device
> /sys/class/drm/card0/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card0/device# echo balanced > power_dpm_state 
> /sys/class/drm/card0/device# cd ../../card1/device
> /sys/class/drm/card1/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card1/device# echo balanced > power_dpm_state 
> ```
> 
> https://wiki.gentoo.org/wiki/AMDGPU#Frequent_and_Sporadic_Crashes
> 
> Still got the crash though.

I did not to say to attempt any undervolting (Which should not be attempted unless you really know what you're doing). Also, the commands you're listing here are not about undervolting, but about indexing available GPU power states (Again, avoid attempting underclocking). 
Remember also that kernel parameters are needed at boot for (Most of) these to work, otherwise the GPU will just ignore those, but won't output that they're being ignored, and you'll be thinking it's working while it's not. 

No, I was writing about doing this: 

https://linuxreviews.org/HOWTO_undervolt_the_AMD_RX_4XX_and_RX_5XX_GPUs

But not the undervolting part, the "The Quick And Easy Way To Manually "Undervolt" AMD GPUs" (Which, again, is not "undervolting", but fixing GPU clock states, that's why they put it in the ""). 
Basically, look at the section for "HOWTO Limit The GPU To A Certain Set Of GPU Clock States" (But remember that you'll need to inject kernel parameters for this to work). 
Then, limit the GPU clock state to ONE specific clock state (It's all in the guide). It's critical for it to be ONE clock state, for whatever reason, that black screen is triggered by the GPU switching clock states on the fly. 

Again, much easier to just get `corectrl` and do it from there. It'll also let you see quite clearly if you've injected kernel paramters correctly. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 2687 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564577075

Comment:
> Thank you so much, that's very helpful.
> 
> I had these lock up issues a year ago, but then they went away.
> 
> When they were happening, they would happen maybe every 8+ hours. This reoccurrence is now more quicker like 30 mins or so.
> 
> Unfortunately I tried downgrading but it didn't go away. The system still freezes. I tried these combos:

Every time the AMDGPU kernel driver is worked upon (Usually to add support for newer GPUs), something like this happens. It comes and goes, and it's been like this for years. Remember that the AMDGPU driver is shared by many GPU adapters (Like, tens of those), thus one bug will affect multi-generation adapters.

> ~# cd /sys/class/drm/card0/device
> /sys/class/drm/card0/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card0/device# echo balanced > power_dpm_state 
> /sys/class/drm/card0/device# cd ../../card1/device
> /sys/class/drm/card1/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card1/device# echo balanced > power_dpm_state 
> ```
> 
> https://wiki.gentoo.org/wiki/AMDGPU#Frequent_and_Sporadic_Crashes
> 
> Still got the crash though.

I did not to say to attempt any undervolting (Which should not be attempted unless you really know what you're doing). Also, the commands you're listing here are not about undervolting, but about indexing available GPU power states (Again, avoid attempting underclocking). 
Remember also that kernel parameters are needed at boot for (Most of) these to work, otherwise the GPU will just ignore those, but won't output that they're being ignored, and you'll be thinking it's working while it's not. 

No, I was writing about doing this: 

https://linuxreviews.org/HOWTO_undervolt_the_AMD_RX_4XX_and_RX_5XX_GPUs

But not the undervolting part, the "The Quick And Easy Way To Manually "Undervolt" AMD GPUs" (Which, again, is not "undervolting", but fixing GPU clock states, that's why they put it in the ""). 
Basically, look at the section for "HOWTO Limit The GPU To A Certain Set Of GPU Clock States" (But remember that you'll need to inject kernel parameters for this to work). 
Then, limit the GPU clock state to ONE specific clock state (It's all in the guide). It's critical for it to be ONE clock state, for whatever reason, that black screen is triggered by the GPU switching clock states on the fly. 

Again, much easier to just get `corectrl` and do it from there. It'll also let you see quite clearly if you've injected kernel paramters correctly. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564577075

Comment:
> Thank you so much, that's very helpful.
> 
> I had these lock up issues a year ago, but then they went away.
> 
> When they were happening, they would happen maybe every 8+ hours. This reoccurrence is now more quicker like 30 mins or so.
> 
> Unfortunately I tried downgrading but it didn't go away. The system still freezes. I tried these combos:

Every time the AMDGPU kernel driver is worked upon (Usually to add support for newer GPUs), something like this happens. It comes and goes, and it's been like this for years. Remember that the AMDGPU driver is shared by many GPU adapters (Like, tens of those), thus one bug will affect multi-generation adapters.

> ~# cd /sys/class/drm/card0/device
> /sys/class/drm/card0/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card0/device# echo balanced > power_dpm_state 
> /sys/class/drm/card0/device# cd ../../card1/device
> /sys/class/drm/card1/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card1/device# echo balanced > power_dpm_state 
> ```
> 
> https://wiki.gentoo.org/wiki/AMDGPU#Frequent_and_Sporadic_Crashes
> 
> Still got the crash though.

I did not to say to attempt any undervolting (Which should not be attempted unless you really know what you're doing). Also, the commands you're listing here are not about undervolting, but about indexing available GPU power states (Again, avoid attempting underclocking). 
Remember also that kernel parameters are needed at boot for (Most of) these to work, otherwise the GPU will just ignore those, but won't output that they're being ignored, and you'll be thinking it's working while it's not. 

No, I was writing about doing this: 

https://linuxreviews.org/HOWTO_undervolt_the_AMD_RX_4XX_and_RX_5XX_GPUs

But not the undervolting part, the "The Quick And Easy Way To Manually "Undervolt" AMD GPUs" (Which, again, is not "undervolting", but fixing GPU clock states, that's why they put it in the ""). 
Basically, look at the section for "HOWTO Limit The GPU To A Certain Set Of GPU Clock States" (But remember that you'll need to inject kernel parameters for this to work). 
Then, limit the GPU clock state to ONE specific clock state (It's all in the guide). It's critical for it to be ONE clock state, for whatever reason, that black screen is triggered by the GPU switching clock states on the fly (But, if we force the GPU to stay on ONE clock state, there won't be any switching available, thus hopefully no black screen triggering). 

Again, much easier to just get `corectrl` and do it from there. It'll also let you see quite clearly if you've injected kernel paramters correctly. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 2897 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564577075

Comment:
> Thank you so much, that's very helpful.
> 
> I had these lock up issues a year ago, but then they went away.
> 
> When they were happening, they would happen maybe every 8+ hours. This reoccurrence is now more quicker like 30 mins or so.
> 
> Unfortunately I tried downgrading but it didn't go away. The system still freezes. I tried these combos:

Every time the AMDGPU kernel driver is worked upon (Usually to add support for newer GPUs), something like this happens. It comes and goes, and it's been like this for years. Remember that the AMDGPU driver is shared by many GPU adapters (Like, tens of those), thus one bug will affect multi-generation adapters.

> ~# cd /sys/class/drm/card0/device
> /sys/class/drm/card0/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card0/device# echo balanced > power_dpm_state 
> /sys/class/drm/card0/device# cd ../../card1/device
> /sys/class/drm/card1/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card1/device# echo balanced > power_dpm_state 
> ```
> 
> https://wiki.gentoo.org/wiki/AMDGPU#Frequent_and_Sporadic_Crashes
> 
> Still got the crash though.

I did not to say to attempt any undervolting (Which should not be attempted unless you really know what you're doing). Also, the commands you're listing here are not about undervolting, but about indexing available GPU power states (Again, avoid attempting underclocking). 
Remember also that kernel parameters are needed at boot for (Most of) these to work, otherwise the GPU will just ignore those, but won't output that they're being ignored, and you'll be thinking it's working while it's not. 

No, I was writing about doing this: 

https://linuxreviews.org/HOWTO_undervolt_the_AMD_RX_4XX_and_RX_5XX_GPUs

But not the undervolting part, the "The Quick And Easy Way To Manually "Undervolt" AMD GPUs" (Which, again, is not "undervolting", but fixing GPU clock states, that's why they put it in the ""). 
Basically, look at the section for "HOWTO Limit The GPU To A Certain Set Of GPU Clock States" (But remember that you'll need to inject kernel parameters for this to work). 
Then, limit the GPU clock state to ONE specific clock state (It's all in the guide). It's critical for it to be ONE clock state, for whatever reason, that black screen is triggered by the GPU switching clock states on the fly (But, if we force the GPU to stay on ONE clock state, there won't be any switching available, thus hopefully no black screen triggering). 

Again, much easier to just get `corectrl` and do it from there. It'll also let you see quite clearly if you've injected kernel parameters correctly. 

Monitor temperatures, though, you don't want the thing to catch on fire.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 2976 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564577075

Comment:
> Thank you so much, that's very helpful.
> 
> I had these lock up issues a year ago, but then they went away.
> 
> When they were happening, they would happen maybe every 8+ hours. This reoccurrence is now more quicker like 30 mins or so.
> 
> Unfortunately I tried downgrading but it didn't go away. The system still freezes. I tried these combos:

Every time the AMDGPU kernel driver is worked upon (Usually to add support for newer GPUs), something like this happens. It comes and goes, and it's been like this for years. Remember that the AMDGPU driver is shared by many GPU adapters (Like, tens of those), thus one bug will affect multi-generation adapters.

> ~# cd /sys/class/drm/card0/device
> /sys/class/drm/card0/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card0/device# echo balanced > power_dpm_state 
> /sys/class/drm/card0/device# cd ../../card1/device
> /sys/class/drm/card1/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card1/device# echo balanced > power_dpm_state 
> ```
> 
> https://wiki.gentoo.org/wiki/AMDGPU#Frequent_and_Sporadic_Crashes
> 
> Still got the crash though.

I did not to say to attempt any undervolting (Which should not be attempted unless you really know what you're doing). Also, the commands you're listing here are not about undervolting, but about indexing available GPU power states (Again, avoid attempting underclocking). 
Remember also that kernel parameters are needed at boot for (Most of) these to work, otherwise the GPU will just ignore those, but won't output that they're being ignored, and you'll be thinking it's working while it's not. 

No, I was writing about doing this: 

https://linuxreviews.org/HOWTO_undervolt_the_AMD_RX_4XX_and_RX_5XX_GPUs

But not the undervolting part, the "The Quick And Easy Way To Manually "Undervolt" AMD GPUs" (Which, again, is not "undervolting", but fixing GPU clock states, that's why they put it in the ""). 
Basically, look at the section for "HOWTO Limit The GPU To A Certain Set Of GPU Clock States" (But remember that you'll need to inject kernel parameters for this to work). 
Then, limit the GPU clock state to ONE specific clock state (It's all in the guide). It's critical for it to be ONE clock state, for whatever reason, that black screen is triggered by the GPU switching clock states on the fly (But, if we force the GPU to stay on ONE clock state, there won't be any switching available, thus hopefully no black screen triggering). 

Again, much easier to just get `corectrl` and do it from there. It'll also let you see quite clearly if you've injected kernel parameters correctly (Performance Mode: Advanced, Only have one GPU State checked, others disabled). 

Monitor temperatures, though, you don't want the thing to catch on fire.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 2976 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564577075

Comment:
> Thank you so much, that's very helpful.
> 
> I had these lock up issues a year ago, but then they went away.
> 
> When they were happening, they would happen maybe every 8+ hours. This reoccurrence is now more quicker like 30 mins or so.
> 
> Unfortunately I tried downgrading but it didn't go away. The system still freezes. I tried these combos:

Every time the AMDGPU kernel driver is worked upon (Usually to add support for newer GPUs), something like this happens. It comes and goes, and it's been like this for years. Remember that the AMDGPU driver is shared by many GPU adapters (Like, tens of those), thus one bug will affect multi-generation adapters.

> ~# cd /sys/class/drm/card0/device
> /sys/class/drm/card0/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card0/device# echo balanced > power_dpm_state 
> /sys/class/drm/card0/device# cd ../../card1/device
> /sys/class/drm/card1/device# echo low > power_dpm_force_performance_level 
> /sys/class/drm/card1/device# echo balanced > power_dpm_state 
> ```
> 
> https://wiki.gentoo.org/wiki/AMDGPU#Frequent_and_Sporadic_Crashes
> 
> Still got the crash though.

I did not to say to attempt any undervolting (Which should not be attempted unless you really know what you're doing). Also, the commands you're listing here are not about undervolting, but about indexing available GPU power states (Again, avoid attempting underclocking). 
Remember also that kernel parameters are needed at boot for (Most of) these to work, otherwise the GPU will just ignore those, but won't output that they're being ignored, and you'll be thinking it's working while it's not. 

No, I was writing about doing this: 

https://linuxreviews.org/HOWTO_undervolt_the_AMD_RX_4XX_and_RX_5XX_GPUs

But not the undervolting part, the "The Quick And Easy Way To Manually "Undervolt" AMD GPUs" (Which, again, is not "undervolting", but fixing GPU clock states, that's why they put it in the ""). 
Basically, look at the section for "HOWTO Limit The GPU To A Certain Set Of GPU Clock States" (But remember that you'll need to inject kernel parameters for this to work). 
Then, limit the GPU clock state to ONE specific clock state (It's all in the guide). It's critical for it to be ONE clock state, for whatever reason, that black screen is triggered by the GPU switching clock states on the fly (But, if we force the GPU to stay on ONE clock state, there won't be any switching available, thus hopefully no black screen triggering). 

Again, much easier to just get `corectrl` and do it from there. It'll also let you see quite clearly if you've injected kernel parameters correctly (Performance Mode: Advanced, Only have ONE GPU State checked, others disabled). 

Monitor temperatures, though, you don't want the thing to catch on fire.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564663129

Comment:
Thanks so much. This is hugely helpful.

I followed your advice, and rebooted kernel 6.6 with the param `amdgpu.ppfeaturemask=0xffffffff`.

Then I open corectrl. My external GPU is card 0, and internal is card 1. For card 0, I see the GPU frequency constantly changing, but it remains fixed at 600 Mhz for card 1.

![card0](https://github.com/user-attachments/assets/e376044e-2671-404d-b348-d3ba21a814b8)
![card1](https://github.com/user-attachments/assets/cda69ac6-4397-4f91-a82a-b5e1b2842df9)

I also tried setting it through the sysfs API:

```
/sys/class/drm/card0/device# cat pp_dpm_sclk 
0: 500Mhz
1: 17Mhz *
2: 2254Mhz
/sys/class/drm/card0/device# echo 0 > pp_dpm_sclk 
/sys/class/drm/card0/device# cat pp_dpm_sclk 
0: 500Mhz
1: 7Mhz *
2: 2254Mhz

/sys/class/drm/card1/device# cat pp_dpm_sclk 
0: 400Mhz 
1: 600Mhz *
2: 2200Mhz 
/sys/class/drm/card1/device# echo 0 > pp_dpm_sclk 
bash: echo: write error: Invalid argument
```

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564663129

Comment:
Thanks so much. This is hugely helpful.

I followed your advice, and rebooted kernel 6.6 with the param `amdgpu.ppfeaturemask=0xffffffff`.

Then I open corectrl. My external GPU is card 0, and internal is card 1. For card 0, I see the GPU frequency constantly changing, but it remains fixed at 600 Mhz for card 1.

![card0](https://github.com/user-attachments/assets/e376044e-2671-404d-b348-d3ba21a814b8)
![card1](https://github.com/user-attachments/assets/cda69ac6-4397-4f91-a82a-b5e1b2842df9)

I also tried setting it through the sysfs API:

```
/sys/class/drm/card0/device# cat pp_dpm_sclk 
0: 500Mhz
1: 17Mhz *
2: 2254Mhz
/sys/class/drm/card0/device# echo 0 > pp_dpm_sclk 
/sys/class/drm/card0/device# cat pp_dpm_sclk 
0: 500Mhz
1: 7Mhz *
2: 2254Mhz

/sys/class/drm/card1/device# cat pp_dpm_sclk 
0: 400Mhz 
1: 600Mhz *
2: 2200Mhz 
/sys/class/drm/card1/device# echo 0 > pp_dpm_sclk 
bash: echo: write error: Invalid argument
```

Even with this, my system crashed.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564663129

Comment:
Thanks so much. This is hugely helpful.

I followed your advice, and rebooted kernel 6.6 with the param `amdgpu.ppfeaturemask=0xffffffff`.

Then I open corectrl. My external GPU is card 0, and internal is card 1. For card 0, I see the GPU frequency constantly changing, but it remains fixed at 600 Mhz for card 1.

![card0](https://github.com/user-attachments/assets/e376044e-2671-404d-b348-d3ba21a814b8)
![card1](https://github.com/user-attachments/assets/cda69ac6-4397-4f91-a82a-b5e1b2842df9)

I also tried setting it through the sysfs API:

```
/sys/class/drm/card0/device# cat pp_dpm_sclk 
0: 500Mhz
1: 17Mhz *
2: 2254Mhz
/sys/class/drm/card0/device# echo 0 > pp_dpm_sclk 
/sys/class/drm/card0/device# cat pp_dpm_sclk 
0: 500Mhz
1: 7Mhz *
2: 2254Mhz

/sys/class/drm/card1/device# cat pp_dpm_sclk 
0: 400Mhz 
1: 600Mhz *
2: 2200Mhz 
/sys/class/drm/card1/device# echo 0 > pp_dpm_sclk 
bash: echo: write error: Invalid argument
```

Even with this, my system crashed.

Interestingly it only seems to happen when switching windows. If I use a single terminal window, the crash doesn't happen.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 3177 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564738335

Comment:
> Thanks so much. This is hugely helpful.
> 
> I followed your advice, and rebooted kernel 6.6 with the param `amdgpu.ppfeaturemask=0xffffffff`.
> 
> Then I open corectrl. My external GPU is card 0, and internal is card 1. For card 0, I see the GPU frequency constantly changing, but it remains fixed at 600 Mhz for card 1.
> Even with this, my system crashed.
> 
> Interestingly it only seems to happen when switching windows. If I use a single terminal window, the crash doesn't happen.

A few more things:

1) Remember that with `corectrl` you need to press the "Apply" button on top-right of the window for settings to be injected, and "Save" (Only appears after having pressed "Apply") for those to be remembered. Double check you did that just in case. 

2) With hardware this powerful, you probably don't need two GPUs working in tandem (Which they don't really work in tandem, most of the work is offloaded to the PCIe-located GPU regardless). You can disable your CPU-embedded GPU in BIOS/UEFI. It'll save you on CPU heat, power consumption, and lots of headaches in the future when configuration gets confused because there are two display adapters. Even on a dual or triple setup monitor, there really is not a need to keep the CPU-embedded GPU activated. You may want to retry and see if a 1-GPU setup does away with crashes. 

3) You shouldn't downgrade the `*-firmware` packages. They're just collecton of binaries provided by manufacturers. Normally, newer version just increase the amount of binaries container, but some ancient binaries may be dropped because of security concerns. Since you're using pretty much recent hardware, you're better staying on the latest firmware packages. 

4) You did not mention what window manager (WM) you are using. If you're on one of the typical desktop environments (DEs) (Like Gnome, KDE, XFCE and the like), each of those comes with its own WM. You should take a look at their documentation and see where the WM locates .log files. If you're using a custom WM, you may want to check the documentation of that WM to see where it stores .log files. Once you've found .log files, run a search into those, and see if you can find anything with "segfault" or "seg" or "segmentation". Remember for the search to be case-insensitive and NOT to look for whole words only. 

If not, than you're experiencing a different problem than the one we've been identifying here. If so, you may want to open a separate issue here on void-packages (Here it can be requested for a package downgrade assuming many are experiencing the same problem, or a patch commit if developers appear to have produced an hotfix somewhere). 
You may otherwise open an issue on the repository of the WM developers, or the repository of the `mesa` developers (On gitlab) if you're absolutely sure this happened when `mesa` was updated. They'll take it from there, since here it's mostly software packaging and distribution to be done, not software development of each of those software suits. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564815160

Comment:
Thanks so much. You've really been very generous with your time. I've followed all your advice above. Disabling the internal GPU is a good idea. My WM is wlroots based DWL. I checked the output, and nothing seems to appear in dmesg nor my WM's output. But just looking at the amdgpu issue tracker, there's a whole load of new reports about crashing cards so I think this is not just isolated to me. But you're right, and you've given me some powerful leads to chase up. Thanks again.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2564815160

Comment:
Thanks so much. You've really been very generous with your time. I've followed all your advice above. Disabling the internal GPU is a good idea. My WM is wlroots based DWL. I checked the output, and nothing seems to appear in dmesg nor my WM's output. But just looking at the amdgpu issue tracker, there's a whole load of new reports about crashing cards so I think this is not just isolated to me. But you're right, and you've given me some powerful leads to chase up. Thanks again.

Indeed seems a big issue: https://gitlab.freedesktop.org/drm/amd/-/issues/3092

What's strange is everything was fine until just a week ago when I updated. Now even downgrading doesn't fix it.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2565274627

Comment:
OK I think I've found the source of error. Firstly I noticed it didn't happen when just terminal windows. I use a minimal desktop environment without even a toolbar. I reasoned it's because the terminal is not using AMD graphics APIs for video or vulkan.

```
  487  xbps-query -Rs mesa-vulkan-radeon
  488  xbps-query -Rs amdvlk
  489  xbps-remove mesa-vulkan-radeon
  490  xbps-query -Rs mesa-vaapi
  491  xbps-remove mesa-vaapi
  492  xbps-remove mesa-vdpau
  493  xbps-query -Rs mesa-dri
  496  cd /var/cache/xbps/
  498  xdowngrade mesa-24.2.7_1.x86_64.xbps libglapi-24.2.7_1.x86_64.xbps libOSMesa-24.2.7_1.x86_64.xbps mesa-libgallium-24.2.7_1.x86_64.xbps libgbm-24.2.7_1.x86_64.xbps libgbm-devel-24.2.7_1.x86_64.xbps MesaLib-devel-24.2.7_1.x86_64.xbps
```

Here are the lines which seem to have fixed it. I'm on kernel 6.12 and haven't had any freeze yet.

https://docs.voidlinux.org/config/graphical-session/graphics-drivers/amd.html

A big culprit seems to be the browser, which I reckon must've been using one of these components. I removed them and downgraded mesa. So if you're having these freezes, remove everything except mesa, and then downgrade mesa.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2565274627

Comment:
OK I think I've found the source of error. Firstly I noticed it didn't happen when just terminal windows. I use a minimal desktop environment without even a toolbar. I reasoned it's because the terminal is not using AMD graphics APIs for video or vulkan.

```
  487  xbps-query -Rs mesa-vulkan-radeon
  488  xbps-query -Rs amdvlk
  489  xbps-remove mesa-vulkan-radeon
  490  xbps-query -Rs mesa-vaapi
  491  xbps-remove mesa-vaapi
  492  xbps-remove mesa-vdpau
  493  xbps-query -Rs mesa-dri
  496  cd /var/cache/xbps/
  498  xdowngrade mesa-24.2.7_1.x86_64.xbps libglapi-24.2.7_1.x86_64.xbps libOSMesa-24.2.7_1.x86_64.xbps mesa-libgallium-24.2.7_1.x86_64.xbps libgbm-24.2.7_1.x86_64.xbps libgbm-devel-24.2.7_1.x86_64.xbps MesaLib-devel-24.2.7_1.x86_64.xbps
```

Here are the lines which seem to have fixed it. I'm on kernel 6.12 and haven't had any freeze yet.

https://docs.voidlinux.org/config/graphical-session/graphics-drivers/amd.html

A big culprit seems to be the browser, which I reckon must've been using one of these components. I removed them and downgraded mesa. So if you're having these freezes, remove everything except mesa, and then downgrade mesa.

BTW I tried both external graphics card (onboard disabled in bios), and removing the graphics card and just using onboard. Both are AMD. Both would have the same system freezing.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2565274627

Comment:
OK I think I've found the source of error. Firstly I noticed it didn't happen when just terminal windows. I use a minimal desktop environment without even a toolbar. I reasoned it's because the terminal is not using AMD graphics APIs for video or vulkan.

```
  487  xbps-query -Rs mesa-vulkan-radeon
  488  xbps-query -Rs amdvlk
  489  xbps-remove mesa-vulkan-radeon
  490  xbps-query -Rs mesa-vaapi
  491  xbps-remove mesa-vaapi
  492  xbps-remove mesa-vdpau
  493  xbps-query -Rs mesa-dri
  496  cd /var/cache/xbps/
  498  xdowngrade mesa-24.2.7_1.x86_64.xbps libglapi-24.2.7_1.x86_64.xbps libOSMesa-24.2.7_1.x86_64.xbps mesa-libgallium-24.2.7_1.x86_64.xbps libgbm-24.2.7_1.x86_64.xbps libgbm-devel-24.2.7_1.x86_64.xbps MesaLib-devel-24.2.7_1.x86_64.xbps
```

Here are the lines which seem to have fixed it. I'm on kernel 6.12 and haven't had any freeze yet.

https://docs.voidlinux.org/config/graphical-session/graphics-drivers/amd.html

A big culprit seems to be the browser, which I reckon must've been using one of these components. I removed them and downgraded mesa. So if you're having these freezes, remove everything except mesa, and then downgrade mesa.

BTW I tried both external graphics card (onboard disabled in bios), and removing the graphics card and just using onboard. Both are AMD. Both would have the same system freezing.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[narodnik]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

New comment by narodnik on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2567035178

Comment:
hey just commenting that I managed to get a stable configuration, and have opened a new issue here: https://github.com/void-linux/void-packages/issues/53787

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[zlice]

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

New comment by zlice on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2616164971

Comment:
anyone able to test 24.3.4 / e641ae27191d387599219694560d221b7feaa91c900bcec46bf444218ed66025 ?

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2616878414

Comment:
> anyone able to test 24.3.4 / e641ae27191d387599219694560d221b7feaa91c900bcec46bf444218ed66025 ?

Should be able to run some tests this weekend.

In the meantime, anyone cares to share on how to build multiple packages with `xbps-src` safely? Because I've been building single packages, but I'm not entirely sure if building an entire suite of packages requires different approaches to consider. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[zlice]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

New comment by zlice on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2616908427

Comment:
for something like mesa where everything's a sub-package, you just do the build for mesa.

if it's multiple packages with dependencies, you wana make sure to build them "in order" (if they rely on each other)

for 1, they may pick up the dependency being out of date, and built it, then you build it again because you did the order wrong

2nd, if something like shlibs changes and you didn't update, or some misc packages don't pick up thing properly, you waste time

not sure what you mean by safe. if that doesn't answer lmk.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[zlice]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

New comment by zlice on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2616908427

Comment:
for something like mesa where everything's a sub-package, you just do the build for mesa.

if it's multiple packages with dependencies, you wana make sure to build them "in order" (if they rely on each other)

for 1, they may pick up the dependency being out of date, and build it, then you build it again because you did the order wrong

2nd, if something like shlibs changes and you didn't update, or some misc packages don't pick up thing properly, you waste time

not sure what you mean by safe. if that doesn't answer lmk.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[hvraven]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

New comment by hvraven on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2616937473

Comment:
Tested with 24.3.4 on a RX480, at first glance the problems appear to be fixed. Will run it for longer the next days and report if I hit any problems, but with 24.3.1 the plasma desktop wasn't even starting up.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2629186391

Comment:
Ok, after a long fight with `github-cli` not reconizing my ssh key (Figures), and being forced to revert to tokens for the time being:

Tested https://github.com/void-linux/void-packages/pull/53601 _seems to be working on AMDGPU_

I will do more tests in the next few days, but someone that uses either GNOME or KDE will probably spot any problems much faster than me, also different GPU architectures would be welcome. 
But I wouldn't be merging this in until either GNOME or KDE are confirmed to be working. 

> for something like mesa where everything's a sub-package, you just do the build for mesa.
> 
> if it's multiple packages with dependencies, you wana make sure to build them "in order" (if they rely on each other)
> 
> for 1, they may pick up the dependency being out of date, and build it, then you build it again because you did the order wrong
> 
> 2nd, if something like shlibs changes and you didn't update, or some misc packages don't pick up thing properly, you waste time
> 
> not sure what you mean by safe. if that doesn't answer lmk.

By "safe" I just meant `xbps-src` actually doing a reverse-check on dependencies and subpackages and not installing version mismatched packages, which it appears to do automagically. Good to know. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[hvraven]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]

New comment by hvraven on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2630484668

Comment:
I now had it running for a week on my work setup with a full plasma/kde setup and didn't hit any issues.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[rationalize-zz]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

New comment by rationalize-zz on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2646586731

Comment:
Was wondering what was causing us to be so far behind on Mesa updates!

Looks like description links 3 mesa reports as segfaults in 24.3.1:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/12253 (Segfault on AMD Polaris)

The issue that has reports by Void users, reported as fixed in 24.3.2, seems to be corroborated by Void users that have done the testing.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/12275 (Segfault on Nvidia Quadro)

Isn't a segfault.  Report indicates the user had segfaults in 24.2.7, but those went away in 24.3.1 and instead has different issue.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/12283 (Segfault with Gnome-Shell on Intel Integrated Graphics)

Lodged against the 25.0.0-devel branch of mesa, not an actual release branch.

Since this issue is actually just one specific crash type that has been fixed for a while, could we get Mesa updates back on track?

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2648180212

Comment:
> Was wondering what was causing us to be so far behind on Mesa updates!
> 
> Looks like description links 3 mesa reports as segfaults in 24.3.1:
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/12253 (Segfault on AMD Polaris)
> 
> The issue that has reports by Void users, reported as fixed in 24.3.2, seems to be corroborated by Void users that have done the testing.
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/12275 (Segfault on Nvidia Quadro)
> 
> Isn't a segfault. Report indicates the user had segfaults in 24.2.7, but those went away in 24.3.1 and instead has different issue.
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/12283 (Segfault with Gnome-Shell on Intel Integrated Graphics)
> 
> Lodged against the 25.0.0-devel branch of mesa, not an actual release branch.
> 
> Since this issue is actually just one specific crash type that has been fixed for a while, could we get Mesa updates back on track?

We were in fact awaiting for testing by the userbase. When the issue was opened, `mesa 23.3.1` was riddled with segfault reports everywhere in their gitlab repo. I just indicized some as examples to demonstrate this was a multi-architecture concern, to justify the title, and a version reverse, that's all. But there were tens of segfaults reports on gitlab, although it was impossible to tell exactly which were related or not. So far, we've only got positive feedback about testing with AMDGPU, and the lack of reporting on other architectures was holding back an update. 

@SpidFightFR I suppose we could attempt an update to a Mesa 24.3.2+ version, since it doesn't seem we're getting more tests from here. We've only had two users actually reporting positive results with `mesa-24.3.2`, that should hopefully be enough. Let's just be careful the first 24-48 hours after the update. I will keep this issue open in the meantime just in case. 

@classabbyamp I also bring this to the attention of a more experienced void maintainer (Yourself), in case they want to chime in on what it should be done. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[SpidFightFR]

[-- Attachment #1: Type: text/plain, Size: 2395 bytes --]

New comment by SpidFightFR on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2648187246

Comment:
> > Was wondering what was causing us to be so far behind on Mesa updates!
> > 
> > Looks like description links 3 mesa reports as segfaults in 24.3.1:
> > 
> > https://gitlab.freedesktop.org/mesa/mesa/-/issues/12253 (Segfault on AMD Polaris)
> > 
> > The issue that has reports by Void users, reported as fixed in 24.3.2, seems to be corroborated by Void users that have done the testing.
> > 
> > https://gitlab.freedesktop.org/mesa/mesa/-/issues/12275 (Segfault on Nvidia Quadro)
> > 
> > Isn't a segfault. Report indicates the user had segfaults in 24.2.7, but those went away in 24.3.1 and instead has different issue.
> > 
> > https://gitlab.freedesktop.org/mesa/mesa/-/issues/12283 (Segfault with Gnome-Shell on Intel Integrated Graphics)
> > 
> > Lodged against the 25.0.0-devel branch of mesa, not an actual release branch.
> > 
> > Since this issue is actually just one specific crash type that has been fixed for a while, could we get Mesa updates back on track?
> 
> We were in fact awaiting for testing by the userbase. When the issue was opened, `mesa 23.3.1` was riddled with segfault reports everywhere in their gitlab repo. I just indicized some as examples to demonstrate this was a multi-architecture concern, to justify the title, and a version reverse, that's all. But there were tens of segfaults reports on gitlab, although it was impossible to tell exactly which were related or not. So far, we've only got positive feedback about testing with AMDGPU, and the lack of reporting on other architectures was holding back an update. 
> 
> @SpidFightFR I suppose we could attempt an update to a Mesa 24.3.2+ version, since it doesn't seem we're getting more tests from here. We've only had two users actually reporting positive results with `mesa-24.3.2`, that should hopefully be enough. Let's just be careful the first 24-48 hours after the update. I will keep this issue open in the meantime just in case. 
> 
> @classabbyamp I also bring this to the attention of a more experienced void maintainer (Yourself), in case they want to chime in on what it should be done. 
> 

Hey there, i won't be able to do this myself, unfortunately.

I've changed distro, i am no longer on voidlinux. 

I won't be able to test things myself.

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2666850838

Comment:
OK, `mesa-24-3-4` is now available as an update, anyone can thus easily test it without compiling once their mirrors update. On my side, I haven't noticed any problem when switching to the binary. 

I will keep this issue open for a few days still, in case anyone else or I find some other segfault. If not, I will be closing this. 

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2666850838

Comment:
OK, `mesa-24-3-4` is now available as an update, anyone can thus easily test it without compiling once their mirrors update. On my side, I haven't noticed any problem when switching to the binary. 

I will keep this issue open for a few days still, in case anyone else or me
 find some other segfault. If not, I will be closing this. 

Re: [ISSUE] [CLOSED] Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

Closed issue by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434

Description:
### Is this a new report?

Yes

### System Info

Void 6.6.63_1 x86_64 GenuineIntel uptodate rFFFF

### Package(s) Affected

`corectrl-1.4.1_1`

### Does a report exist for this bug with the project's home (upstream) and/or another distro?

None Found. 

### Expected behaviour

No segmentation faults given a compatible ABI interface. 

### Actual behaviour

Since Mesa update https://github.com/void-linux/void-packages/commit/027f896d1e685149c377a72ea0ceddf7d48d7431 I'm getting segmentation faults with Corectrl, ~and noticed that `configure_args = "-Ddri3=enabled"` was removed with no apparent reason that I could find (At least among discussions by Void Devs on Github. What Mesa devs may or may not have done I couldn't know). This could impact further applications if resulting in changes to the ABI interface, and that missing argument may itself be unintentional~. 

EDIT: See comments and links to upstream, but, basically, unintentional ABI changes procuring segfaults on multiple architectures

https://gitlab.freedesktop.org/mesa/mesa/-/issues/12253 (Segfault on AMD Polaris)
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12275 (Segfault on Nvidia Quadro)
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12283 (Segfault with Gnome-Shell on Intel Integrated Graphics)

### Steps to reproduce

Update to Mesa 24.3.1 https://github.com/void-linux/void-packages/commit/027f896d1e685149c377a72ea0ceddf7d48d7431

Run Corectrl in a terminal

Amid other generic Qt5 errors, notice the segmentation fault at the end:

`
[09-12-24 19:24:34.442][I] No translation found for locale en_US
[09-12-24 19:24:34.442][I] Using en_EN translation.
QSystemTrayIcon::setVisible: No Icon set
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
zsh: segmentation fault  corectrl
`

Re: Mesa 24.3.1 Update Causing Segmentation Faults On Several-Vendors GPU Architectures

[TeusLollo]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/53434#issuecomment-2676905103

Comment:
OK, no segfaults on sight since https://github.com/void-linux/void-packages/pull/54278 got merged in. 

Closing this for now, anyone else is free to reopen/make a new issue in case something else happens.

Thanks to developers for all their efforts, and thanks to the userbase for providing feedback.