LinuxQuestions.org - [SOLVED] Firefox 105.0.1 error messages after Sep 28th upgrade

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Firefox 105.0.1 error messages after Sep 28th upgrade - Slack64-Current (https://www.linuxquestions.org/questions/slackware-14/firefox-105-0-1-error-messages-after-sep-28th-upgrade-slack64-current-4175717254/)

Firefox 105.0.1 error messages after Sep 28th upgrade - Slack64-Current

After today's upgrades (Slackware64-current), Firefox 105.0.1 refused to start. I killed the process that remained running in background, lauched FF again from a console and it started but with error messages (FF is running now, but with these errors in the console). I have an AMD GPU card running stock drivers (see inxi -G output below). Things were running nicely yesterday. Kernel 5.19.12, display server X.org.

Any ideas?

Console errors:

Quote:

bash-5.2$ firefox
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: VA-API test failed: no supported VAAPI profile found. (t=0.537699) [GFX1-]: glxtest: VA-API test failed: no supported VAAPI profile found.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
Missing chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=136.039) [GFX1-]: Couldn't sanitize RENDERER device: TAHITI
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=136.039) |[C1][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=138.517) [GFX1-]: Couldn't sanitize RENDERER device: TAHITI
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=136.039) |[C1][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=138.517) |[C2][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=144.868) [GFX1-]: Couldn't sanitize RENDERER device: TAHITI
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=136.039) |[C1][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=138.517) |[C2][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=144.868) |[C3][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=174.15) [GFX1-]: Couldn't sanitize RENDERER device: TAHITI
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=136.039) |[C1][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=138.517) |[C2][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=144.868) |[C3][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=174.15) |[C4][GFX1-]: Couldn't sanitize RENDERER device: TAHITI (t=226.068) [GFX1-]: Couldn't sanitize RENDERER device: TAHITI

My inxi -G:

Quote:

bash-5.2$ inxi -G
Graphics:
Device-1: AMD Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X] driver: radeon
v: kernel
Display: server: X.Org v: 21.1.4 with: Xwayland v: 22.1.3 driver: X:
loaded: radeon unloaded: modesetting,vesa gpu: radeon
resolution: 1920x1080~60Hz
OpenGL: renderer: TAHITI ( LLVM 14.0.6 DRM 2.50 5.19.12) v: 4.5 Mesa
22.2.0

Thank you.

I'm not running current, but you might want to try switching to the amdgpu driver. I have a Tahiti card as well and if my memory serves me, I used to see those errors with firefox before I switched drivers. The amdgpu driver has better support for hw acceleration.

There's a couple other ways to enable it, but this the method I used.

Code:

# cat /etc/modprobe.d/amdgpu.conf

options amdgpu si_support=1

options amdgpu cik_support=1



# cat /etc/modprobe.d/radeon.conf

options radeon si_support=0

options radeon cik_support=0



#also added the following and rebuilt initrd.gz

echo "MODCONF=\"1\"" >> /etc/mkinitrd.conf

Regarding the first VAAPI error, you probably got bitten by the last mesa update. Starting from 22.2, mesa does not build by default video decode codecs for h264/h265, thus leaving amd gpus without VAAPI support.

Quote:

Originally Posted by giomat (Post 6383276)

Yep

Code:

Support for building Mesa with select video codecs disabled out of software patent concerns.

https://www.phoronix.com/news/Mesa-22.2-Released

Maybe we should add:

Code:

+ -Dvideo-codecs=vc1dec,h264dec,h264enc,h265dec,h265enc \

Quote:

Originally Posted by marav (Post 6383302)

Maybe we should add:

Code:

+ -Dvideo-codecs=vc1dec,h264dec,h264enc,h265dec,h265enc \

You mean remove? It's not adding anything TBH
And maybe if it goes down that route, then vdpau also should be moved to SBo or something?

Quote:

Originally Posted by elcore (Post 6383308)

You mean remove? It's not adding anything TBH
And maybe if it goes down that route, then vdpau also should be moved to SBo or something?

Nope
Others also do it like that (at least Arch & Gentoo)

Code:

