1664798 - [WebRender/EGL] Firefox freezes complete Ubuntu 20.04.1 LTS system

Status: RESOLVED WORKSFORME

(Core :: Graphics: WebRender, defect, P3)

Description

[abhishek suvarna]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Recently updated from Ubuntu 18.04 to Ubuntu 20.04.1 LTS after that when ever i open firefox after visit any website.

Actual results:

After doing some surfing entire system freeze's noting happens only option left is to restart the system

Expected results:

It does not happen using any other application only it happens in fire fox

Comment 1

[Andrei Purice]

Hello Abhishek,

I tried to reproduce this on the latest Nightly 82.0a1 (2020-09-17), beta 81.0 and release 80.0.1 on Ubuntu 18.04 and Ubuntu 20.04 but Firefox behaves normally for me. Do you visit any specific sites before encountering this issue?

Can you test the issue while in Safe Mode. You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .

Also a fresh new profile could help. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .

If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[hollmeer]

while continuously experiencing this ubuntu 20.04 freeze with firefox while browsing internet (but especially while browsing our site with firefox any arbitrary-/random-length-time), some cues emerging perhaps with today's ssh-connection to the failing ubuntu-box, when the system freeze happened.

A console output from that other box, which show the sudden output from the freezed box. As the output shows, nothing but forcing a boot with the following command eventually rebooted the stuck machine:

a console output on another ubuntu box, which was ssh to the failing ubuntu with failing firefox, when the BUG stuck the other box:

***** CLIP *****

(base) USER_NAME_HIDDEN@SERVER_NAME_HIDDEN:$
Message from syslogd@SERVER_NAME_HIDDEN at Apr 5 20:08:52 ...
kernel:[ 5134.821047] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [Web Content:8123]
^C
(base) USER_NAME_HIDDEN@SERVER_NAME_HIDDEN:$ sudo killall firefox
(base) USER_NAME_HIDDEN@SERVER_NAME_HIDDEN:$
Message from syslogd@SERVER_NAME_HIDDEN at Apr 5 20:10:49 ...
kernel:[ 5251.095727] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [Web Content:8123]
^C
(base) USER_NAME_HIDDEN@SERVER_NAME_HIDDEN:$ sudo killall --verbose firefox
Killed firefox(8071) with signal 15
(base) USER_NAME_HIDDEN@SERVER_NAME_HIDDEN:$
Message from syslogd@SERVER_NAME_HIDDEN at Apr 5 20:12:12 ...
kernel:[ 5334.840166] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [Web Content:8123]
^C
(base) USER_NAME_HIDDEN@SERVER_NAME_HIDDEN:$ sudo -s -H
root@SERVER_NAME_HIDDEN:/home/USER_NAME_HIDDEN#
Message from syslogd@SERVER_NAME_HIDDEN at Apr 5 20:12:52 ...
kernel:[ 5374.980888] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [Web Content:8123]
^C
root@SERVER_NAME_HIDDEN:/home/USER_NAME_HIDDEN# killall firefox
root@SERVER_NAME_HIDDEN:/home/USER_NAME_HIDDEN#
Message from syslogd@SERVER_NAME_HIDDEN at Apr 5 20:13:21 ...
kernel:[ 5403.010289] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [Web Content:8123]
^C
root@SERVER_NAME_HIDDEN:/home/USER_NAME_HIDDEN# echo k > /proc/sysrq-trigger
root@SERVER_NAME_HIDDEN:/home/USER_NAME_HIDDEN#
Message from syslogd@SERVER_NAME_HIDDEN at Apr 5 20:14:45 ...
kernel:[ 5487.101879] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [Web Content:8123]
^C
root@SERVER_NAME_HIDDEN:/home/USER_NAME_HIDDEN# echo f > /proc/sysrq-trigger
root@SERVER_NAME_HIDDEN:/home/USER_NAME_HIDDEN# echo r > /proc/sysrq-trigger
Message from syslogd@SERVER_NAME_HIDDEN at Apr 5 20:15:52 ...
kernel:[ 5554.926938] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [Web Content:8123]

[NOTE: at this point only the following command booted the other box:

echo b > /proc/sysrq-trigger

..which resulted booting and kicking out the ssh connection and thence the message line below..]

echo bclient_loop: send disconnect: Broken pipe

***** CLAP *****

Comment 4

[obana48]

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0

Newly installed Ubuntu 20.04 with all recent updates.

I'm experiencing very similar crashes. My ubuntu xfce4 desktop goes to eternal freeze along with high disk load. The only thin that helps is the cold reset.

Everything points at a new firefox release as it's the only application that I run when I'm experiencing these crashes. I'm going to clear the browsers' cache and I will be monitoring the issue to gather more data for Mozilla developers.

Thanks

Comment 5

[bkeahl]

I am having the same issue with Firefox on Ubuntu 20.04, 21.04, and 21.10. I had the problem in 21.04 on an HP 15-ba series, upgraded to 21.10 and the problem persisted. I loaded Ubuntu 20.04 on a Dell E5500 which also exhibits the problem. Currently running 89.0b6, but problem existed going back to 79, I think.

Chromium seems to work fine.

Comment 6

[Gustavo Homem]

Similar situation occasionally reproducible on Dell XPS 13 Dev Edition with Ubuntu 20.04. The mouse pointer moves but nothing else works. Nothing obvious in the logs. Currently running 88.0.1.

Comment 7

[u687247]

I am having the same issue.
The device is a notebook produced by Gigabyte.
It has Nvidia Geforce 770M GTX.
I can't install the proprietary drivers (causes boot issues) so using Nouveau,
Linux Mint is the OS. (version 20.1)

After I move the mouse for some time, the system hangs and nothing works, including, mouse clicks, REISUB and switching to another TTY.

Version 75.0+build3-0ubuntu1 amd64 does not have this issue. So I downgraded firefox.

Chrome also has that issue. Just for your information. Maybe that helps.

Comment 8

[bill schafer]

I am having this same issue. I use Firefox 89.0.1 and Ubuntu 21.04.

Frequently while browsing the mouse and keyboard lock up and the only way I can get past that is to power my computer off and on again.

I noticed last night that the OS continues to play music through Bluetooth after the mouse and keyboard locks up.

I had not seen this problem until I updated to Ubuntu 21.04. I also believe that Firefox updated to a new version after the Ubuntu update.

Comment 9

[Barry W. Black]

I just built a new Ubuntu MATE 20.04 system that crashes hard EVERY time I try to launch the Firefox browser since it did updates.

There were no issues with the "stock version" that came with the OS build but then... Updates.

This problem is persistent and very repeatable. As soon as the browser launches, it hangs the entire system... except that you can still move the curser all over.

I now have to do what several others have detailed and HARD restart this system, thereby losing all the work that wasn't yet completed or saved.

This needs immediate attention or my system builds will no longer have Firefox as a tool for my end-users.

Barry W. Black
Chief Scientist & Tech. Mgr.
Black Ranger Software, LLC
Austin, Texas, USA

Comment 10

[Barry W. Black]

Interesting update: For the first time, while typing and speelchking the above comment it "un-hung" ... somewhat.

I was able to close the browser with the usual button. Bear in mind that the time it took for me to detail the comment above, it came unhung, so if you have found this and have work that still needs saving... WAIT.

I had a program being compiled in a terminal that was still running and completed successfully, because I didn't do the hard reboot too soon.

Barry W. Black
Chief Scientist & Tech. Mgr.
Black Ranger Software, LLC
Austin, Texas, USA

Comment 11

[bks]

This is happening on my Ubuntu box which is totally vanilla. FF hangs the interface and nothing will react to keys or mouse.
System must be hard restarted.

Comment 12

[hollmeer]

Still there in FF 89.0.2, it seems.

After updating FF to 89.0.2 and somewhat serendipitously experiencing for some time without a system freeze (Ubuntu 20.04.02 LTS with latest updates/upgrades), left intentionally our website running in FF - and time-to-time looking FF window if still alive and well, just in curious yet still dubious anticipation of impact/outcome after the 89.0.2 fixes (cf. related fix of https://bugzilla.mozilla.org/show_bug.cgi?id=1708224 ) - and working with other applications.

After about 45min of working, took FF window again from background to foreground/active window, and with a wandering mind, thought of the very possibility that so far so good, so curious if this one gone with the update..

..and suddenly while moving the mouse cursor on the screen, the familiar pattern of behavior re-emerged: ..the cursor on screen hardly following the intended movement but with sparse leaps and just grossly following the intended movement patterns, with quite a difficulty to point the mouse cursor into a precise intended position on a close-button etc.. ..and as the pattern rapidly deteriorated, the cursor got stuck into a fixed arbitrary position, and nothing happened but the fan was spinning louder, indicating a processor hurdle.

Re an earlier comment herein for WAIT, to try to save the unsaved works, nothing changed withing the next 12minutes..

The laptop was stuck into a condition..

..so went back to power button and rebooted the poor thing.

Comment 13

[Yoram]

Also in FF 89.0.2.

The only workaround is to access my computer via SSH from my phone and

killall firefox

but you only got a minute or less.

Comment 14

[1020988872]

Also in FF 90.0, Ubuntu 20.04.2, Linux 5.9.8, Xfce 4.14.
FF does not freeze my system. It freezes when the network is bad, especially when it's loading the context.
I'm using a slow proxy server to access the Internet (in China). For example, when I'm typing in the Google search box, the characters cannot display in real-time, and all the other tabs also fail to response, until a few seconds later the webpage is updated. Sometimes it may even freeze for a minute... At the same time Firefox would take up 100% usage of a single CPU. Restarting Firefox does not alter its performance.
I guess that the Firefox GUI always spins on some sort of network-oriented lock, which is an odd design causing the 100% CPU occupation...

Comment 15

[hollmeer]

The system freeze problem seems to be still with us after upgrade to FF 91.0.

Updated/upgraded an ubuntu 20.04.2 LTS laptop last night with the latest, also upgrading to FF 91.0, and intentionally tested the problematic webpage (see further above) this morning by opening it and working first with other stuff about half an hour, and then left the FF in front running with the webpage. Returned back after some 25min and observed the laptop frozen, with just a page rendered but nothing updated by JS-scripts, the mouse pointer stuck in an arbitrary position (..however, observed a small nudge of the pointer arrow, just once, but nothing then..], and nothing else could bee done. Ping from an other machine to that laptop indicated 'host not reachable". The fan was humming so the cpu was running with some load, I assume.

..so back to power button, and rebooted the poor thing..

Comment 16

[hollmeer]

Attachment: a /varr/log/syslog portion from a 'frozen' ubuntu with FF91.0, but indicating Xorg as the cause for CPU#1 soft lock

The attached file is related to another comment on suddenly freezing ubuntu with FF 91.0 open, containing a /var/log/syslog portion from a 'frozen' ubuntu with FF91.0 open, but indicating Xorg as the cause for CPU#1 soft lock.

As noted in another comment, I've never experienced system freeze but when FF is open with certain page(s).

Comment 17

[hollmeer]

While trying to explore the occurrence and cause of the ubuntu freeze problem, with an old MacBook running 20.04.2 LTS and FF 91.0, another freeze occurred, with system-monitor window halting to update the resource usage, and also everything else frozen but mouse pointer following with sparse leaps the intended mouse motion.

On another ubuntu box, an attempt to connect to this frozen box seemed to stuck the terminal, but suddenly established the connection, with immediate message:

--clip--
[..ACCOUNT-HIDDEN..]@[..HOSTNAME-1-HIDDEN..]:~$ ssh -X [..ACCOUNT-HIDDEN..]@[..IP-2-HIDDEN..]
Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-80-generic x86_64)

• Documentation: https://help.ubuntu.com
• Management: https://landscape.canonical.com
• Support: https://ubuntu.com/advantage

0 updates can be applied immediately.

Last login: Thu Aug 12 10:13:12 2021 from [..IP-1-HIDDEN..]

Message from syslogd@[..HOSTNAME-2-HIDDEN..] at Aug 12 11:45:52 ...
kernel:[ 5049.040651] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [Xorg:2539]
[..ACCOUNT-HIDDEN..]@[..HOSTNAME-2-HIDDEN..]:~$
Message from syslogd@[..HOSTNAME-2-HIDDEN..] at Aug 12 11:46:20 ...
kernel:[ 5077.070013] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [Xorg:2539]

Message from syslogd@[..HOSTNAME-2-HIDDEN..] at Aug 12 11:46:48 ...
kernel:[ 5105.099283] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [Xorg:2539]

Message from syslogd@[..HOSTNAME-2-HIDDEN..] at Aug 12 11:47:16 ...
kernel:[ 5132.782549] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [Xorg:2539]

Message from syslogd@[..HOSTNAME-2-HIDDEN..] at Aug 12 11:47:44 ...
kernel:[ 5160.811700] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [Xorg:2539]
--clap--

indicating that Xorg process was the cause this time. Not FF WebContent this time.

From there, managed to access and browse the frozen ubuntu's /var/log/syslog, and a portion from the beginning of the freeze is in a file attached into attachments further above.

Eveen though the problem points this time to Xorg, the interesting/crucial thing is that I've NEVER experienced a freeze if FF is NOT open (e.g. with M§ EDGE-DEV)

Comment 18

[hollmeer]

Attachment: another /var/log/syslog portion taken from another freeze, now indicating CPU#0 soft lock related to FF WebContent process

Another /var/log/syslog portion taken from another freeze, now indicating CPU#0 soft lock related to FF WebContent process

Comment 19

[hollmeer]

Just upgraded ubuntu 20.04.02 LTS with normal apt-get update & upgrade, which also updated FF to latest 91.0.1, and as the release notes mention "various stability fixes", curiously run a test by opening the earlier referred website page, and also worked with some other tabs and other applications (Thunderbird, editor, files), running a terminal with "watch -n 2 sensors", and a system-monitor. Also a ssh connection was established from another ubuntu box to this experimenting machine, to see if any messages appear in terminal, in case of a system freeze of the connected machine, as sometimes - but not always - has taken place.

While running the referred page open, working with other applications and/or FF tabs, and time to time bringing the referred website tab in front, to check if everything is running/rendering, the experiment lasted without problems 1 hour 32 min, with the last minute or so, the referred FF tab in front, and then suddenly the webpage rendering was frozen, and the mouse pointer was stuck, and nothing could be done.

No message was written to the ssh terminal on the other box.

While waiting for a while, as nothing could be done, the frozen machine must have been booted by pressing thee power button.

After boot, while searching the logs, some peculiarity was found at the crashing timepoint, in syslog and kern.log:

In syslog, a consecutive string of "\00" was written 231 times. Nothing suspicious before, and next boot's logging thereafter.

In kern.log, a consecutive string of "\00" was written 177 times.

Still no clue, why keeping a FF tab open - even with the latest FF - with the referred webpage open some arbitrary time - but some rather rare cases also with bare any other pages/tabs open, with the referred webpage having been closed even rather long time ago - causes the system freeze (..with either no traces anywhere, with such "\00..." strings on logs, some traces on logs and also maybe in an other machine's ssh terminal, indicating the "BUG: soft lock - CPU#x stuck for xx secs! (Web Content:xxxx)" (or sometimes Xorg:xxxx). But with anything else but such FF tab [..or having been..?] running, whatever time the ubuntu user session open, locked, reopened etc, no problems.

Comment 20

[Wayne Mery (:wsmwk)]

abhishek appears to be gone

Comment 21

[hollmeer]

After upgrading the ubuntu (20.04.03 LTS) with the latest FF 91.0.2, and testing several hours the still possible existence / random-arbitrary occurrence of the potential problem herein, the machine, OS, and Firefox are RUNNING WITH NO PROBLEMS WHATSOEVER, so cautiously and carefully tempted to anticipate that MAYBE THE [SYSTEM] FREEZE PROBLEM IS GONE, although release notes do not explicitly mention or hint to any specific bug fix related directly hereto. Still cautious, and in case of re-occurrence later, an immediate note hereto. Otherwise, iff fully ok hereonwards, and iff the problem was related to FF, welcome back to stability, Firefox!

Comment 22

[Christopher Smith]

Attachment: strace snippet

I'm on 20.04.03 LTS and I'm experiencing something similar to this. It appears to eventually "unstuck" itself, but only after spending a great deal of time in a sleep state. I noticed a subprocess running that seemed to be stalled talking to my (proprietary) display driver, in a kind of loop that eventually seems to time out. Strace -r for that process shows this (/home/$USER replaced with ~ to protect privacy):

0.000010 <... ioctl resumed>, 0x7ffe0cf83750) = 0
0.000010 openat(AT_FDCWD, "~/.nv/nvidia-application-profile-globals-rc", O_RDONLY <unfinished ...>
0.000011 <... openat resumed>) = -1 ENOENT (No such file or directory)
0.000010 openat(AT_FDCWD, "~/.nv/nvidia-application-profiles-rc", O_RDONLY <unfinished ...>
0.000011 <... openat resumed>) = -1 ENOENT (No such file or directory)
0.000010 openat(AT_FDCWD, "~/.nv/nvidia-application-profiles-rc.d", O_RDONLY <unfinished ...>
0.000010 <... openat resumed>) = -1 ENOENT (No such file or directory)
0.000010 openat(AT_FDCWD, "/etc/nvidia/nvidia-application-profiles-rc", O_RDONLY <unfinished ...>
0.000011 <... openat resumed>) = -1 ENOENT (No such file or directory)
0.000010 openat(AT_FDCWD, "/etc/nvidia/nvidia-application-profiles-rc.d/", O_RDONLY) = -1 ENOENT (No such file or directory)
0.000010 openat(AT_FDCWD, "/usr/share/nvidia/nvidia-application-profiles-460.91.03-rc", O_RDONLY <unfinished ...>
0.000010 <... openat resumed>) = 6
0.000010 fstat(6,  <unfinished ...>
0.000010 <... fstat resumed>{st_mode=S_IFREG|0644, st_size=8336, ...}) = 0
0.000011 fstat(6,  <unfinished ...>
0.000011 <... fstat resumed>{st_mode=S_IFREG|0644, st_size=8336, ...}) = 0
0.000016 read(6,  <unfinished ...>
0.000010 <... read resumed>"# Application profiles for the N"..., 8192) = 8192
0.000010 read(6,  <unfinished ...>
0.000009 <... read resumed>"           \"profile\" : \"IdleQueu"..., 4096) = 144
0.000153 close(6)            = 0
0.000031 openat(AT_FDCWD, "/usr/share/nvidia/nvidia-application-profiles-rc", O_RDONLY) = -1 ENOENT (No such file or directory)
0.000087 getpid()            = 45114
0.000035 readlink("/proc/45114/exe", "/usr/lib/firefox/firefox", 4095) = 24
0.000042 openat(AT_FDCWD, "/proc/self/comm", O_RDONLY) = 6
0.000037 fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
0.000030 read(6, "firefox\n", 4096) = 8
0.000029 read(6, "", 3072)   = 0
0.000026 close(6)            = 0
0.000030 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe0cf83750) = 0
0.000054 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe0cf83830) = 0
0.000033 openat(AT_FDCWD, "/proc/driver/nvidia/params", O_RDONLY) = 6
0.000033 fstat(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
0.000029 read(6, "ResmanDebugLevel: 4294967295\nRmL"..., 1024) = 791
0.000037 close(6)            = 0
0.000027 stat("/dev/nvidia0", {st_mode=S_IFCHR|0666, st_rdev=makedev(0xc3, 0), ...}) = 0
0.000032 openat(AT_FDCWD, "/dev/nvidia0", O_RDWR|O_CLOEXEC <unfinished ...>
0.701991 <... openat resumed>) = -1 EIO (Input/output error)
0.000047 openat(AT_FDCWD, "/dev/nvidia0", O_RDWR <unfinished ...>
0.795855 <... openat resumed>) = -1 EIO (Input/output error)
0.000085 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0xd1, 0xc), 0x7ffe0cf83734) = 0
0.000069 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe0cf837a0) = 0
0.000262 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe0cf83900) = 0
0.000237 openat(AT_FDCWD, "/proc/driver/nvidia/params", O_RDONLY) = 6
0.000122 fstat(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
0.000080 read(6, "ResmanDebugLevel: 4294967295\nRmL"..., 1024) = 791
0.000053 close(6)            = 0
0.000029 stat("/dev/nvidia0", {st_mode=S_IFCHR|0666, st_rdev=makedev(0xc3, 0), ...}) = 0
0.000034 openat(AT_FDCWD, "/dev/nvidia0", O_RDWR|O_CLOEXEC <unfinished ...>
0.048327 <... openat resumed>) = -1 EIO (Input/output error)
0.000034 openat(AT_FDCWD, "/dev/nvidia0", O_RDWR <unfinished ...>
0.508494 <... openat resumed>) = -1 EIO (Input/output error)
0.000051 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0xd1, 0xc), 0x7ffe0cf83804) = 0
0.000135 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe0cf83870) = 0
0.000251 futex(0x7f46e556947c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
0.000127 futex(0x7f46e5636370, FUTEX_WAKE_PRIVATE, 2147483647) = 0
0.000084 mincore(0x7f46f08c6000, 4096, [1]) = 0
0.000045 mincore(0x7f46f08c6000, 4096, [1]) = 0
0.000042 mincore(0x7f46f08c6000, 4096, [1]) = 0

Those long "openat" delays seem to be the culprit.

Comment 23

[Christopher Smith]

I'm on 20.04.03 LTS and I'm experiencing something similar to this. It appears to eventually "unstuck" itself, but only after spending a great deal of time in a sleep state. I noticed a subprocess running that seemed to be stalled talking to my (proprietary) display driver, in a kind of loop that eventually seems to time out. Strace -r for that process shows this (/home/$USER replaced with ~ to protect privacy):

0.000010 <... ioctl resumed>, 0x7ffe0cf83750) = 0
0.000010 openat(AT_FDCWD, "/.nv/nvidia-application-profile-globals-rc", O_RDONLY <unfinished ...>
0.000011 <... openat resumed>) = -1 ENOENT (No such file or directory)
0.000010 openat(AT_FDCWD, "/.nv/nvidia-application-profiles-rc", O_RDONLY <unfinished ...>
0.000011 <... openat resumed>) = -1 ENOENT (No such file or directory)
0.000010 openat(AT_FDCWD, "~/.nv/nvidia-application-profiles-rc.d", O_RDONLY <unfinished ...>
0.000010 <... openat resumed>) = -1 ENOENT (No such file or directory)
0.000010 openat(AT_FDCWD, "/etc/nvidia/nvidia-application-profiles-rc", O_RDONLY <unfinished ...>
0.000011 <... openat resumed>) = -1 ENOENT (No such file or directory)
0.000010 openat(AT_FDCWD, "/etc/nvidia/nvidia-application-profiles-rc.d/", O_RDONLY) = -1 ENOENT (No such file or directory)
0.000010 openat(AT_FDCWD, "/usr/share/nvidia/nvidia-application-profiles-46> 0.91.03-rc", O_RDONLY <unfinished ...>
0.000010 <... openat resumed>) = 6
0.000010 fstat(6, <unfinished ...>
0.000010 <... fstat resumed>{st_mode=S_IFREG|0644, st_size=8336, ...}) = 0
0.000011 fstat(6, <unfinished ...>
0.000011 <... fstat resumed>{st_mode=S_IFREG|0644, st_size=8336, ...}) = 0
0.000016 read(6, <unfinished ...>
0.000010 <... read resumed>"# Application profiles for the N"..., 8192) = 8192
0.000010 read(6, <unfinished ...>
0.000009 <... read resumed>" "profile" : "IdleQueu"..., 4096) = 144
0.000153 close(6) = 0
0.000031 openat(AT_FDCWD, "/usr/share/nvidia/nvidia-application-profiles-rc", O_RDONLY) = -1 ENOENT (No such file or directory)
0.000087 getpid() = 45114
0.000035 readlink("/proc/45114/exe", "/usr/lib/firefox/firefox", 4095) = 24
0.000042 openat(AT_FDCWD, "/proc/self/comm", O_RDONLY) = 6
0.000037 fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
0.000030 read(6, "firefox\n", 4096) = 8
0.000029 read(6, "", 3072) = 0
0.000026 close(6) = 0
0.000030 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe0cf83750) = 0
0.000054 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe0cf83830) = 0
0.000033 openat(AT_FDCWD, "/proc/driver/nvidia/params", O_RDONLY) = 6
0.000033 fstat(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
0.000029 read(6, "ResmanDebugLevel: 4294967295\nRmL"..., 1024) = 791
0.000037 close(6) = 0
0.000027 stat("/dev/nvidia0", {st_mode=S_IFCHR|0666, st_rdev=makedev(0xc3, 0), ...}) = 0
0.000032 openat(AT_FDCWD, "/dev/nvidia0", O_RDWR|O_CLOEXEC <unfinished ...>
0.701991 <... openat resumed>) = -1 EIO (Input/output error)
0.000047 openat(AT_FDCWD, "/dev/nvidia0", O_RDWR <unfinished ...>
0.795855 <... openat resumed>) = -1 EIO (Input/output error)
0.000085 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0xd1, 0xc), 0x7ffe0cf83734) = 0
0.000069 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe0cf837a0) = 0
0.000262 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe0cf83900) = 0
0.000237 openat(AT_FDCWD, "/proc/driver/nvidia/params", O_RDONLY) = 6
0.000122 fstat(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
0.000080 read(6, "ResmanDebugLevel: 4294967295\nRmL"..., 1024) = 791
0.000053 close(6) = 0
0.000029 stat("/dev/nvidia0", {st_mode=S_IFCHR|0666, st_rdev=makedev(0xc3, 0), ...}) = 0
0.000034 openat(AT_FDCWD, "/dev/nvidia0", O_RDWR|O_CLOEXEC <unfinished ...>
0.048327 <... openat resumed>) = -1 EIO (Input/output error)
0.000034 openat(AT_FDCWD, "/dev/nvidia0", O_RDWR <unfinished ...>
0.508494 <... openat resumed>) = -1 EIO (Input/output error)
0.000051 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0xd1, 0xc), 0x7ffe0cf83804) = 0
0.000135 ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe0cf83870) = 0
0.000251 futex(0x7f46e556947c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
0.000127 futex(0x7f46e5636370, FUTEX_WAKE_PRIVATE, 2147483647) = 0
0.000084 mincore(0x7f46f08c6000, 4096, [1]) = 0
0.000045 mincore(0x7f46f08c6000, 4096, [1]) = 0
0.000042 mincore(0x7f46f08c6000, 4096, [1]) = 0

Those long "openat" delays seem to be the culprit.

Comment 24

[ottomaani138]

Hey all!

I recently upgraded ( = fresh install to a new SSD ) to Ubuntu 20.04.03, and I'm having daily out of memory crashes when waking up my system from sleep, IF I leave Firefox open. When trying to log back into my session, I'll get the login screen, after which the fans start furiously working, and I get a complete freeze for ~20min. After the waiting period, the kernel will kill the Firefox process, and let's me log in (without Firefox being open anymore, obviously). The only way for my system to safely fall asleep and wake up from it, is to remember to quit Firefox before going to sleep, which I sometimes forget. This always costs me 20 min, which is infuriating when in a hurry.

I don't have huge amounts of RAM in my system, but this consistent wake-up crash wasn't something I was experiencing with my previous Ubuntu 18.04 on the same machine, so I thought I'd report on this.

If I can provide some logs from the next crash, let me know!

Comment 25

[pranav.tech]

Ubuntu 20.04, 16 GB RAM, i5 11 gen CPU, and latest firefox. Very less extension, firefox regularly goes into this strange mode of 100% CPU. The entire system freezes, unable to move mouse hardly. If I am lucky, I do kill-all firefox-bin, and save myself. Otherwise will have to press hard reset button. Although I am trying to support firefox much, I change my system completely, but some or other way firefox will cause issues if many tabs.

Please help.. also my dev work cannot happen in safe-mode.

Comment 26

[Gustavo Homem]

I have come to the conclusion that most of such situations are due to memory consumption. Ubuntu does not degrade in speed proportionally to the memory consumption but rather halts out of a sudden when a certain threshold is reached.... and it stays that way until the OOM kills some processes (usually Firefox tabs). The systems I manage all have a memory indicator on the KDE systray and we even have a script that launches a systray notification whenever memory is under 500 MB.

The part where Firefox could be responsible is that the memory consumption does not seem to decrease when tabs are closed so it needs to be restarted from time to time.

The rest is OS management.

Comment 27

[abhishek suvarna]

(In reply to pranav.tech from comment #25)

Ubuntu 20.04, 16 GB RAM, i5 11 gen CPU, and latest firefox. Very less extension, firefox regularly goes into this strange mode of 100% CPU. The entire system freezes, unable to move mouse hardly. If I am lucky, I do kill-all firefox-bin, and save myself. Otherwise will have to press hard reset button. Although I am trying to support firefox much, I change my system completely, but some or other way firefox will cause issues if many tabs.

Please help.. also my dev work cannot happen in safe-mode.

I had similar issues and i sorted it by kernal upgrade only udate can resolve such issue it depends which version of kernal you choose and I have done it long back.... I hope it work for you also.

Comment 28

[pranav.tech]

I am using Linux 5.11.0-37-generic. And Firefox 93.0 (64 bit). Luckily twice I was able to open system monitor when this system freeze happened, in both cases - CPU was hitting 100% and I think memory was at its limit too (16 GB). I think there is definitely issue how firefox manages cpu/ram when too many tabs open because never faced with chrome.

Comment 29

[Andrei Purice]

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Comment 30

[oliver.cg89]

I'm using Linux 5.13.0-21-generic and Firefox Developer Edition 95b4, and I can confirm that I'm experiencing the same on Ubuntu 21.04 and now in the upgraded version 21.10.

When it happens, sometimes Firefox simply closes after some minutes and I can continue working by opening it again. Some other cases the only solution is to reboot it manually. I can confirm that the CPU hits 100% in my case too.

Comment 31

[nicolas]

Hello,
I'm facing the same issue with Firefox 94.0, and I'm starting to face the exact same freeze issue with Thunderbird 91.2.1 : the mouse cursor can still move, yet I can click nowhere, and there is not workaround but to hard button-reset my computer.

(Xubuntu 21.10)

Comment 32

[Emilio Cobos Álvarez (:emilio)]

When you kill firefox, can you kill it using kill -11 <pid>? That should bring up the crash reporter and allow us to see what's going on in your system.

Comment 33

[Darkspirit]

Do you hear crackling audio before the freeze occurs? There is a Rust/LLVM incompatibility plaguing Debian and OpenSUSE distro builds: bug 1740260

Comment 34

[Bob]

Ubuntu linux 5.4.0-90-generic, Firefox 94.0 crashes system. The cursor can be moved but nothing can be selected from GUI. The only option is a hard reset of laptop.

Watching video in past cases has caused similar issue. While using google maps today the issue appeared again.

Comment 35

[Bob]

The freeze occurs when using the zoom buttons on Google maps.

No info is showing in FIrefox under about:crashes. I looked in Ubuntu under /var/crash and a log doesn't appear after hard reset.

Comment 36

[Bob]

This message repeats frequently in syslog:

Nov 14 20:04:21 rg-HP-x360 gnome-shell[3727]: [GFX1-]: Failed to connect WebRenderBridgeChild.
Nov 14 20:04:21 rg-HP-x360 gnome-shell[3856]: [GFX1-]: Failed to connect WebRenderBridgeChild.
Nov 14 20:04:21 rg-HP-x360 gnome-shell[3557]: [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate
Nov 14 20:04:21 rg-HP-x360 gnome-shell[3557]: IPDL protocol error: Handler returned error code!
Nov 14 20:04:21 rg-HP-x360 gnome-shell[3557]: ###!!! [Parent][DispatchSyncMessage] Error: PCompositorBridge::Msg_NotifyChildRecreated Processing error: message was deserialized, but the handler returned false (indicating failure)
Nov 14 20:04:21 rg-HP-x360 gnome-shell[3557]: IPDL protocol error: Handler returned error code!
Nov 14 20:04:21 rg-HP-x360 gnome-shell[3557]: ###!!! [Parent][DispatchSyncMessage] Error: PCompositorBridge::Msg_NotifyChildRecreated Processing error: message was deserialized, but the handler

Comment 37

[Gustavo Homem]

People who are having this issue: are you monitoring the memory consumption?

This problem stopped happening to me (and the people I work with) the moment we started having a memory applet in the systray and a popup everytime memory goes under 500M. It would be useful to confirm if this situation still happens to people under a situation where memory consumption is controlled.

Comment 38

[hollmeer]

Just for curiosity, browsed through the increasing spree of messages from various users posting [Your] experiences still with the issue here.

Just for the record, since my last message about 3 months ago, I've NOT experienced ANY such stalls/freezes, which I could have related directly to my earlier experienced FF-open-and-running -related system-freeze.

There has been some very rare cases where I had to hard reboot the [somewhat older] MacBook via power button. But I was not entirely convinced that such any such case was directly related to FF. There has been ONLY two or three such mysterious cases totally (..since my last message, where I was reporting/pondering if the FF got back to stability re this issue..).

As always updated the latest with apt-get update & upgrade, currently running

FF 94.0
Ubuntu 20.04.3LTS
5.4.0-90-generic x86_64 GNU/Linux
system RAM 8GB

without any directly identified/experienced problems re this system freeze issue.

Curiosity emerges, what might be the crucial difference [..if any..?] re the contexts/systems-configs/[resource-]usage-profiles of the increasingly growing experiences from others.

Comment 39

[Martin Stránský [:stransky] (ni? me)]

Bob, please attach your about:support page. There are some options how to tweak it:

1. Test Mozilla binaries:
   https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries

2. Disable EGL backend (set gfx.x11-egl.force-disabled to true at about:support and restart browser)

3. Disable WebRender:
   https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Check_WebRender

Comment 40

[Bob]

Attachment: Firefox_about:support

Firefox about:support text :: WebRender freeze

Comment 41

[iamspeedcubing]

I'm having this same issue even today on Ubuntu 20.04.3 LTS.

Comment 42

[ottomaani138]

(In reply to Gustavo Homem from comment #37)

People who are having this issue: are you monitoring the memory consumption?

This problem stopped happening to me (and the people I work with) the moment we started having a memory applet in the systray and a popup everytime memory goes under 500M. It would be useful to confirm if this situation still happens to people under a situation where memory consumption is controlled.

In response to this, and also as a continuation to my earlier post from 3 months ago (which I quoted below).
Yes, in my case it's 100% memory related. Since my earlier post, I've also added a memory monitoring bash-script to my system, giving me notifications when available memory goes below 500M. This saves me from runtime crashes, but requires me to manually do all the memory cleanup routines from about:memory every now and then, and also restart my browser to free up resources. I don't know if it's Firefox's or OS's duty to keep Firefox from clogging up all the resources, but memory management is definitely the cause for the behavior.

In my original post, I reported this thing of Firefox causing my OS not to wake up from sleep before it's killed by the OS, which takes some 20 minutes. This is also 100% memory related, and used to not happen with my previous Ubuntu setup on the same machine. Since then, I've always closed Firefox if I leave the computer, to not have to wait 20min to get back to work.

(In reply to ottomaani138 from comment #24)

I recently upgraded ( = fresh install to a new SSD ) to Ubuntu 20.04.03, and I'm having daily out of memory crashes when waking up my system from sleep, IF I leave Firefox open.

Comment 43

[devaux]

Can confirm. Happens here on Ubuntu 21.10 with Firefox (but also Chrome, Chromium, Brave, Electum base things...), too. System takes 100% memory (16GB installed), starts to swap to disk and then the computer freezes for about 5 minutes.
Having this on multiple Linux-based (Ubuntu, Manjaro, Arch...) computers/laptops since a year or so. Don't know how to solve...

Comment 44

[oliver.cg89]

(In reply to devaux from comment #43)

Can confirm. Happens here on Ubuntu 21.10 with Firefox (but also Chrome, Chromium, Brave, Electum base things...), too. System takes 100% memory (16GB installed), starts to swap to disk and then the computer freezes for about 5 minutes.
Having this on multiple Linux-based (Ubuntu, Manjaro, Arch...) computers/laptops since a year or so. Don't know how to solve...

That's exactly what I'm experiencing since Ubuntu 21.04. I'm not sure if I mentioned before, but I'm using VMware Fusion 12.2.1 (18811640) and macOS Monterey 12.0.1 (21A559) as the host OS.

Comment 45

[hollmeer]

While serendipitously NOT experiencing the system-freezing issue during recent months but only a few rare cases - the last mysterious one encountered during a long-lasted ZOOM-session with FF when the system got unresponsively frozen and had to power-button-boot the laptop - I have been pondering a potential difference, and while observing the various memory-related clues, some thoughts leaned towards also to my swap partition, which I have configured still as a separate 10 GB partition, as the suspend/hibernate seems to corrupt the swap for resuming if used as file-configured. So just pondering with some more potential hints and directions to find the root-cause - maybe-maybe-not - any possibility that the swap hits the ceiling (if as file, or even as too small as a partition)..

I'm currently consuming 6.0GB of 8.1GB RAM, and 2.7GB of 10GB swap-partition while working with some[time rather] memory-consuming AI (and that app not running just now), other stuff plus also FF open. The typically same use profile was also when I last time met the unfortunate system freeze so tempted to entertain a thought - re the discussions here recently over various memory-related aspects/clues - that had the system hit ceiling maybe. And as a partition config not a out-of-the-box at install, maybe onto something from there (..towards rather then an OS system problem?)

..OR even that - assuming that at least some others reporting here use file-based swap - is NOT THE difference for NOT encountering the freeze..

Comment 46

[Michael]

Having a huge issue with 97.0a1.
Freezes constantly everytime I enter preferences, and hit the Home section. Tried older 9x.xx versions, that does the same, I'm on Kubuntu 14.04 cause my "old" HP Elitebook i7 won't boot the newer kernels at all. That's why I'm still caught on the old version. and doing "standalone" browsers.
Didn't have that issue before I did a clean install with the 94-95 nightly builds, but still a freeze once in a while. Mozilla updated the older versions packages with some from the newer nightly builds? that's just my thought.

Using a HP Elitebook 8550w i7 with 8GB RAM. Yeah it's a 4-core i7, guess that's already too old for linux. I'm guessing I'm going to ditch Ubuntu/Kubuntu for good now.

Comment 47

[Michael]

(In reply to Michael from comment #46)

Having a huge issue with 97.0a1.
Freezes constantly everytime I enter preferences, and hit the Home section. Tried older 9x.xx versions, that does the same, I'm on Kubuntu 14.04 cause my "old" HP Elitebook i7 won't boot the newer kernels at all. That's why I'm still caught on the old version. and doing "standalone" browsers.
Didn't have that issue before I did a clean install with the 94-95 nightly builds, but still a freeze once in a while. Mozilla updated the older versions packages with some from the newer nightly builds? that's just my thought.

Using a HP Elitebook 8550w i7 with 8GB RAM. Yeah it's a 4-core i7, guess that's already too old for linux. I'm guessing I'm going to ditch Ubuntu/Kubuntu for good now.

Sorry, that's a HP Elitebook 8560w

Comment 48

[Michael]

Maybe a trick from M$ to push Linux users to start using Edge Browser? It already surely stinks that way.

Comment 49

[Peter Felix Schuster]

I got the same problem with an old MacBook Pro 15" (approx. 2009 build). It freezes very fast after start, most of the time when I search on Google.

Comment 50

[Darkspirit]

• Does anyone have set gfx.webrender.software.opengl to true? Please set it back to false (bug 1745582).
• Please file an own bug.
  • Put this bug ("1664798") into "See Also".
  • Open about:support, click on "Copy text to clipboard" and paste it into the "Add an attachment" field.
  • If possible, please try to find a regression range. Most likely it is necessary to narrow down the problem. Example:
    $ sudo apt install python3-pip
$ pip3 install --user mozregression
$ ~/.local/bin/mozregression --good 93 --bad 2021-12-15 --pref gfx.webrender.all:true
    Test all builds, you'll get a pushlogURL at the end.
  • Does the problem still occur with https://nightly.mozilla.org?
    If not, please try to find out what fixed the bug and ask for a backport:
    $ ~/.local/bin/mozregression --find-fix --bad 95 --good 2021-12-15 --pref gfx.webrender.all:true
  • Try taking an anonymized memory report on about:memory and attach it to your bug.
  • Try taking a performance profile with https://profiler.firefox.com:
    1. Click on "Enable Firefox Profiler Menu Button"
    2. Select "Graphics" in the Settings dropdown
    3. Start Recording
    4. Reproduce the problem
    5. Click on the blue profiler button next to the main menu button to end the recording
    6. Click on "Upload Local Profile" and "Upload"
    7. Post the https://share.firefox.dev/ url in your bug

Comment 51

[nicolas]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #39)

Bob, please attach your about:support page. There are some options how to tweak it:

1. Test Mozilla binaries:
   https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries

2. Disable EGL backend (set gfx.x11-egl.force-disabled to true at about:support and restart browser)

3. Disable WebRender:
   https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Check_WebRender

Hello,

After experiencing months of VERY consistent, frequent, reproducible events I've witnessed on Firefox AND Thunderbird, as a complete freeze (except the mouse cursor moving) of the system, forcing me to hard reset, I tried the workaround above and it totally solved the problem.
When the issue appeared, I still was able to connect via SSH, and have a look at the /var/log/kern.log and syslog.
Every time, the graphic "nouveau" driver was involved, with some errors related to "nouveau", but I've NEVER noticed any relation between these freeze events and any MEMORY issues (neither any over filling, nor even any significant raise of memory consumption).

I've used this workaround on both FF the TB and it fixed the problem.

Comment 52

[Martin Stránský [:stransky] (ni? me)]

Nicolas, hich option (1, 2 or 3) does work for you?
Thanks.

Comment 53

[nicolas]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #52)

Nicolas, hich option (1, 2 or 3) does work for you?
Thanks.

2 and 3

(related to gfx and disabling webrender)

Comment 54

[u699616]

About a year ago I have had exactly this same problem with Firefox. For a while, I thought it was a problem with my computer, until I realized that there was no memory problem, not even high consumption. I will try Martin Stránský's suggestions and see if they work.

Comment 55

[u699616]

(In reply to edson.asnt from comment #54)

About a year ago I have had exactly this same problem with Firefox. For a while, I thought it was a problem with my computer, until I realized that there was no memory problem, not even high consumption. I will try Martin Stránský's suggestions and see if they work.

Informações básicas sobre o aplicativo

Nome: Firefox
Versão: 96.0
ID da compilação: 20220106144528
ID da distribuição: canonical
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0
Sistema operacional: Linux 5.11.0-46-generic #51~20.04.1-Ubuntu SMP Fri Jan 7 06:51:40 UTC 2022
Tema do sistema operacional: Yaru-dark / Yaru
Janelas multiprocessadas: 1/1
Janelas do Fission: 1/1 Ativado para liberação em implementação gradual
Processos remotos: 5
Diretivas empresariais: Inativo
Chave do Serviço de Localização do Google: Encontrado
Chave do Google Safebrowsing: Encontrado
Chave do serviço de localização da Mozilla: Faltando
Modo de segurança: false

Relatórios de travamento dos últimos 3 dias

Recursos do Firefox

Nome: DoH Roll-Out
Versão: 2.0.0
ID: [e-mail]

Nome: Firefox Screenshots
Versão: 39.0.1
ID: [e-mail]

Nome: Form Autofill
Versão: 1.0.1
ID: [e-mail]

Nome: Picture-In-Picture
Versão: 1.0.0
ID: [e-mail]

Nome: Proxy Failover
Versão: 1.0.2
ID: [e-mail]

Nome: Web Compatibility Interventions
Versão: 29.2.0
ID: [e-mail]

Nome: WebCompat Reporter
Versão: 1.4.2
ID: [e-mail]

Recursos remotos

bug-1690367-rollout-moving-webrtc-networking-functionality-into-i-release-87-100: active
bug-1732206-rollout-fission-release-rollout-release-94-95: active
bug-1750257-rollout-pref-off-networkcookiesamesiteschemeful-in-release-96-96: active

Processos remotos

Tipo: Página 'about' privilegiada
Quantidade: 1

Tipo: Extensão
Quantidade: 1

Tipo: Pré-alocado
Quantidade: 3

Extensões

Nome: Add-ons Search Detection
Tipo: extension
Versão: 2.0.0
Ativado: true
ID: [e-mail]

Nome: Bing
Tipo: extension
Versão: 1.3
Ativado: true
ID: [e-mail]

Nome: Bitwarden
Tipo: extension
Versão: 1.55.0
Ativado: true
ID: {446900e4-71c2-419f-a6a7-df9c091e268b}

Nome: DuckDuckGo
Tipo: extension
Versão: 1.1
Ativado: true
ID: [e-mail]

Nome: Google
Tipo: extension
Versão: 1.1
Ativado: true
ID: [e-mail]

Nome: MercadoLivre
Tipo: extension
Versão: 1.0
Ativado: true
ID: [e-mail]

Nome: uBlock Origin
Tipo: extension
Versão: 1.40.8
Ativado: true
ID: [e-mail]

Nome: Wikipedia (pt)
Tipo: extension
Versão: 1.1
Ativado: true
ID: [e-mail]

Nome: English (CA) Language Pack
Tipo: locale
Versão: 96.0buildid20220106.144528
Ativado: true
ID: [e-mail]

Nome: English (GB) Language Pack
Tipo: locale
Versão: 96.0buildid20220106.144528
Ativado: true
ID: [e-mail]

Nome: Português (Europeu) Language Pack
Tipo: locale
Versão: 96.0buildid20220106.144528
Ativado: true
ID: [e-mail]

Nome: Português (pt-BR) Language Pack
Tipo: locale
Versão: 96.0buildid20220106.144528
Ativado: true
ID: [e-mail]

Gráficos

Funcionalidades
Composição: WebRender
Deslocamento/Zoom assíncrono: entrada com roda do mouse ativada; arrasto da barra de rolagem ativado; teclado ativado; rolagem automática ativada; zoom suave com gesto de pinça ativado
Info WSI do driver WebGL 1: EGL_VENDOR: Mesa Project EGL_VERSION: 1.5 EGL_EXTENSIONS: EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync EGL_CHROMIUM_sync_control EGL_EXT_buffer_age EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_EXT_swap_buffers_with_damage EGL_IMG_context_priority EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_KHR_swap_buffers_with_damage EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_image_dma_buf_export EGL_MESA_query_driver EGL_NOK_texture_from_pixmap EGL_WL_bind_wayland_display EGL_EXTENSIONS(nullptr): EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_device EGL_EXT_platform_wayland EGL_KHR_platform_wayland EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_MESA_platform_xcb EGL_MESA_platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless IsWebglOutOfProcessEnabled: 0
Renderizador do driver WebGL 1: Intel -- Mesa Intel(R) HD Graphics 5500 (BDW GT2)
Versão do driver WebGL 1: 4.6 (Compatibility Profile) Mesa 21.0.3
Extensões do driver WebGL 1: GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB GL_ARB_multitexture GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat GL_3DFX_texture_compression_FXT1 GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_transpose_matrix GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_secondary_color GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_S3_s3tc GL_SUN_multi_draw_arrays GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos GL_NV_packed_depth_stencil GL_NV_texture_rectangle GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_window_pos GL_ATI_fragment_shader GL_EXT_stencil_two_side GL_EXT_texture_cube_map GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fog_distance GL_NV_half_float GL_APPLE_packed_pixels GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_shader_objects GL_ARB_vertex_program GL_ARB_vertex_shader GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_MESA_pack_invert GL_NV_primitive_restart GL_ARB_depth_clamp GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_occlusion_query2 GL_ARB_point_sprite GL_ARB_shading_language_100 GL_ARB_sync GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object GL_ATI_blend_equation_separate GL_EXT_blend_equation_separate GL_OES_read_format GL_ARB_color_buffer_float GL_ARB_pixel_buffer_object GL_ARB_texture_compression_rgtc GL_ARB_texture_float GL_ARB_texture_rectangle GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_ARB_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_packed_depth_stencil GL_ARB_vertex_array_object GL_ATI_separate_stencil GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_texture_array GL_EXT_texture_integer GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_OES_EGL_image GL_AMD_performance_monitor GL_EXT_texture_buffer_object GL_AMD_texture_texture4 GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_draw_instanced GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_map_buffer_range GL_ARB_texture_buffer_object GL_ARB_texture_rg GL_ARB_texture_swizzle GL_ARB_vertex_array_bgra GL_EXT_texture_swizzle GL_EXT_vertex_array_bgra GL_NV_conditional_render GL_AMD_conservative_depth GL_AMD_draw_buffers_blend GL_AMD_seamless_cubemap_per_texture GL_ARB_ES2_compatibility GL_ARB_blend_func_extended GL_ARB_compatibility GL_ARB_debug_output GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_explicit_attrib_location GL_ARB_fragment_coord_conventions GL_ARB_provoking_vertex GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_shader_texture_lod GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_multisample GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_uniform_buffer_object GL_ARB_vertex_type_2_10_10_10_rev GL_EXT_provoking_vertex GL_EXT_texture_snorm GL_MESA_texture_signed_rgba GL_NV_copy_image GL_NV_texture_barrier GL_ARB_draw_indirect GL_ARB_get_program_binary GL_ARB_gpu_shader5 GL_ARB_gpu_shader_fp64 GL_ARB_robustness GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_precision GL_ARB_shader_subroutine GL_ARB_texture_compression_bptc GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_viewport_array GL_EXT_direct_state_access GL_EXT_vertex_attrib_64bit GL_AMD_multi_draw_indirect GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ARB_base_instance GL_ARB_compressed_texture_pixel_storage GL_ARB_conservative_depth GL_ARB_internalformat_query GL_ARB_map_buffer_alignment GL_ARB_shader_atomic_counters GL_ARB_shader_image_load_store GL_ARB_shading_language_420pack GL_ARB_shading_language_packing GL_ARB_texture_storage GL_ARB_transform_feedback_instanced GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_transform_feedback GL_AMD_query_buffer_object GL_AMD_shader_trinary_minmax GL_AMD_vertex_shader_layer GL_AMD_vertex_shader_viewport_index GL_ARB_ES3_compatibility GL_ARB_arrays_of_arrays GL_ARB_clear_buffer_object GL_ARB_compute_shader GL_ARB_copy_image GL_ARB_explicit_uniform_location GL_ARB_fragment_layer_viewport GL_ARB_framebuffer_no_attachments GL_ARB_invalidate_subdata GL_ARB_multi_draw_indirect GL_ARB_program_interface_query GL_ARB_robust_buffer_access_behavior GL_ARB_shader_image_size GL_ARB_shader_storage_buffer_object GL_ARB_stencil_texturing GL_ARB_texture_buffer_range GL_ARB_texture_query_levels GL_ARB_texture_storage_multisample GL_ARB_texture_view GL_ARB_vertex_attrib_binding GL_KHR_debug GL_KHR_robustness GL_KHR_texture_compression_astc_ldr GL_AMD_pinned_memory GL_ARB_buffer_storage GL_ARB_clear_texture GL_ARB_compute_variable_group_size GL_ARB_enhanced_layouts GL_ARB_indirect_parameters GL_ARB_internalformat_query2 GL_ARB_multi_bind GL_ARB_query_buffer_object GL_ARB_seamless_cubemap_per_texture GL_ARB_shader_draw_parameters GL_ARB_shader_group_vote GL_ARB_shading_language_include GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_stencil8 GL_ARB_vertex_type_10f_11f_11f_rev GL_EXT_shader_integer_mix GL_INTEL_performance_query GL_ARB_ES3_1_compatibility GL_ARB_clip_control GL_ARB_conditional_render_inverted GL_ARB_cull_distance GL_ARB_derivative_control GL_ARB_direct_state_access GL_ARB_get_texture_sub_image GL_ARB_pipeline_statistics_query GL_ARB_shader_texture_image_samples GL_ARB_texture_barrier GL_ARB_transform_feedback_overflow_query GL_EXT_polygon_offset_clamp GL_KHR_blend_equation_advanced GL_KHR_context_flush_control GL_KHR_robust_buffer_access_behavior GL_ARB_gpu_shader_int64 GL_ARB_parallel_shader_compile GL_ARB_shader_atomic_counter_ops GL_ARB_shader_ballot GL_ARB_shader_clock GL_ARB_shader_viewport_layer_array GL_EXT_shader_samples_identical GL_EXT_texture_sRGB_R8 GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_ARB_gl_spirv GL_ARB_spirv_extensions GL_MESA_shader_integer_functions GL_ARB_polygon_offset_clamp GL_ARB_texture_filter_anisotropic GL_EXT_semaphore GL_EXT_semaphore_fd GL_KHR_parallel_shader_compile GL_EXT_EGL_image_storage GL_EXT_shader_framebuffer_fetch_non_coherent GL_EXT_texture_shadow_lod GL_INTEL_blackhole_render GL_INTEL_shader_integer_functions2 GL_MESA_framebuffer_flip_y GL_NV_compute_shader_derivatives GL_EXT_EGL_sync GL_EXT_demote_to_helper_invocation
Extensões WebGL 1: ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_float_blend EXT_frag_depth EXT_shader_texture_lod EXT_sRGB EXT_texture_compression_bptc EXT_texture_compression_rgtc EXT_texture_filter_anisotropic MOZ_debug OES_element_index_uint OES_fbo_render_mipmap OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object WEBGL_color_buffer_float WEBGL_compressed_texture_astc WEBGL_compressed_texture_etc WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context
Info WSI do driver WebGL 2: EGL_VENDOR: Mesa Project EGL_VERSION: 1.5 EGL_EXTENSIONS: EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync EGL_CHROMIUM_sync_control EGL_EXT_buffer_age EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_EXT_swap_buffers_with_damage EGL_IMG_context_priority EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_KHR_swap_buffers_with_damage EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_image_dma_buf_export EGL_MESA_query_driver EGL_NOK_texture_from_pixmap EGL_WL_bind_wayland_display EGL_EXTENSIONS(nullptr): EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_device EGL_EXT_platform_wayland EGL_KHR_platform_wayland EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_MESA_platform_xcb EGL_MESA_platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless IsWebglOutOfProcessEnabled: 0
Renderizador do driver WebGL 2: Intel -- Mesa Intel(R) HD Graphics 5500 (BDW GT2)
Versão do driver WebGL 2: 4.6 (Core Profile) Mesa 21.0.3
Extensões do driver WebGL 2: GL_3DFX_texture_compression_FXT1 GL_AMD_conservative_depth GL_AMD_draw_buffers_blend GL_AMD_gpu_shader_int64 GL_AMD_multi_draw_indirect GL_AMD_performance_monitor GL_AMD_pinned_memory GL_AMD_query_buffer_object GL_AMD_seamless_cubemap_per_texture GL_AMD_shader_trinary_minmax GL_AMD_texture_texture4 GL_AMD_vertex_shader_layer GL_AMD_vertex_shader_viewport_index GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ARB_ES2_compatibility GL_ARB_ES3_1_compatibility GL_ARB_ES3_2_compatibility GL_ARB_ES3_compatibility GL_ARB_arrays_of_arrays GL_ARB_base_instance GL_ARB_blend_func_extended GL_ARB_buffer_storage GL_ARB_clear_buffer_object GL_ARB_clear_texture GL_ARB_clip_control GL_ARB_compressed_texture_pixel_storage GL_ARB_compute_shader GL_ARB_compute_variable_group_size GL_ARB_conditional_render_inverted GL_ARB_conservative_depth GL_ARB_copy_buffer GL_ARB_copy_image GL_ARB_cull_distance GL_ARB_debug_output GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_derivative_control GL_ARB_direct_state_access GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_draw_indirect GL_ARB_draw_instanced GL_ARB_enhanced_layouts GL_ARB_explicit_attrib_location GL_ARB_explicit_uniform_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_layer_viewport GL_ARB_fragment_shader GL_ARB_framebuffer_no_attachments GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_get_program_binary GL_ARB_get_texture_sub_image GL_ARB_gl_spirv GL_ARB_gpu_shader5 GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader_int64 GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_indirect_parameters GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_internalformat_query2 GL_ARB_invalidate_subdata GL_ARB_map_buffer_alignment GL_ARB_map_buffer_range GL_ARB_multi_bind GL_ARB_multi_draw_indirect GL_ARB_occlusion_query2 GL_ARB_parallel_shader_compile GL_ARB_pipeline_statistics_query GL_ARB_pixel_buffer_object GL_ARB_point_sprite GL_ARB_polygon_offset_clamp GL_ARB_program_interface_query GL_ARB_provoking_vertex GL_ARB_query_buffer_object GL_ARB_robust_buffer_access_behavior GL_ARB_robustness GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_seamless_cubemap_per_texture GL_ARB_separate_shader_objects GL_ARB_shader_atomic_counter_ops GL_ARB_shader_atomic_counters GL_ARB_shader_ballot GL_ARB_shader_bit_encoding GL_ARB_shader_clock GL_ARB_shader_draw_parameters GL_ARB_shader_group_vote GL_ARB_shader_image_load_store GL_ARB_shader_image_size GL_ARB_shader_objects GL_ARB_shader_precision GL_ARB_shader_storage_buffer_object GL_ARB_shader_subroutine GL_ARB_shader_texture_image_samples GL_ARB_shader_texture_lod GL_ARB_shader_viewport_layer_array GL_ARB_shading_language_420pack GL_ARB_shading_language_include GL_ARB_shading_language_packing GL_ARB_spirv_extensions GL_ARB_stencil_texturing GL_ARB_sync GL_ARB_tessellation_shader GL_ARB_texture_barrier GL_ARB_texture_buffer_object GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_buffer_range GL_ARB_texture_compression_bptc GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map_array GL_ARB_texture_filter_anisotropic GL_ARB_texture_float GL_ARB_texture_gather GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_query_levels GL_ARB_texture_query_lod GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_stencil8 GL_ARB_texture_storage GL_ARB_texture_storage_multisample GL_ARB_texture_swizzle GL_ARB_texture_view GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_transform_feedback_instanced GL_ARB_transform_feedback_overflow_query GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_attrib_64bit GL_ARB_vertex_attrib_binding GL_ARB_vertex_buffer_object GL_ARB_vertex_shader GL_ARB_vertex_type_10f_11f_11f_rev GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ATI_blend_equation_separate GL_ATI_texture_float GL_EXT_EGL_image_storage GL_EXT_EGL_sync GL_EXT_abgr GL_EXT_blend_equation_separate GL_EXT_demote_to_helper_invocation GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_polygon_offset_clamp GL_EXT_provoking_vertex GL_EXT_semaphore GL_EXT_semaphore_fd GL_EXT_shader_framebuffer_fetch_non_coherent GL_EXT_shader_integer_mix GL_EXT_shader_samples_identical GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_sRGB GL_EXT_texture_sRGB_R8 GL_EXT_texture_sRGB_decode GL_EXT_texture_shadow_lod GL_EXT_texture_shared_exponent GL_EXT_texture_snorm GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_EXT_vertex_attrib_64bit GL_IBM_multimode_draw_arrays GL_INTEL_blackhole_render GL_INTEL_performance_query GL_INTEL_shader_integer_functions2 GL_KHR_blend_equation_advanced GL_KHR_context_flush_control GL_KHR_debug GL_KHR_no_error GL_KHR_parallel_shader_compile GL_KHR_robust_buffer_access_behavior GL_KHR_robustness GL_KHR_texture_compression_astc_ldr GL_KHR_texture_compression_astc_sliced_3d GL_MESA_framebuffer_flip_y GL_MESA_pack_invert GL_MESA_shader_integer_functions GL_MESA_texture_signed_rgba GL_NV_compute_shader_derivatives GL_NV_conditional_render GL_NV_copy_image GL_NV_depth_clamp GL_NV_packed_depth_stencil GL_NV_texture_barrier GL_OES_EGL_image GL_S3_s3tc
Extensões WebGL 2: EXT_color_buffer_float EXT_float_blend EXT_texture_compression_bptc EXT_texture_compression_rgtc EXT_texture_filter_anisotropic MOZ_debug OES_texture_float_linear WEBGL_compressed_texture_astc WEBGL_compressed_texture_etc WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context
Protocolo de janelas: x11
Ambiente de trabalho: gnome
Alvo de taxa de atualização: 60
GPU #1
Ativo: Sim
Descrição: Mesa Intel(R) HD Graphics 5500 (BDW GT2)
ID do fornecedor: 0x8086
ID do dispositivo: 0x1616
Fornecedor do driver: mesa/iris
Versão do driver: 21.0.3.0
RAM: 0

Diagnósticos
AzureCanvasBackend: skia
AzureContentBackend: skia
AzureFallbackCanvasBackend: skia
CMSOutputProfile: AAAE7GxjbXMEMAAAbW50clJHQiBYWVogB+UABgAGAA0AFwAqYWNzcEFQUEwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1sY21zeeH3esuE5g3DWlxD9tsTrwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOZGVzYwAAASwAAAAoY3BydAAAAVQAAACGd3RwdAAAAdwAAAAUY2hhZAAAAfAAAAAsclhZWgAAAhwAAAAUYlhZWgAAAjAAAAAUZ1hZWgAAAkQAAAAUclRSQwAAAlgAAAAQZ1RSQwAAAlgAAAAQYlRSQwAAAlgAAAAQY2hybQAAAmgAAAAkbWV0YQAAAowAAAIUZG1uZAAABKAAAAAiZG1kZAAABMQAAAAobWx1YwAAAAAAAAABAAAADGVuVVMAAAAMAAAAHAAzADcAMABFADQAS21sdWMAAAAAAAAAAQAAAAxlblVTAAAAagAAABwAVABoAGkAcwAgAHAAcgBvAGYAaQBsAGUAIABpAHMAIABmAHIAZQBlACAAbwBmACAAawBuAG8AdwBuACAAYwBvAHAAeQByAGkAZwBoAHQAIAByAGUAcwB0AHIAaQBjAHQAaQBvAG4AcwAuAABYWVogAAAAAAAA9tYAAQAAAADTLXNmMzIAAAAAAAEMGgAABcD///L+AAAHYAAA/c7///uX///9lQAAA/QAAL9OWFlaIAAAAAAAAGp0AABBJAAAB4BYWVogAAAAAAAAKVAAAB3jAAC4yFhZWiAAAAAAAABjEQAAoPoAABLkcGFyYQAAAAAAAAAAAAIzM2Nocm0AAAAAAAMAAAAAlIAAAFzAAABVwAAAlMAAACdAAAAZgGRpY3QAAAAAAAAACAAAABAAAACQAAAAFgAAAKYAAAAqAAAA0AAAABYAAADmAAAACAAAAO4AAAAiAAABEAAAAAYAAAEWAAAAEAAAASYAAABAAAABZgAAABQAAAF6AAAAKgAAAaQAAAASAAABtgAAAAYAAAG8AAAAFgAAAdIAAAAMAAAB3gAAACIAAAIAAAAAFABDAE0ARgBfAHAAcgBvAGQAdQBjAHQAZwBuAG8AbQBlAC0AcwBlAHQAdABpAG4AZwBzAC0AZABhAGUAbQBvAG4ARABBAFQAQQBfAHMAbwB1AHIAYwBlAGUAZABpAGQARQBEAEkARABfAG0AYQBuAHUAZgBhAGMAdAB1AHIAZQByAEIATwBFAEUARABJAEQAXwBtAGQANQA1ADkANwA1ADIAMgA4ADMAZgBlAGIANwBmADIAOQA3ADgAMwBlADcANQAyADMANwA3ADUAMgAxADYAOQBjAGYAQwBNAEYAXwBiAGkAbgBhAHIAeQBnAG4AbwBtAGUALQBzAGUAdAB0AGkAbgBnAHMALQBkAGEAZQBtAG8AbgBFAEQASQBEAF8AbQBuAGYAdABCAE8ARQBDAE0ARgBfAHYAZQByAHMAaQBvAG4AMwAuADMANgAuADEATQBBAFAAUABJAE4ARwBfAGQAZQB2AGkAYwBlAF8AaQBkAHgAcgBhAG4AZAByAC0AQgBPAEVtbHVjAAAAAAAAAAEAAAAMZW5VUwAAAAYAAAAcAEIATwBFAABtbHVjAAAAAAAAAAEAAAAMZW5VUwAAAAwAAAAcADMANwAwAEUANABL
Display0: 1366x768 default
DisplayCount: 1
Registro de decisões
HW_COMPOSITING:
available by default
OPENGL_COMPOSITING:
available by default
WEBRENDER:
available by default
WEBRENDER_QUALIFIED:
available by default
WEBRENDER_COMPOSITOR:
disabled by default: Disabled by default
blocklisted by env: Blocklisted by gfxInfo
WEBRENDER_PARTIAL:
available by default
WEBRENDER_SHADER_CACHE:
disabled by default: Disabled by default
WEBRENDER_OPTIMIZED_SHADERS:
available by default
WEBRENDER_ANGLE:
available by default
unavailable by env: OS not supported
WEBRENDER_DCOMP_PRESENT:
available by default
disabled by user: User disabled via pref
unavailable by env: Requires Windows 10 or later
unavailable by runtime: Requires ANGLE
WEBRENDER_SOFTWARE:
available by default
WEBGPU:
disabled by default: Disabled by default
blocked by runtime: WebGPU can only be enabled in nightly
X11_EGL:
available by default
DMABUF:
available by default

Mídia

Infraestrutura de Áudio: pulse-rust
Máximo de Canais: 2
Taxa de amostragem preferida: 44100
Latência de ida e volta (desvio padrão): 50.93ms (3.50)
Dispositivos de Saída
Nome: Grupo
Áudio interno Estéreo analógico: /devices/pci0000:00/0000:00:1b.0/sound/card1
Dispositivos de Entrada
Nome: Grupo
Monitor of Áudio interno Estéreo analógico: /devices/pci0000:00/0000:00:1b.0/sound/card1
Áudio interno Estéreo analógico: /devices/pci0000:00/0000:00:1b.0/sound/card1

Enumeração de banco de dados

Variáveis de ambiente

DISPLAY: :0
MOZ_APP_LAUNCHER: /usr/bin/firefox
MOZ_ASSUME_USER_NS: 1
MOZ_CRASHREPORTER_EVENTS_DIRECTORY: /home/edson/.mozilla/firefox/4tby3w6b.Usuário Padrão/crashes/events
MOZ_CRASHREPORTER_RESTART_ARG_0: /usr/bin/firefox
MOZ_CRASHREPORTER_RESTART_ARG_1:
MOZ_CRASHREPORTER_DATA_DIRECTORY: /home/edson/.mozilla/firefox/Crash Reports
MOZ_CRASHREPORTER_PING_DIRECTORY: /home/edson/.mozilla/firefox/Pending Pings
MOZ_CRASHREPORTER_STRINGS_OVERRIDE: /usr/lib/firefox/browser/crashreporter-override.ini
MOZ_LAUNCHED_CHILD:
MOZ_APP_SILENT_START:
XRE_PROFILE_PATH:
XRE_PROFILE_LOCAL_PATH:
XRE_START_OFFLINE:
XRE_BINARY_PATH:
XRE_RESTARTED_BY_PROFILE_MANAGER:

Recursos experimentais

cache de inicialização de about:home (browser.startup.homepage.abouthome_cache.enabled): false
Cookies: SameSite=Lax por padrão (network.cookie.sameSite.laxByDefault): true
Cookies: SameSite=None requer atributo seguro (network.cookie.sameSite.noneRequiresSecure): true
Cookies: Schemeful SameSite (network.cookie.sameSite.schemeful): false
CSS: Cascade Layers (layout.css.cascade-layers.enabled): false
CSS: Constructable Stylesheets (layout.css.constructable-stylesheets.enabled): false
CSS: Masonry Layout (layout.css.grid-template-masonry-value.enabled): false
Developer Tools: Painel de compatibilidade (devtools.inspector.compatibility.enabled): false
Developer Tools: Seletor de contexto de execução (devtools.webconsole.input.context): false
Developer Tools: Debug de Service Worker (devtools.debugger.features.windowless-service-workers): false
Fission (isolamento de sites) (fission.autostart): true
Media: JPEG XL (image.jxl.enabled): false
Suporte a vários Picture-in-Picture (media.videocontrols.picture-in-picture.allow-multiple): true
Barra de endereços: Mostrar resultados durante a composição IME (browser.urlbar.keepPanelOpenDuringImeComposition): false
Web API: WebGPU (dom.webgpu.enabled): false
Ativar/desativar som WebRTC globalmente (privacy.webrtc.globalMuteToggles): false
Confinamento de Win32k (security.sandbox.content.win32k-disable): false

Experimentos remotos

Preferências importantes modificadas

accessibility.typeaheadfind.flashBar: 0
browser.contentblocking.category: strict
browser.download.useDownloadDir: false
browser.search.region: BR
browser.sessionstore.upgradeBackup.latestBuildID: 20220106144528
browser.startup.homepage_override.buildID: 20220106144528
browser.startup.homepage_override.mstone: 96.0
browser.startup.page: 3
browser.urlbar.placeholderName: DuckDuckGo
browser.urlbar.quicksuggest.migrationVersion: 2
browser.urlbar.quicksuggest.scenario: history
browser.urlbar.tipShownCount.searchTip_onboard: 4
doh-rollout.balrog-migration-done: true
doh-rollout.disable-heuristics: true
doh-rollout.doneFirstRun: true
doh-rollout.home-region: BR
dom.security.https_only_mode: true
dom.security.https_only_mode_ever_enabled: true
extensions.lastAppVersion: 96.0
idle.lastDailyNotification: 1642262178
media.eme.enabled: true
media.gmp-gmpopenh264.abi: x86_64-gcc3
media.gmp-gmpopenh264.lastUpdate: 1641909982
media.gmp-gmpopenh264.version: 1.8.1.1
media.gmp-manager.buildID: 20220106144528
media.gmp-manager.lastCheck: 1642261298
media.gmp-widevinecdm.abi: x86_64-gcc3
media.gmp-widevinecdm.lastUpdate: 1641996683
media.gmp-widevinecdm.version: 4.10.2391.0
media.gmp.storage.version.observed: 1
media.videocontrols.picture-in-picture.video-toggle.has-used: true
network.cookie.cookieBehavior: 5
network.dns.disablePrefetch: true
network.http.referer.disallowCrossSiteRelaxingDefault: true
network.http.speculative-parallel-limit: 0
network.predictor.enabled: false
network.prefetch-next: false
network.trr.blocklist_cleanup_done: true
network.trr.mode: 5
network.trr.uri: https://firefox.dns.nextdns.io/
places.database.lastMaintenance: 1641910199
privacy.annotate_channels.strict_list.enabled: true
privacy.partition.network_state.ocsp_cache: true
privacy.purge_trackers.date_in_cookie_database: 0
privacy.purge_trackers.last_purge: 1642262178816
privacy.sanitize.pending: [{"id":"newtab-container","itemsToClear":[],"options":{}}]
privacy.trackingprotection.enabled: true
privacy.trackingprotection.socialtracking.enabled: true
security.remote_settings.crlite_filters.checked: 1642280900
security.remote_settings.intermediates.checked: 1642280900
security.sandbox.content.tempDirSuffix: 3246a4e2-6192-47a1-823e-2d637014d9b1
services.sync.declinedEngines:
services.sync.engine.creditcards: true
services.sync.engine.prefs.modified: false
services.sync.lastPing: 1642439044
services.sync.lastSync: Mon Jan 17 2022 14:05:39 GMT-0300 (Horário Padrão de Brasília)
signon.management.page.breach-alerts.enabled: false
signon.rememberSignons: false
storage.vacuum.last.index: 1
storage.vacuum.last.places.sqlite: 1641910199

Preferências importantes bloqueadas

fission.autostart.session: true

Base de dados de lugares

Acessibilidade

Ativado: false
Bloquear acessibilidade: 0

Versões de bibliotecas

NSPR
Versão mínima esperada: 4.33
Versão em uso: 4.33

NSS
Versão mínima esperada: 3.73.1
Versão em uso: 3.73.1

NSSSMIME
Versão mínima esperada: 3.73.1
Versão em uso: 3.73.1

NSSSSL
Versão mínima esperada: 3.73.1
Versão em uso: 3.73.1

NSSUTIL
Versão mínima esperada: 3.73.1
Versão em uso: 3.73.1

Isolamento (sandbox)

Seccomp-BPF (Sistema de filtragem de chamadas): true
Sincronização do thread Seccomp: true
Espaço de nomes do usuário: true
Isolamento de processamento de conteúdo: true
Isolamento de plugins de mídia: true
Nível de isolamento de processamento de conteúdo: 4
Nível efetivo de isolamento de processamento de conteúdo: 4
Estado de confinamento de Win32k em processos de conteúdo: Win32k Lockdown disabled -- Operating system not supported

Chamadas do sistema rejeitadas

Cache ao iniciar

Caminho do cache em disco: /home/edson/.cache/mozilla/firefox/4tby3w6b.Usuário Padrão/startupCache/startupCache.8.little
Ignorar cache em disco: false
Cache em disco encontrado ao iniciar: true
Gravado no cache em disco: false

Internacionalização e localização

Configurações do aplicativo
Idiomas solicitados: ["pt-BR"]
Idiomas disponíveis: ["en-US","pt-BR","pt-PT","en-CA","en-GB"]
Idiomas do aplicativo: ["pt-BR","pt-PT","en-US"]
Preferências regionais: ["pt-BR"]
Idioma padrão: "en-US"
Sistema operacional
Idiomas do sistema: ["pt-BR"]
Preferências regionais: ["pt-BR"]

Depuração remota (protocolo Chromium)

Aceitando conexões: false
URL:

Impressão

Configuração de impressão modificada

Comment 56

[Bruno Raoult]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #39)

[...]
2) Disable EGL backend (set gfx.x11-egl.force-disabled to true at about:support and restart browser)
3) Disable WebRender:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Check_WebRender

I can confirm these two actions worked for me (not sure if both are necessary).

Hardware: iMac early 2009
CPU: Intel(R) Core(TM)2 Duo E8135
GPU: NVIDIA C79 [GeForce 9400]
System: Ubuntu 20.04.3 LTS. I installed a fresh 16.04 a few days ago (dual boot with MacOS), then immediately upgraded twice (to 18.04 then 20.04).
kernel: 5.4.0-96-generic SMP
Firefox: 96.0+build2-0ubuntu0.20.04.1

Before making the changes proposed by Martin, I could not do anything with Firefox : As soon as I launched it, and its main window appeared, keyboard and mouse stopped working (but the mouse could move, but I could not do anything with it, like selecting another window). The system was OK, as I could ssh from another machine.

Comment 57

[Darkspirit]

(In reply to Bruno Raoult from comment #56)
Does the freeze still/also occur with https://nightly.mozilla.org?

Comment 58

[Darkspirit]

(In reply to Bruno Raoult from comment #56)

I can confirm these two actions worked for me (not sure if both are necessary).

We should find out if hardware WebRender, EGL vs. GLX, or Dmabuf WebGL causes the problem on Ubuntu 20.04.
@Everyone affected, please test these configurations:

1. GLX WebRender:
   Open about:config, set gfx.x11-egl.force-disabled to true, gfx.webrender.software to false,
   restart Firefox,
   open about:support and confirm that "Compositing" is "WebRender",
   open https://webglsamples.org/aquarium/aquarium.html.
   Does the freeze occur again with this configuration? If the freeze didn't occur, please test this configuration for some hours.

2. Software WebRender with EGL WebGL:
   Open about:config, set gfx.x11-egl.force-disabled to false, gfx.webrender.software to true,
   restart Firefox,
   open about:support and confirm that "Compositing" is "WebRender (Software)",
   open https://webglsamples.org/aquarium/aquarium.html.
   Does the freeze occur again with this configuration? If the freeze didn't occur, please test this configuration for some hours.

3. EGL WebRender without EGL Dmabuf WebGL:
   Open about:config, set gfx.x11-egl.force-disabled to false, gfx.webrender.software to false, widget.dmabuf-webgl.enabled to false,
   restart Firefox,
   open about:support and confirm that "Compositing" is "WebRender",
   open https://webglsamples.org/aquarium/aquarium.html.
   Does the freeze occur again with this configuration? If the freeze didn't occur, please test this configuration for some hours.

Comment 59

[Darkspirit]

(bug 1736949 seems to have caused a hang on 14.04 that even affects SW WR: bug 1744882)

Comment 60

[Bruno Raoult]

I made tests with configuration :

Hardware: iMac early 2009
CPU: Intel(R) Core(TM)2 Duo E8135
GPU: NVIDIA C79 [GeForce 9400]
System: Ubuntu 20.04.3 LTS. I installed a fresh 16.04 a few days ago (dual boot with MacOS), then immediately upgraded twice (to 18.04 then 20.04).
kernel: 5.4.0-96-generic SMP
Firefox: 96.0+build2-0ubuntu0.20.04.1
Xorg driver: 1:1.0.16-1

IMPORTANT / LAST MINUTE FINDING : My tests below should be considered as invalid, as my hardware is very specific : Meantime, I found this, which indicates my issue is likely on nvidia driver side, not on graphical application side. I got a LibreOffice freeze too, which is a good argument for this hypothesis. Therefore, I consider I don't have a Firefox issue, at least with my current unstable Xorg configuration. Sorry for the noise.

We should find out if hardware WebRender, EGL vs. GLX, or Dmabuf WebGL causes the problem on Ubuntu 20.04.
@Everyone affected, please test these configurations:

1. GLX WebRender:
   Open about:config, set gfx.x11-egl.force-disabled to true, gfx.webrender.software to false,
   restart Firefox,
   open about:support and confirm that "Compositing" is "WebRender",
   open https://webglsamples.org/aquarium/aquarium.html.
   Does the freeze occur again with this configuration? If the freeze didn't occur, please test this configuration for some hours.

Freeze after a few seconds after loading the page [1]

2. Software WebRender with EGL WebGL:
   Open about:config, set gfx.x11-egl.force-disabled to false, gfx.webrender.software to true,
   restart Firefox,
   open about:support and confirm that "Compositing" is "WebRender (Software)",
   open https://webglsamples.org/aquarium/aquarium.html.
   Does the freeze occur again with this configuration? If the freeze didn't occur, please test this configuration for some hours.

Freeze after a few seconds after loading the page [1]

3. EGL WebRender without EGL Dmabuf WebGL:
   Open about:config, set gfx.x11-egl.force-disabled to false, gfx.webrender.software to false, widget.dmabuf-webgl.enabled to false,
   restart Firefox,
   open about:support and confirm that "Compositing" is "WebRender",
   open https://webglsamples.org/aquarium/aquarium.html.
   Does the freeze occur again with this configuration? If the freeze didn't occur, please test this configuration for some hours.

Freeze occurs when I start to load the page (nothing shows in tab).

[1] I am unsure these two options work at all, even for "normal" pages. Before I made the changes above, Firefox stopped working (ie. it became impossible to do anything with Xorg) in a random manner.

For the 3 tests, a killall firefox (remote ssh) left one firefox process. kill -9 did not work on it (or very slow: After ~1mn it was killed with one test, for the others I powered off after ~1-2 min, it is possible that firefox would have been killed if I wait longer).

Comment 61

[Bob]

Attachment: Firefox about:support

The two features that was suggested to switch to off has solved my problem.

Comment 62

[Bruno Raoult]

(In reply to Bruno Raoult from comment #60)

IMPORTANT / LAST MINUTE FINDING : My tests below should be considered as invalid, as my hardware is very specific : Meantime, I found this, which indicates my issue is likely on nvidia driver side, not on graphical application side. I got a LibreOffice freeze too, which is a good argument for this hypothesis. Therefore, I consider I don't have a Firefox issue, at least with my current unstable Xorg configuration. Sorry for the noise.

I can confirm (on my early 2009 iMac) that switching from nouveau to proprietary NVidia (nvidia-340 for the GeForce 9400) fixed all my issues : I reverted the settings I changed before, FF works fine, and the aquarium test page works perfectly.

Note: I cannot edit my previous posts ([#56] and [#60]), it would be nice if someone could strikethrough them and link to this post, explaining my issue was not linked to this thread.

Comment 63

[hollmeer]

..I can confirm also "..that switching from nouveau to proprietary NVidia (nvidia-340 for the GeForce 9400) fixed all my issues.."..
..only about four (or so) somewhat mysterious total system freezes since Summer 2021..
..the kernel update with apt update/upgrade seems to make each time some patches related to nvidia 340, so something there to look into..?

Comment 64

[bweinel]

I am seeing the same hanging issues here with Firefox (v98.0 canonical-1.0) on two different Kubuntu machines both using the xorg-nouveau drivers (one is Kubuntu v18.04.6 with xserver-xorg-video-nouveau v1:1.0.15-2 driver, the other is Kubuntu v20.04.4 with xserver-xorg-video-nouveau v1:1.0.16-1 driver.) No issues noted with the Chromium browser on the same machines. I haven't yet tested using the Nvidia driver but both machines have Nvidia cards.

Comment 65

[Rik]

Same problem on Debian 11 (Bullseye) with Mate DE.
Firefox from the official Debian repo is the release before v. 91.7.0esr (64-bit) (I've just installed this version few hours ago and I don't know which release was the previous one... somenthing very, very close to this).

At random the computer freezes completely after a click or while typing into Firefox. The screen keeps showing the last things (obviously frozen like a screenshot). At that point anything is frozen: no mouse, no keyboard (caps lock doesn't toggle the light), no reply to ping from other machines in LAN, USB, 100% frozen.
Pressing the power button doesn't trigger any action.
The only way to go is pressing reset, or keeping the power off button pressed for 4s to brutally turn off the PSU, or turning off the UPS.

Note:
It is now the 3rd time in 10 days and it only happens when using Firefox. Never happened with other apps (and I use most of the time Netbeans that is far heavier than Firefox in any aspect). And by the way is something new of this last version

Note:
I can't find anything useful in the logs because the computer freezes with no time to write somenthing.

Comment 66

[Rik]

I forgot to say I'm using the GPU integrated in the Intel i5-8400, and Firefox is using hardware acceleration (webrender)

Comment 67

[mikhail]

It worked for me
set gfx.webrender.software to true
set gfx.webrender.software.opengl to true
set widget.dmabuf-webgl.enabled to false

There is less hangs now. My problem is on ESR https://bugzilla.mozilla.org/show_bug.cgi?id=1743505

I'm on 98 Fedora Spins Xfce now:
$ inxi -CG
CPU:
Info: dual core model: Intel Celeron G3900 bits: 64 type: MCP cache: L2: 512 KiB
Speed (MHz): avg: 800 min/max: 800/2800 cores: 1: 800 2: 800
Graphics:
Device-1: Intel HD Graphics 510 driver: i915 v: kernel
Display: x11 server: X.Org 1.20.14 driver: loaded: modesetting unloaded: fbdev,vesa resolution: 1280x1024~60Hz
OpenGL: renderer: Mesa Intel HD Graphics 510 (SKL GT1) v: 4.6 Mesa 21.3.6

Comment 68

[Rik]

Thanks for the info mikhail.
I've had another total freeze after 10 days, while I was moving the youtube video cursor. Now I've completely disabled the hardware acceleration. In case I don't have "explosions" in 2/3 weeks I'll try your config.

Comment 69

[mikhail]

(In reply to Rik from comment #68)

I've had another total freeze after 10 days, while I was moving the youtube video cursor. Now I've completely disabled the hardware acceleration. In case I don't have "explosions" in 2/3 weeks I'll try your config.

But this did not solve the problem completely, freezes less often and the computer can now be restarted with the reset button instead of turning off completely.

And the ESR problem - was solved by the link above, but soon something was updated and the hangs continued.

I think there is something more serious and WebRender has nothing to do with it.

Comment 70

[mikhail]

(In reply to mikhail from comment #67)

It worked for me
set gfx.webrender.software to true
set gfx.webrender.software.opengl to true
Another need to set gfx.webrender.max-partial-present-rects in 0 then the moving images on the page froze, but the page does not hang links work, the page can be updated and then work.

Comment 71

[Rik]

From Yesterday I've set
set gfx.webrender.software to true
set gfx.webrender.software.opengl to true
set widget.dmabuf-webgl.enabled to false

Let's see if it's sufficient to solve this very, VERY, annoying+dangerous problem. I this this bug should have top max priority because it's not disruptive, it's destructive: 2 freezes ago it damaged the VM where I was developing. :-(

Comment 72

[Rik]

For me this should be set as Severity 1 because it damages the computer/OS.

Comment 73

[mikhail]

(In reply to Rik from comment #71)

Let's see if it's sufficient to solve this very, VERY, annoying+dangerous problem. I this this bug should have top max priority because it's not disruptive, it's destructive: 2 freezes ago it damaged the VM where I was developing. :-(

I think I figured it out, you have to:
set gfx.webrender.software to true
set gfx.webrender.software.opengl to true
set gfx.webrender.max-partial-present-rects in 0

Now I expert set gfx.webrender.max-partial-present-rects in -1, with a value of 0 I don't hang anymore.

Comment 74

[mikhail]

(In reply to Rik from comment #71)

Let's see if it's sufficient to solve this very, VERY, annoying+dangerous problem. I this this bug should have top max priority because it's not disruptive, it's destructive: 2 freezes ago it damaged the VM where I was developing. :-(

No, I was wrong it did not help, two freezes in a row. It seems to be a problem with gecko engine.

Comment 75

[Rik]

(In reply to mikhail from comment #74)
At the moment no explosions yet! :-) But it's only 6 days. The last time it tooks 2 weeks despite I'm a developer and I use the computer 10 hours per day. Must be a very particular combination of things. However in my case the problem has always happened in the exact moment I was clicking a link or moving the cursor of youtube. Never happened simply loading a page o watching a YT video or using any other software. So it seems the problem is the mouse + firefox.

Since Firefox-ESR uses EGL by default and EGL requires at least mesa version 21.x and Debian bullseye ships with mesa version 20.3.5, maybe your idea about
set gfx.webrender.software.opengl to true
is enough or can be improved with
webgl.disabled=true
instead of only
set widget.dmabuf-webgl.enabled to false
as you suggested.

Comment 76

[mikhail]

(In reply to Rik from comment #75)

Since Firefox-ESR uses EGL by default and EGL requires at least mesa version 21.x and Debian bullseye ships with mesa version 20.3.5, maybe your idea about
set gfx.webrender.software.opengl to true

See about:support Compositing: WebRender (Software OpenGL). It is mandatory to set gfx.webrender.software to true.

is enough or can be improved with
webgl.disabled=true

Yes, I have that disabled. From fingerprinting.

instead of only
set widget.dmabuf-webgl.enabled to false
as you suggested.

It has no effect on me at all. But with the setting gfx.webrender.max-partial-present-rects in 0 managed to prevent some hangs page freezes you can continue to work the tab by refreshing it. I have a feeling that there is more than one bug that causes freezing.

Comment 77

[mikhail]

My statistics:
Compositing: WebRender - freezes after an average of 30 minutes.
Compositing: WebRender (Software) - freezes after a few hours.
Compositing: WebRender (Software OpenGL) - freezes after a few days.

Comment 78

[mikhail]

I solved the problem by disabling compositing in Xfce
xfconf-query -c xfwm4 -p /general/use_compositing -s false
and hardware acceleration in Firefox
layers.acceleration.disabled=true

Comment 79

[Rik]

I've never used compositing because I hate GUI effects. I'm using Marco no compositing in Debian Mate.
Yesterday it happened again. I'm now testing
webgl.disabled=true
in case of a new "explosion" I'll disable hw acceleration completely.

Comment 80

[mikhail]

(In reply to Rik from comment #79)

I've never used compositing

In xfce it has always been disabled by default, I think in version 4.16 they turned it on. Now I've got everything stable and it doesn't freeze.

Comment 81

[huyou]

Firefox always freeze my computer, I cannot use any key and mouse, cannot use alt+ctl+ f1.

I have to directly power off my computer for many times.

Firefox freeze my computer when I open firefox for a few minutes, or for a few hours.

When I use virtualbox, Firefox freeze my computer too.

When will fix this bug?

By the way, Chromium also freeze my computer.

Firefox 91.9 esr

Comment 82

[Rik]

(In reply to huyou from comment #81)

Firefox always freeze my computer, I cannot use any key and mouse, cannot use alt+ctl+ f1.

I have to directly power off my computer for many times.

Firefox freeze my computer when I open firefox for a few minutes, or for a few hours.
...

Which OS and DE (xfce, mate, etc.) are you using?

Comment 83

[huyou]

Thank you!

Host OS: Devuan Chimaera4.0-64 kde-5.20.5, virtualbox OS kali-virtual-64 xfce-4.16

Both OS have been frozen for many times.

Even only use firefox, not use other applications, firefox will freeze my computer.

Thanks.

Comment 84

[huyou]

At first I suspected PulseAudio, because I played many MP4 and MP3 at the same time and used firefox.

When I only used firefox and my computer was frozen, I realized firefox was the suspect.

I have tried Mate desktop, but after sometime, firefox also froze my computer.

I tried Chromium(version 101), the same thing happened.

I tried to use firefox in virtualbox to avoid the problem. Yesterday, firefox froze my host computer too.

Now I try not to let keyboard being captured in virtualbox.

It is really annoying experience.

Comment 85

[Rik]

OK, Devuan Chimaera4.0-64 is based on Debian 11 that I'm quite sure is 1 of the factors of the problem. The other 2 factors must be the Intel Graphics, and the Firefox version.

I think I've solved the problem since It is now 21 days without a problem after setting

gfx.webrender.software.opengl=true
webgl.disabled=true

I think the main problem is that Firefox-ESR uses EGL by default and EGL requires at least mesa version 21.x and Debian bullseye ships with mesa version 20.3.5. Disabling webgl in firefox solves the problem.

Comment 86

[Rik]

I can confirm the problem is webgl.
The only parameter that solves the problem is
webgl.disabled=true
It's the only paramter that matter. With such parameter I've been freeze-free for a month. I've set it back to false and in 2 days I've got the problem back.

Comment 88

[Rik]

Correction: today I've got again a complete freeze. So I rectify: webgl.disabled=true does NOT solve the issue.
I'm now trying to reverse the compositor back to previous versions, the so called "Basic" compositor that is actually working great. Especially those who are running on "webrender (software)", "Basic" is light years faster. On a laptop I've seen a difference on Youtube from 100% CPU and frame loss to 20% CPU
So I'm now testing
gfx.webrender.force-disabled
I hear this flag is going to be removed in v. 92... well if it this flag solve the problem I'll pin this version forever or I'm going to use Falkon because I can't live with the fear to have the PC frozen at random while doing important things.

IN ANY CASE removing this flag is a bad move, because on many PC webrender works only in "software" mode and it's unuseable compared to "Basic" (100% CPU against 20% with Basic).

Comment 89

[Martin Stránský [:stransky] (ni? me)]

Can you get backtrace / crash ID of the freeze please? How-to is here:
https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Application_freeze
Thanks.

Comment 90

[Rik]

There is no way to have a backtrace because when it happens (once per 1 or 2 weeks) everything is frozen and the only thing working is the hard reset of the computer.
However after a month of test, I can assure the problem is webrender and the best solution is
gfx.webrender.force-disabled = true
Going back to Compositing Basic solves any problem: much faster than "webrender (software)" and no freeze.

On another PC with no freezing problem but with "webrender (software)" very slow the same option
gfx.webrender.force-disabled = true
has changed the compositor to "Basic" and youtube instead of 100% of CPU is now at 20%

I wonder what I will do when such option will be removed... mayble I'll never update FF again or probably I will have to change browser.

Comment 91

[mikhail]

(In reply to Rik from comment #90)

I wonder what I will do when such option will be removed...

"Basic" - now called "WebRender (Software OpenGL)".

Comment 92

[Rik]

Do you mean that in v. 92+ disabling the hardware webrender and forcing OpenGL is the same as compositor "Basic"?
But I have already tried
set gfx.webrender.software to true
set gfx.webrender.software.opengl to true
and the freeze still happens, so it doesn't seem to be equivalent.

Moreover it's slow as hell, while "Basic" has no difference from webrendering hw accelerated.

I've tried a lot of options but nothing compare with compositor "Basic".

The only interesting thing is that Firefox Developer Edition is using Compositor "WebRender" and has never frozen the PC. I wonder if the problem is the version that comes with Debian.

My best option is:

1. Going with "Basic" till it last
2. When the option disappears, I'll make new experiments.

Comment 93

[mikhail]

(In reply to Rik from comment #92)

Do you mean that in v. 92+ disabling the hardware webrender and forcing OpenGL is the same as compositor "Basic"?

I have in the test games on the speed he does not differ from the "Basic", I thought that this is it.

Comment 94

[mikhail]

(In reply to Rik from comment #86)

I can confirm the problem is webgl.
The only parameter that solves the problem is
webgl.disabled=true
It's the only paramter that matter. With such parameter I've been freeze-free for a month. I've set it back to false and in 2 days I've got the problem back.

I confirm that when I turn on WebGL I also freeze. Firefox 101, 102 has not yet been tested.

Comment 95

[mikhail]

(In reply to Rik from comment #90)

There is no way to have a backtrace because when it happens (once per 1 or 2 weeks) everything is frozen and the only thing working is the hard reset of the computer.

I am able to call the terminal Ctrl-Shift-T.

Comment 96

[mikhail]

(In reply to mikhail from comment #95)

(In reply to Rik from comment #90)

There is no way to have a backtrace because when it happens (once per 1 or 2 weeks) everything is frozen and the only thing working is the hard reset of the computer.

I am able to call the terminal Ctrl-Shift-T.

Sorry Alt-Shift-T.

Comment 97

[mikhail]

(In reply to mikhail from comment #96)

(In reply to mikhail from comment #95)

(In reply to Rik from comment #90)

There is no way to have a backtrace because when it happens (once per 1 or 2 weeks) everything is frozen and the only thing working is the hard reset of the computer.

I am able to call the terminal Ctrl-Shift-T.

Sorry Alt-Shift-T.

Shit Alt-Ctrl-T :)

Comment 98

[Rik]

In my case when Firefox freezes the computer, it's really frozen and absolutery nothing works.
Even the caps lock on the keyboard stops turning on/off the led (that's a great indicator to understand if it's an unrecoverable freeze). So not only I cannot open a terminal, but I cannot also open a console (CTRL+ALT+F1), no sysreq commands, no X reset with CTRL+ALT+Backspace, no ping, no nothing.
The only working button is the hard reset.

Comment 99

[mikhail]

I get hangs more often, so sometimes even the mouse worked. Now I can't reproduce to go to the terminal. I said from the beginning there are several bugs.

1. Video on YouTube stuttered sound and everything hangs.
   Solution: Disable hardware acceleration and compositing in Xfce.
2. Hanging in WebGL games.
   Solution: Disable WebGL.
3. Freezing on minimizing browser window.
   No solution was found.

Comment 100

[Rik]

Your case is much simple than mine because is frequent and because the computer is still alive. In my case there is no possibility to analyze the problem at all. Fortunately though I've solved it completely switching Webrender for "Basic".

Comment 101

[mikhail]

https://crash-stats.mozilla.org/report/index/08c7a861-4adb-4869-aec3-5f7660220708

Comment 102

[mikhail]

https://crash-stats.mozilla.org/report/index/6223f1e7-6818-4894-8749-5fb970220713

Comment 103

[Samuel]

Debian 11 with Gnome-Shell and Wayland.
After upgrade from Firefox ESR 91.11 to Firefox ESR 102 (and 120.0.1) we have also freezes.

Complete system freeze but ssh into this machine is possible.
After pkill firefox Gnome-Shell response again.

We tried to reset the Firefox profil (rm -r ~/.mozilla), but it doesn't help.
At the moment we switch back to xorg and monitor the problem.

Any ideas?

Comment 104

[mikhail]

https://crash-stats.mozilla.org/report/index/b36995dc-2c05-454d-a6a6-5a47a0220728

Comment 105

[Samuel]

(In reply to Samuel from comment #103)

At the moment we switch back to xorg and monitor the problem.

xorg solved the problem for us, Firefox is stable again.

Comment 106

[Rik]

In which way xorg solved the problem? Where? When? Which version?
I have the problem with Debian 11 + Mate (with or without compositor of any kind).

Comment 107

[mikhail]

https://crash-stats.mozilla.org/report/index/966803e5-d379-48c5-8871-f20f00220804#tab-details

Comment 108

[Rik]

I saw that but I can't find any sign of fix about this case. The list of fixed things it's here
https://crash-stats.mozilla.org/report/index/966803e5-d379-48c5-8871-f20f00220804#tab-bugzilla
and the only fixed bug is this one https://bugzilla.mozilla.org/show_bug.cgi?id=1762611
that is
Status: ASSIGNED → RESOLVED
Closed: 4 months ago

4 months ago we still had problems so must be another kind of problem or maybe is not released yet after 4 months (?).

Comment 109

[mikhail]

Found the same problem on someone on Ubuntu:
https://crash-stats.mozilla.org/report/index/623feb17-8e1c-4f58-b671-b16d10220729

Comment 110

[mikhail]

(In reply to Rik from comment #108)

I saw that but I can't find any sign of fix about this case. The list of fixed things it's here
https://crash-stats.mozilla.org/report/index/966803e5-d379-48c5-8871-f20f00220804#tab-bugzilla
and the only fixed bug is this one https://bugzilla.mozilla.org/show_bug.cgi?id=1762611
that is
Status: ASSIGNED → RESOLVED
Closed: 4 months ago

4 months ago we still had problems so must be another kind of problem or maybe is not released yet after 4 months (?).

No, it has nothing to do with our problem. Crash Report [@ __GI___poll ] is when you kill firefox.

In short, I'm sick of it all, now I'm looking for an alternative. Or we'll have to roll back to old versions where this problem does not exist.

Comment 111

[Martin Stránský [:stransky] (ni? me)]

(In reply to mikhail from comment #110)

In short, I'm sick of it all, now I'm looking for an alternative. Or we'll have to roll back to old versions where this problem does not exist.

So heavy failures with various config looks like underlying HW issue to me - maybe memory failure or so. Try to check your memory by some memcheck tool.
Or is there any Firefox version you can use (from the past) which is rock solid on your recent setup?
Thanks.

Comment 112

[Rik]

In my case is not hw problem for sure, it's a webrender problem, in fact, simply using "basic" solve the problem. The day FF ESR will remove "basic" I'll have to change browser if this problem persist. I'm quite sure the problem is related to the Intel APUs and/or UHD Graphics 630.

Comment 113

[mikhail]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #111)

(In reply to mikhail from comment #110)

In short, I'm sick of it all, now I'm looking for an alternative. Or we'll have to roll back to old versions where this problem does not exist.

So heavy failures with various config looks like underlying HW issue to me - maybe memory failure or so. Try to check your memory by some memcheck tool.
Or is there any Firefox version you can use (from the past) which is rock solid on your recent setup?
Thanks.

I had this computer for a year without any problems. Then, as I remember after upgrading the kernel to 5.10 began to have problems, began to hang video on YouTube, this problem I solved by turning off the hardware acceleration. Now added some new bugs Firefox hangs when minimizing the browser window, and most recently a new bug Firefox as it hangs and the text disappears in the top right menu. That is, with each version it becomes impossible to use the browser.

Comment 114

[mikhail]

about:support is getting errors:

(#1) CP+[GFX1-]: Managed to allocate after flush.
(#2) CP+[GFX1-]: Managed to allocate after flush.
(#3) CP+[GFX1-]: Managed to allocate after flush.
(#4) CP+[GFX1-]: Managed to allocate after flush.
(#5) CP+[GFX1-]: Managed to allocate after flush.
(#6) CP+[GFX1-]: Managed to allocate after flush.
(#7) CP+[GFX1-]: Managed to allocate after flush.
(#8) CP+[GFX1-]: Managed to allocate after flush.
(#9) CP+[GFX1-]: Managed to allocate after flush.
(#10) CP+[GFX1-]: Managed to allocate after flush.
(#11) CP+[GFX1-]: Managed to allocate after flush.
(#12) CP+[GFX1-]: Managed to allocate after flush.
(#13) CP+[GFX1-]: Managed to allocate after flush.
(#14) CP+[GFX1-]: Managed to allocate after flush.

Comment 115

[mikhail]

With hardware acceleration enabled:

(#0) Error glxtest: VA-API test failed: failed to initialise VAAPI connection.
(#1) Assert Device reset due to WR context
(#2) Error GFX: RenderThread detected a device reset in PostUpdate

Comment 116

[mikhail]

Since version 104 video now hangs with hardware acceleration turned off

Comment 117

[Rik]

That's why I'm still with the stock version that comes with Debian Bullseye, FF 91.12.0esr and no webrender. It's now 4 months I have zero problems thanks to
gfx.webrender.force-disabled = true

Comment 118

[mikhail]

I found these errors in the log:

Aug 31 02:02:18 kernel: i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
Aug 31 02:02:18 kernel: i915 0000:00:02.0: [drm] ERROR rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Aug 31 02:02:18 kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:87f7effa, in Xorg [828]
Aug 31 02:02:32 kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:87f7effa, in Xorg [828]
Aug 31 02:02:32 kernel: i915 0000:00:02.0: [drm] Resetting rcs0 for stopped heartbeat on rcs0
Aug 31 02:02:32 kernel: i915 0000:00:02.0: [drm] ERROR rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Aug 31 02:02:32 kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Aug 31 02:02:32 kernel: i915 0000:00:02.0: [drm] ERROR rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Aug 31 02:02:32 kernel: i915 0000:00:02.0: [drm] ERROR rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}

Could it be related to this?

Comment 119

[mikhail]

I set the GPU frequency limit:

echo 350 > /sys/class/drm/card0/gt_boost_freq_mhz
echo 350 > /sys/class/drm/card0/gt_max_freq_mhz

cat /sys/kernel/debug/dri/0/i915_rps_boost_info
RPS enabled? yes
RPS active? no
GPU busy? no
Boosts outstanding? 0
Interactive? 42
Frequency requested 350, actual 350
  min hard:350, soft:350; max soft:350, hard:950
  idle:350, efficient:350, boost:350
Wait boosts: 0

No hang-ups at the moment.

Comment 120

[Rik]

Debian 11 proposes an upgrade from FF 92 to 102. Accepted... now Firefox freezing the entire OS is back.
The option that was saving me from that, gfx.webrender.force-disabled = true, is now ignored by FF and that's the problem.
Now I have 2 options left:

1. go back (timeshift) and then pin FF so it will never upgrade again, EVER
2. change browser.

Comment 121

[mikhail]

(In reply to Rik from comment #120)

Debian 11 proposes an upgrade from FF 92 to 102. Accepted... now Firefox freezing the entire OS is back.
The option that was saving me from that, gfx.webrender.force-disabled = true, is now ignored by FF and that's the problem.
Now I have 2 options left:

1. go back (timeshift) and then pin FF so it will never upgrade again, EVER
2. change browser.

I have hardware acceleration turned on and haven't had a hang-up in a month. Have you tried limiting GPU frequencies?

Comment 122

[Rik]

Yes I'm using hw acceleration. I've also tried without it. Same problem. The only thing working was disabling webrender going with "Basic" compositor. Now the option is gone and the explosions are back.
Why should I limiting the GPU for a FF bug? By the way the freeze I experience few hours ago happened with the browser minimized, no video, only ebay opened.
I cannot work knowing my computer can freeze at any moment just because I have FF opened... even doing experiments on paramters it's a pain because every time it freezes I can have damages: some freezes ago, FF damaged an entire Windows VM. I'm going to change browser.

Comment 123

[mikhail]

This is not an FF bug. See https://gitlab.freedesktop.org/drm/intel/-/issues/4858

Comment 124

[Rik]

That's not my case, my computers doesn't crash/freeze with anything except FF Webrender. Anything else on planet works OK. I've tested Falkon with webgl, stressing test with 10.000 moving fishes acquarium: 60fps against 30fps of FF. No freeze at all. If it were a problem of GPU it would now be exploded with such test. :-) And I also make video rendering, I use VLC fullscreen, Netbeans, Eclipse, RDP fullscreen, never had a single problem. With FF + webrender a freeze is granted.
However, I'm found out the update to v 102 was because of the fasttrack repo. Removed and I'm now back on v91 ESR with the "Basic" compositor and now it's OK.

Comment 125

[huyou]

set swappiness value =10

from:
https://unix.stackexchange.com/questions/226395/my-linux-desktop-freezes-randomly-what-to-look-for-in-logs

To see what the swappiness is set to

cat /proc/sys/vm/swappiness
if it is set to the default value of 60 then

sudo gedit /etc/sysctl.conf
add this to end of file

vm.swappiness=10
My system no-longer freezes

In my host OS and virtual box OS ,firefox cannot be used, open and clash.
I have to use chromium, but my pc froze when I used or not used web browser.
Since 2022-9-15, I changed swappiness to 10, my host pc have never been frozen by now(2022-10-15).
But virtualbox OS mx-linux sometimes automatic shut down, that is acceptable.

I am afraid fewer and fewer people will use firefox.

Comment 126

[huyou]

set swappiness value =10

from:
https://unix.stackexchange.com/questions/226395/my-linux-desktop-freezes-randomly-what-to-look-for-in-logs
To see what the swappiness is set to

cat /proc/sys/vm/swappiness
if it is set to the default value of 60 then

sudo gedit /etc/sysctl.conf
add this to end of file

vm.swappiness=10

My system no-longer freezes

In my host OS and virtual box OS ,firefox cannot be used, opened and immediately crashed.
I have to use chromium.
But my pc was frozen when I used or not used web browser.
Since 2022-9-15, I changed swappiness to 10, my host pc has never been frozen by now(2022-10-15).
But virtualbox OS mx-linux sometimes automatic shuts down, that is acceptable.

I am afraid fewer and fewer people will use firefox.

Comment 127

[Rik]

It cannot be my problem because:

1. I don't have any random freeze
2. it's only Firefox to freeze the system and only when the compositor is webrender, (not with "basic"). Even opening 1000 tabs it's not a problem with "Basic", while a single page can freeze the computer when using webrender.
3. I don't use swap at all (set to 0) because I have plenty of DDR4 and the max I use is 70% (tipically not even 40%) . In case Linux is going to get stuck because of an out of memory problem, the watchdog would kill non-system apps, so there is no way to have a freeze in Linux because of ram/swappiness.

PS: the problem you mentioned was: "turned out to be that my swap was too small".

Comment 128

[mikhail]

(In reply to Rik from comment #127)

it's only Firefox to freeze the system and only when the compositor is webrender, (not with "basic"). Even opening 1000 tabs it's not a problem with "Basic", while a single page can freeze the computer when using webrender.

Webrender increases the frequency of the GPU, so the GPU can freeze. I suggest you to test with frequency limitation, because our cases are very similar.

Comment 129

[mikhail]

You can also try disabling Intel Turbo Boost in the BIOS. But I couldn't find it in my BIOS.

Comment 130

[Rik]

The thing is this happens even leaving FF open doing nothing, in a static ebay page. The simple fact of having FF open can freeze the system at random moments. On the contrary, to prove it's not the GPU, with Falkon on a webgl stress test, with the GPU at maximum frequency (1050 MHz), no problem at all even if I leave it there for hours. By the way, blocking the GPU at 350MHz while gt_boost_freq_mhz it's 1050, it's not a great solution to say the least. :-)

Comment 131

[Rik]

PS: the move from 91 to v. 102 was not proposed by Debian Bullseye stable repo, it came from the Debian fasttrack repo that I only used for VirtualBox. I've now pinned fasttrack to update VirtualBox only and revert FF 102 to v.91 with compositor "basic". No more problems. I'll keep going with v.91 till it last, then, if Debian Bullseye repo will ever propose v.92+ I have 2 options: abandon the ESR of the repo going with the very latest version of the standard release in the hope it works, or change browser with Falkon or a degoogled chromium.

Comment 132

[mikhail]

(In reply to Rik from comment #130)

By the way, blocking the GPU at 350MHz while gt_boost_freq_mhz it's 1050, it's not a great solution to say the least. :-)

I am testing now and noticed that it is enough to limit only max soft: 350.

Comment 133

[7etetic]

Hello.
I have the same problem.
(In reply to Darkspirit from comment #58)

We should find out if hardware WebRender, EGL vs. GLX, or Dmabuf WebGL causes the problem on Ubuntu 20.04.
@Everyone affected, please test these configurations:

1. GLX WebRender:
   Open about:config, set gfx.x11-egl.force-disabled to true, gfx.webrender.software to false,
   Test page passed OK. Freeze after two weeks on a page with static content.

2. Software WebRender with EGL WebGL:
   Open about:config, set gfx.x11-egl.force-disabled to false, gfx.webrender.software to true,

Test page passed OK. Freeze after several hours on a page with static content.

3. EGL WebRender without EGL Dmabuf WebGL:
   Open about:config, set gfx.x11-egl.force-disabled to false, gfx.webrender.software to false, widget.dmabuf-webgl.enabled to false,

Test page passed OK. Freeze on a random YouTube video.

(In reply to mikhail from comment #70)

(In reply to mikhail from comment #67)

It worked for me
set gfx.webrender.software to true
set gfx.webrender.software.opengl to true
Another need to set gfx.webrender.max-partial-present-rects in 0 then the moving images on the page froze, but the page does not hang links work, the page can be updated and then work.

Freeze after one week on a YouTube video.

(In reply to Rik from comment #85)

I think I've solved the problem since It is now 21 days without a problem after setting

gfx.webrender.software.opengl=true
webgl.disabled=true

I think the main problem is that Firefox-ESR uses EGL by default and EGL requires at least mesa version 21.x and Debian bullseye ships with mesa version 20.3.5. Disabling webgl in firefox solves the problem.

I'm testing right now. Hope it will help. But I'm sure that it's not a normal work of FF.

My configuration:

$ lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 20.04.5 LTS
Release: 20.04
Codename: focal

$ firefox -v
Mozilla Firefox 106.0.2

$ inxi -CG
CPU: Topology: Dual Core model: AMD Athlon 64 X2 6000+ bits: 64 type: MCP L2 cache: 1024 KiB
Speed: 1000 MHz min/max: 1000/3100 MHz Core speeds (MHz): 1: 1800 2: 1800
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] driver: radeon v: kernel
Display: x11 server: X.Org 1.20.13 driver: radeon FAILED: ati unloaded: fbdev,modesetting,vesa
resolution: 1280x1024~60Hz
OpenGL: renderer: VERDE ( LLVM 14.0.6 DRM 2.50 5.15.0-52-generic) v: 4.5 Mesa 22.2.2 - kisak-mesa PPA

Comment 134

[7etetic]

(In reply to 7etetic from comment #133)
Hello.
The issue still persists in Ubuntu 22.04. The only thing that helps is to disable WebGL (webgl.disabled=true). All other settings are set by default.

Dear moderators, can you create a link to this discussion in the new version of Firefox please? I don't know how to do it.

My configuration:

$ lsb_release -a
LSB Version: core-11.1.0ubuntu4-noarch:security-11.1.0ubuntu4-noarch
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy

$ firefox -v
Mozilla Firefox 109.0

$ inxi -CG
CPU:
Info: dual core model: AMD Athlon 64 X2 6000+ bits: 64 type: MCP cache:
L2: 1024 KiB
Speed (MHz): avg: 1000 min/max: 1000/3100 cores: 1: 1000 2: 1000
Graphics:
Device-1: AMD Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] driver: radeon
v: kernel
Device-2: KYE Systems (Mouse Systems) Genius Webcam type: USB
driver: snd-usb-audio,uvcvideo
Display: x11 server: X.Org v: 1.21.1.3 driver: X: loaded: ati,radeon
unloaded: fbdev,modesetting,vesa gpu: radeon resolution: 1280x1024
OpenGL: renderer: VERDE ( LLVM 15.0.6 DRM 2.50 5.15.0-57-generic)
v: 4.5 Mesa 22.3.2 - kisak-mesa PPA

Comment 135

[Rik]

@7etetic
It's now more than 6 month I don't have a crash ONLY thanks to
gfx.webrender.force-disabled = true
NO OTHER WAY. I've tested all the parameters of this world. Unfortunately this parameter is no longer present in the latest versions and the crashes are back. That's why I've pinned FF 91.13 in the hope that some day Mozilla will hopefully solve the problem despite at the moment they don't look very interested in this problem.
I wonder how FF manages to crash Linux is such a bad way, Windows BSOD style I'd say. I've never seen such "capability" in any other software on Linux.

Comment 136

[Rik]

PS: this massive bug is marked S4 that means
"Small/Trivial) minor significance, cosmetic issues, low or no impact to users "

This is not trivial/minor AT ALL because me and the others not only cannot use FF, but it's even a cause of DAMAGE to the OS and DATA LOSS because the computer freezes completely and only the hard reset solve the problem. How can this be seen as S4?!

This is an s2 bug to say the list.
"Serious) Major functionality/product severely impaired or a high impact issue and a satisfactory workaround does not exist"

If we remove the % of people with this problem, it's more an S1
"(Catastrophic) Blocks development/testing, may impact more than 25% of users, causes data loss, likely dot release driver, and no workaround available.

I've had data loss 2 times because of this bug. I cannot express enough my disappointment in how Mozilla ignores this problem and how I find ridiculous to see this bug marked as S1.

Comment 137

[Darkspirit]

(In reply to Rik from comment #135)

1. bug 1129492 and bug 1638466 caused bug 1803754.
   If you open Firefox in your terminal, do you get any "failed to open /dev/dri/renderD***: Permission denied" messages?
2. Maybe you are just running out of memory: Please try out setting browser.tabs.unloadOnLowMemory=true and restarting Firefox. (It's still not enabled by default due to bug 1780058.)
3. If 2 doesn't help: Would setting layout.frame_rate=60 (disabling GLX_SGI_video_sync) and restarting Firefox help?
4. If 3 doesn't help: Would setting gfx.webrender.software=true and webgl.disabled=true and restarting Firefox help?

Comment 138

[Rik]

(In reply to Darkspirit from comment #137)

If you open Firefox in your terminal, do you get any "failed to open /dev/dri/renderD***: Permission denied" messages?
Zero errors in terminal with both webrender or with webrender disable.

2. Maybe you are just running out of memory: Please try out setting browser.tabs.unloadOnLowMemory=true and restarting Firefox. (It's still not enabled by default due to bug 1780058.)
   I've already had this idea and for a while I've monitored the memory realtime. The OS freezes even at 10%.

3. If 2 doesn't help: Would setting layout.frame_rate=60 (disabling GLX_SGI_video_sync) and restarting Firefox help?
4. If 3 doesn't help: Would setting gfx.webrender.software=true and webgl.disabled=true and restarting Firefox help?
   No, there is only 1 parameter that solve the problem: gfx.webrender.force-disabled=true, nothing else. It's just webrender no matter how it is set. Even with gfx.webrender.software=true it freezes the system.

Comment 139

[Darkspirit]

(In reply to Rik from comment #138)

(In reply to Darkspirit from comment #137)

4. If 3 doesn't help: Would setting gfx.webrender.software=true and webgl.disabled=true and restarting Firefox help?

No, there is only 1 parameter that solve the problem: gfx.webrender.force-disabled=true, nothing else. It's just webrender no matter how it is set. Even with gfx.webrender.software=true it freezes the system.

Both hardware and software WebRender use the same font library, for example: https://searchfox.org/mozilla-central/source/gfx/wr/wr_glyph_rasterizer/src/platform/unix/font.rs
If I had this problem, I would disable as much features as possible to try to narrow this down. Please try this (websites might look different):
gfx.webrender.software:true
webgl.disabled:true
gfx.webrender.multithreading:false
browser.display.use_document_fonts:0
privacy.resistFingerprinting:true
layout.css.font-loading-api.enabled:false
gfx.downloadable_fonts.enabled:false
gfx.font_rendering.opentype_svg.enabled:false
gfx.font_rendering.graphite.enabled:false
gfx.color_management.mode:0
media.eme.enabled:false
media.gmp-widevinecdm.enabled:false

Comment 140

[Rik]

Guys, in all these comments the information get mixed and lost...
I've already said that FF freezes Linux (Debian 11) at random times, even NOT USING IT, simply keeping it open in the background.
I've even apt purge firefox-esr, removed the profile and restarted from scratch with a bare FF installation and it freezes as well.
I've tried a lot of disabling here and there at the point that FF becomes basically useless and despite that it freezes the OS anyway.
THE ONLY OPTION THAT WORK, 100% guaranteed is
gfx.webrender.force-disabled=true

It's now more that 6 months I use FF daily 10 hours per day without any problem.
When I enable webrender, no matter about any other parameter, no matter what I do with FF (even not using it), at random times it freezes the OS completely dead (no ctrl+alt+del, no ctrl+alt+f1, no ctrl+alt+backspace, no mouse moving, no caps lock switching the led, no ping reply, DEAD 100%, only hard reset or turning off the UPS works).
gfx.webrender.force-disabled=true solves everything.

Now, if the problem were that FF stop responding, no problem keep going making tests forever, but since it freezes the computer entirely at random times, I cannot go on making experiments forever finding myself with a blocked PC while coding, while making remote assistance to a client, in the middle of a payment, and other similar situations. I mean I'm not using the PC for leisure and every time FF freezes the computer I always have a certain degree of damage depending on what I'm doing. That's why I'm now tired of investigating this problem.

Comment 141

[Darkspirit]

(In reply to Rik from comment #140)
Please test https://nightly.mozilla.org with the prefs from comment 139.
If your desktop still freezes, try Gnome Wayland for comparison and start Firefox with MOZ_ENABLE_WAYLAND=1 environment variable
($ MOZ_ENABLE_WAYLAND=1 path/to/firefox).
If your desktop still freezes, please try upgrading to Debian bookworm (it will become Debian Stable this summer).

Comment 142

[Rik]

I cannot use this computer for experiments. I've tried a lot of option in about:config but I cannot install wayland or do important modifications to the system (by the way the DE is not Gnome is Mate).

COULD BE IMPORTANT
I don't know what are the difference in regards to webrender from FF standard and Dev edition, but I can say that the Dev Edition downloaded from https://www.mozilla.org/en-US/firefox/developer/ and installed manually in /opt/ since it was v 90 or so up to now that is 109, it has never had problems with webrender and webGL both active.
The same version of FF-ESR from Debian freezes the OS (test made with both v 102).

SO...

1. Dev edition could be different in the way it make use/set webrender
2. Or the version from the Debian repo (=tons of other sub-distro like Ubuntu) is compile differently and that's the culprit.
   In this latter case would be nice whether Mozilla talked to Debian about this problem. I certanly can't tell Debian how to compile FF wrong compared to the original bins on FF website. Moreover I find it hard to believe that the main distro in the world makes such an error in compiling an app for its own main repo in the stable branch... but could be.

Comment 143

[mikhail]

What is your platform? Skylake? Firmware i915/skl_dmc_ver1_27.bin?

Comment 144

[mikhail]

Show the dmesg | grep dmc output

Comment 145

[Rik]

dmesg says it's a i915/kbl_dmc_ver1_04.bin
[drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on minor 0
but actually it's a clean natural Debian without any proprietary blob added.
MB: Asrock z370 Extreme4
Intel Corporation CometLake-S GT2 [UHD Graphics 630]
VGA compatible controller: Intel Corporation CometLake-S GT2 [UHD Graphics 630] (prog-if 00 [VGA controller])
Kernel driver in use: i915
Kernel modules: i915

Comment 146

[mikhail]

(In reply to Rik from comment #145)

dmesg says it's a i915/kbl_dmc_ver1_04.bin

This is a problem with intel firmware.

https://gitlab.freedesktop.org/drm/intel/-/issues/4858#note_1599342
They recommend using the guc firmware.
https://gitlab.freedesktop.org/drm/intel/-/issues/4858#note_1425529
Or play with the frequency.

Comment 147

[mikhail]

Pardon me, enable FBC:

i915.force_enable_fbc_with_vtd=1

But, I, too, like you, am tired of experimenting. Frequency limitation helped me.

Comment 148

[Rik]

I want anyone here keep in mind this points

**(1) The FF Dev edition factor **
Whatever it is, I wonder why FF dev edition has never had such problem. I use FF dev edition (99% on LAN) since its inception and has never frozen Debian. I can run webGL stress tests and keep it running forever and nothing happen, while FF ESR from the Debian repo freezes the OS even on a static blank page and even minimized, at random times (ranging from 1 day to 2 weeks). Can anyone explain that?

**(2) The non stress factor **
Why with FF ESR, fresh install, new profile, no addons, all defaults with webrender, webgl, etc. I can run stress tests of any kind for 1 hour and nothing happens, while simply keeping it open on a blank page, not touching it, at a certain point it freezes the OS?
Most of the time when the OS freezes I'm not using FF, it's simply minimazed. At times it happens when I simply click something, e.g. the volume slider on Youtube o some other components on simple pages with no video no nothing simply a web form.
Doesn't look a matter of stress or GPU problems but simply a matter of having the webrender process loaded.

Comment 149

[mikhail]

I had the same problem with xfce. Firefox calls some library for you, for example, the fonts you wrote above.

Comment 150

[7etetic]

(In reply to 7etetic from comment #134)
I was wrong, disabling WebGL doesn't help. After a couple weeks of using FF 108/109 on Ubuntu 22.04 I got the whole system hanging again. This happened when I tried to continue playing a paused video in an online movie theater (not YouTube). Before that, I had been watching that video for an hour without any freezes. I don't know what else I can do with FF settings to stop such annoying behavior of it.

Comment 151

[Darkspirit]

(In reply to Rik from comment #148)

I want anyone here keep in mind this points

**(1) The FF Dev edition factor **
Whatever it is, I wonder why FF dev edition has never had such problem.

while FF ESR from the Debian repo freezes the OS even on a static blank page and even minimized, at random times (ranging from 1 day to 2 weeks). Can anyone explain that?

It would be interesting if you get desktop freezes with Mozilla-built ESR91 as well: https://ftp.mozilla.org/pub/firefox/releases/91.13.0esr/linux-x86_64/en-US/firefox-91.13.0esr.tar.bz2
But be careful: Don't restart it as it might instantly upgrade to ESR 102.

If I understand correctly, the rust compiler version (1.41.1) in Debian stable is older than minimum required rustc version for Firefox ESR 102.
Then they created a rustc-mozilla package (1.59.0) with a newer but still old rust compiler.

bug 1504858: 109 (DevEdition/Beta) requires 1.63.0 and is built with 1.65.0, maybe even 1.66.

Non-Mozilla-made ESR91 builds had also been affected by bug 1735905 comment 11.

In case of problems, one should test https://nightly.mozilla.org (Nightly+built by Mozilla). If it's unaffected, it's possible to narrow down a fix range (pip3 install mozregression; mozregression --find-fix --bad 91 --good 2023-01-12) if the problem was not caused by the build environment.

Comment 152

[Rik]

(In reply to Darkspirit from comment #151)

It would be interesting if you get desktop freezes with Mozilla-built ESR91 as well: https://ftp.mozilla.org/pub/firefox/releases/91.13.0esr/linux-x86_64/en-US/firefox-91.13.0esr.tar.bz2
But be careful: Don't restart it as it might instantly upgrade to ESR 102.

I could try ESR91 from Mozilla, but I can't tell you if it works properly before at least 20 days of no freezes. Actually I don't know why I didn't try that before... or I did? I don't remember. I'm gonna try. The risk of a crash is worth the candle. :-)

OT:: Debian 11 is a version to forget, the worse ever released. I had zero problems with Buster and previous releases and now have tons with Bullseye, including the latest problem of being stuck with kernel 5.10.0-14-amd64 because of VirtualBox. Let's hope v 12 would be better.

Comment 153

[Rik]

I've installed the esr from mozilla and disabled the auto update. However I can't find a way to stop the notification every time I open FF. It's quite annoying if I have to dismiss the notification every time I open FF.

Comment 154

[Rik]

Having a look into about:config for "update" I've found this option useful to get rid of the notification I think I've found the solution this way:
app.update.auto false
app.update.checkInstallTime false
app.update.checkInstallTime.days 0

Now I can test V91 from mozilla repo as per Darkspirit suggestion.
If no freezes in the next 20 days... I'll let you know and that will be the definitive solution. :-)

Comment 155

[7etetic]

I guess in my case the problem was with the hardware video acceleration settings. The following settings were changed to enable acceleration:

gfx.webrender.all true
gfx.webrender.enabled true
media.ffmpeg.vaapi.enabled true

It has been 20 days without freezes after I returned these settings to their default values (default is false).