option(

  'video-codecs',

  type : 'array',

  value : [],

  choices: [

    'vc1dec', 'h264dec', 'h264enc', 'h265dec', 'h265enc'

  ],

  description : 'List of patent encumbered codecs to build support for. Distros might want to consult their legal

department before enabling these. This is used for all video APIs (vaapi, vdpau, vulkan). Non-patent encumbered 

codecs will be enabled by default.'

but maybe there will be a veto from Pat's legal department ;-)

Quote:

Originally Posted by marav (Post 6383317)

Nope

Nope? Can't you be more specific? You mean nope; you're not removing by compiling without, or nope; the vdpau should stay in broken state?
That part of mesa should really go to SBo, but with SBo policy of not replacing distro packages, how?

Quote:

Originally Posted by elcore (Post 6383319)

I'm not removing
The -D means :

Code:

Universal options

All these can be set by passing -Doption=value to meson (aka meson setup)

https://mesonbuild.com/Builtin-options.html

and "+" a the beginning is because I made a diff between my slackbuild and the original one

Code:

--- mesa.SlackBuild.orig  2022-08-09 04:58:15.107303823 +0200

+++ mesa.SlackBuild    2022-09-29 12:33:04.235322375 +0200

@@ -143,6 +143,7 @@

  -Dgles2=enabled \

  -Dopengl=true \

  -Dglx=dri \

+  -Dvideo-codecs=vc1dec,h264dec,h264enc,h265dec,h265enc \

  .. || exit 1

  "${NINJA:=ninja}" $NUMJOBS || exit 1

  DESTDIR=$PKG $NINJA install || exit 1

Quote:

Originally Posted by marav (Post 6383320)

I'm not removing

OK, I'm not removing it either, we may legally keep this enabled because we're in EU.
Still not clear if we're going to have to recompile all of mesa in the future, to get this.

From my understandings this mostly affects GPU-accellerated video decode/encode (VAAPI) on AMD hardware using mesa's va driver.
Intel already needed an external driver for this (https://github.com/intel/media-driver/), while nouveau is probably out of luck anyway on recent cards.

About 5 months ago a change was introduced in mesa to require an explicit list of enabled video codecs at configure time:
https://gitlab.freedesktop.org/mesa/...9bf33337bc2c96
The default list of enabled codecs is empty, but all of them are explicitly enabled in mesa's automatic CI build script, and they are still enabled as of today.

One week ago fedora disabled all codecs in its CI build script, thus the drama:
https://src.fedoraproject.org/rpms/m...branch=rawhide
Looks like Fedora now split the vaapi drivers into a separate package, hoping for them being provided by a separate entity (possibly rpmfusion):
https://src.fedoraproject.org/rpms/m...branch=rawhide

Arch still enables all the video codecs: arch: https://github.com/archlinux/svntogi...5ef0e6d7c57f8a
Gentoo defines a compile time flag "proprietary-codecs": https://gitweb.gentoo.org/repo/gento....0.ebuild#n448
Debian defines a compile time filter "pkg.mesa.nolibva": https://salsa.debian.org/xorg-team/l...e/debian/rules
Ubuntu does the same as Debian: https://git.launchpad.net/ubuntu/+so...u/kinetic#n135
OpenSUSE doesn't explicitly enable any of the video codes (looks like they "forgot" to add the option when updating to mesa 22.2): https://build.opensuse.org/package/v....spec?expand=1

Quote:

Originally Posted by ctrlaltca (Post 6383353)

Arch still enables all the video codecs: arch: https://github.com/archlinux/svntogi...5ef0e6d7c57f8a
Gentoo defines a compile time flag "proprietary-codecs": https://gitweb.gentoo.org/repo/gento....0.ebuild#n448
Debian defines a compile time filter "pkg.mesa.nolibva": https://salsa.debian.org/xorg-team/l...e/debian/rules
Ubuntu does the same as Debian: https://git.launchpad.net/ubuntu/+so...u/kinetic#n135
OpenSUSE doesn't explicitly enable any of the video codes (looks like they "forgot" to add the option when updating to mesa 22.2): https://build.opensuse.org/package/v....spec?expand=1

And if i understand correcly, slackware won't enable them because it's US based, while debian/arch/gentoo can get away because they are community managed right?
Guess we will have to compile our own mesa package, luckily it's very easy on slack but still an annoyance.

Yesterday everything was working, I updated to current just now and Firefox is broken (also Librewolf). There's no error messages, it just hangs. I'm posting this from SeaMonkey.

09:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland [Radeon HD 8570 / R5 430 OEM / R7 240/340 / Radeon 520 OEM]

is my card, using "radeon" kmod. Alot of people are going to have non-working browsers. "Just build Mesa yourself" is our current fix?

Good news: rebuilding Mesa with the patch fixes things. Bad news: Firefox wanted to "refresh" for some reason, which I foolishly allowed, losing all my bookmarks and configuration.

Thank you for the help.

I turned off Firefox hardware acceleration but still kept radeon driver (I will try to change the radeon driver to amdgpu driver later, as suggested by fourtysixandtwo). This way, the RENDERER DEVICE error went off, but the VA-API / mesa error kept showing up.

Quote:

Originally Posted by jayjwa (Post 6383499)

Good news: rebuilding Mesa with the patch fixes things. Bad news: Firefox wanted to "refresh" for some reason, which I foolishly allowed, losing all my bookmarks and configuration.

No old profiles in ~/.mozilla/firefox to copy Places.sqlite into the new profile?