I also have reason to believe, that it is a Firefox issue.
It behaves exactly the same way for me, even though I explained it differently in my thread:
/ Hans Gatu
I also have reason to believe, that it is a Firefox issue.
It behaves exactly the same way for me, even though I explained it differently in my thread:
/ Hans Gatu
Iām pretty sure it is Firefox because if I install Chrome (Chromium) it doesnāt have this issue.
System:
Kernel: 5.15.78-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
parameters: BOOT_IMAGE=/boot/vmlinuz-5.15-x86_64
root=UUID=38bf1d9c-d4fd-4d72-b6cb-8407756db8fd ro quiet
udev.log_priority=3
Desktop: GNOME v: 43.1 tk: GTK v: 3.24.34 wm: gnome-shell dm: GDM v: 43.0
Distro: Manjaro Linux base: Arch Linux
Machine:
Type: Desktop Mobo: EVGA model: 141-BL-E757 v: Tylersburg
serial: BIOS: Phoenix v: 6.00 PG date: 08/25/2011
Battery:
Device-1: hidpp_battery_0 model: Logitech M510 serial:
charge: 55% (should be ignored) rechargeable: yes status: discharging
CPU:
Info: model: Intel Core i7 920 bits: 64 type: MT MCP arch: Nehalem
gen: core 1 level: v2 built: 2008-10 process: Intel 45nm family: 6
model-id: 0x1A (26) stepping: 5 microcode: 0x1D
Topology: cpus: 1x cores: 4 tpc: 2 threads: 8 smt: enabled cache:
L1: 256 KiB desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB desc: 4x256 KiB
L3: 8 MiB desc: 1x8 MiB
Speed (MHz): avg: 1605 high: 1686 min/max: 1596/2661 boost: enabled
scaling: driver: acpi-cpufreq governor: schedutil cores: 1: 1592 2: 1592
3: 1592 4: 1606 5: 1592 6: 1592 7: 1686 8: 1592 bogomips: 42469
Flags: ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3
Vulnerabilities:
Type: itlb_multihit status: KVM: VMX unsupported
Type: l1tf mitigation: PTE Inversion
Type: mds status: Vulnerable: Clear CPU buffers attempted, no microcode;
SMT vulnerable
Type: meltdown mitigation: PTI
Type: mmio_stale_data status: Unknown: No mitigations
Type: retbleed status: Not affected
Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
prctl and seccomp
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
sanitization
Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW,
STIBP: conditional, RSB filling, PBRSB-eIBRS: Not affected
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
Graphics:
Device-1: AMD Cape Verde XT [Radeon HD 7770/8760 / R7 250X] vendor: Hightech
Information System driver: radeon v: kernel alternate: amdgpu arch: GCN-1
code: Southern Islands process: TSMC 28nm built: 2011-20 pcie: gen: 2
speed: 5 GT/s lanes: 16 link-max: gen: 3 speed: 8 GT/s ports:
active: DVI-I-1 empty: DP-1,DP-2,HDMI-A-1 bus-ID: 02:00.0
chip-ID: 1002:683d class-ID: 0300 temp: 37.0 C
Display: x11 server: X.Org v: 21.1.4 with: Xwayland v: 22.1.5
compositor: gnome-shell driver: X: loaded: radeon unloaded: modesetting
alternate: fbdev,vesa dri: radeonsi gpu: radeon display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
s-diag: 582mm (22.93")
Monitor-1: DVI-I-1 mapped: DVI-0 model: Asus VH242H serial:
built: 2012 res: 1920x1080 hz: 60 dpi: 94 gamma: 1.2
size: 521x293mm (20.51x11.54") diag: 598mm (23.5") ratio: 16:9 modes:
max: 1920x1080 min: 720x400
API: OpenGL Message: Unable to show GL data. Required tool glxinfo
missing.
Audio:
Device-1: Intel 82801JI HD Audio driver: snd_hda_intel v: kernel
bus-ID: 00:1b.0 chip-ID: 8086:3a3e class-ID: 0403
Device-2: AMD Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000
Series] vendor: Hightech Information System driver: snd_hda_intel
v: kernel pcie: gen: 2 speed: 5 GT/s lanes: 16 link-max: gen: 3
speed: 8 GT/s bus-ID: 02:00.1 chip-ID: 1002:aab0 class-ID: 0403
Sound API: ALSA v: k5.15.78-1-MANJARO running: yes
Sound Server-1: JACK v: 1.9.21 running: no
Sound Server-2: PulseAudio v: 16.1 running: yes
Sound Server-3: PipeWire v: 0.3.59 running: yes
Network:
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: de00
bus-ID: 06:00.0 chip-ID: 10ec:8168 class-ID: 0200
IF: enp6s0 state: up speed: 1000 Mbps duplex: full mac:
Drives:
Local Storage: total: 1.25 TiB used: 357.36 GiB (28.0%)
SMART Message: Required tool smartctl not installed. Check --recommends
ID-1: /dev/sda maj-min: 8:0 vendor: Western Digital
model: WD5001AALS-00L3B2 size: 465.76 GiB block-size: physical: 512 B
logical: 512 B speed: 1.5 Gb/s type: N/A serial: rev: 3B01
scheme: MBR
ID-2: /dev/sdb maj-min: 8:16 vendor: Kingston model: SA400S37120G
size: 111.79 GiB block-size: physical: 512 B logical: 512 B speed: 3.0 Gb/s
type: SSD serial: rev: 71E0 scheme: MBR
ID-3: /dev/sdc maj-min: 8:32 vendor: Samsung model: SSD 850 EVO 250GB
size: 232.89 GiB block-size: physical: 512 B logical: 512 B speed: 3.0 Gb/s
type: SSD serial: rev: 2B6Q scheme: MBR
ID-4: /dev/sdd maj-min: 8:48 vendor: Samsung model: SSD 860 EVO 500GB
size: 465.76 GiB block-size: physical: 512 B logical: 512 B speed: 3.0 Gb/s
type: SSD serial: rev: 4B6Q
Partition:
ID-1: / raw-size: 111.79 GiB size: 109.47 GiB (97.93%)
used: 71.96 GiB (65.7%) fs: ext4 dev: /dev/sdb1 maj-min: 8:17
Swap:
Alert: No swap data was found.
Sensors:
System Temperatures: cpu: 44.0 C mobo: N/A gpu: radeon temp: 37.0 C
Fan Speeds (RPM): N/A
Info:
Processes: 270 Uptime: 1h 2m wakeups: 20 Memory: 11.68 GiB
used: 1.94 GiB (16.6%) Init: systemd v: 251 default: graphical
tool: systemctl Compilers: gcc: 12.2.0 clang: 14.0.6 Packages: 1510
pm: pacman pkgs: 1499 libs: 449 tools: gnome-software,pamac pm: flatpak
pkgs: 0 pm: snap pkgs: 11 Shell: Bash v: 5.1.16 running-in: gnome-terminal
inxi: 3.3.23
I just thought that Iād share this little tidbit I found that seems to describe this bug:
https://www.reddit.com/r/firefox/comments/z1pnw6/libx11_1822_causes_firefox_107_to_freeze_under/
So it sounds like itās an error with libx11 1.8.2. Hopefully it will get fixed soon.
I can confirm the issue described here. Starting Firefox - regardless of whether this is from the menu or from a Konsole command line, regardless of whether itās the latest version from the repositories, from Snap, or from a download from the Mozilla site - creates 3 instances of firefox-bin visible in the system activity monitor, but without any window. Thereās no error message.
Repeated attempts to start Firefox (I had a whole 18 processes āfirefox-binā running at one point earlier today) eventually result in one of these processes turning āzombieā. I donāt know whether this matters, but after this the Firefox dialogue box appears on the screen to tell me that Firefox is already running but not responding. At that point, I can ākillall firefox-binā and start Firefox again. This time a SINGLE āfirefox-binā process is started, and a Firefox window opens in the expected way. Firefox works perfectly after this. Closing the window and starting Firefox again also works as expected. But this lasts only until the next system shutdown and reboot, after which the faulty behaviour described above reappears.
By contrast, as others have explained, simply killing and restarting Firefox doesnāt work reliably.
This is a very annoying problem. Firefox is the only application I use literally every day.
Well as I showed in later post on KDE at least ⦠problem is only with start-up of Firefox ⦠that spawns multiple process identities and all are āFirefoxā I canāt tell what exactly these are ā¦
But I can absolutely perfectly resume start-up by killing the last process identity as I have shown on the picture of reply 31 (Firefox runs without interface - #31 by ff8idiot). After that only the first process identity remains and Firefox GUI window frames do spawn. At least on KDE itās consistent in this start-up behaviour.
But absolutely nothing else helped ā¦
.mozilla
configuration under /home/xxx/
.mozilla
to whatever else so Firefox canāt find files anymorefirefox --new-window about:processes
canāt be used for start-up since no GUI (graphic user interface) will spawn and you have nothing to look at.Itās just that start-up of Firefox that freezes up. After unfreeze with killing the last of Firefox process identities, Firefox just works perfectly as always ⦠with all od my settings and extensions and tabs as I want them and should be.
Killing and restarting all of Firefox processes and re-attempting whole start-up again is just overkill. And even if you do and eventually arrive to this dialog:
You can just hit [Open] to have all the tabs re-opened, since Refresh resolves nothing about start-up. But with [Open] you have all extensions disabled. And as a result you have to re-start Firefox again to have extensions re-enabled ⦠and again chances are start-up problem might just happen all over again ⦠after you perhaps already re-started whole Firefox like 8 ⦠12 (or even more) times.
So the problem is just mildly annoying, since it requires us to involve ourselves in start-up ⦠But with killing all Firefox processes and re-starting we ourselves are just escalating the problem.
Nothing that I didnāt report before in perhaps too much details. So this time I will let pictures do the talking:
Trying to run Firefox from GUI (KDE in my case)
Icon is there, loading is visible ā¦
And than nothing ⦠you are watching episode of āDude where is my Firefoxā.
Now to āunfreezeā Firefox startup ā¦
And it worked for me ā¦
Just closing Firefox with Ctrl + Q and confirming with [Close and Quit] put me back into another episode of āDude, where is my Firefoxā after I try to (re)run Firefox again.
I need to mitigate Firefox startup again with
kill $(pgrep firefox | tail -n 1)
But i want you to know this works and I can start Firefox 100%. Hope this helped anyone.
Starting from console this time did show an error though:
[GFX1-]: glxtest: VA-API test failed: process crashed. Please check your VA-API drivers.
Maybe that is the last process identity I killed ā¦
This is the exact issue I have with FF on my Mint xfce install. On Manjaro, it works fine. Go figure.
Itās been hit and miss with this issue for the last few days. Some days i have the issue, but other days FF starts up right away. Iām starting to wonder if on the days I donāt have the issue are those days were I let the computer sit for a few minutes after booting (to go get a coffee or something) instead of starting FF right away. I canāt see why this would make a difference, but other than some other random thing happening, this is the only difference I can see.
Funny enough I upgraded my laptop from the LTS Ubuntu to the latest version last night and now Iām having this exact same problem. To me this says itās a Firefox issue not a Linux issue unless itās a common module that both Ubuntu and Manjaro share somehow.
Have you tried what nkgnomic proposes in this thread :
Try this to open a Firefox widow showing Troubleshooting Information page
firefox --new-window about:support
and click on Clear startup cacheā¦
This solution solved for my FF problem
@Denis_Pom I will repeat ā¦
firefox --new-window about:support
Does not even start Firefox ⦠Nor does [Clear Startup Cache] change anything. No matter if I reach to about:support
page from console or from already open instance.
It isnāt even Linux distro issue, much less Manjaroās issue.
Last I checked for actually reported error with
[GFX1-]: glxtest: VA-API test failed: process crashed. Please check your VA-API drivers
Itās problem with AMD drivers that are within mesa
(mesa-vdpau
) and indeed ⦠mesa
was upgraded 22.1.7 => 22.2.x now at beginning of November 2022.
I checked https://gitlab.manjaro.org/-/snippets/810/raw/main/boxit-update-2022-11-02-s.txt Gitlab changelist for 2022-11-02 Majaro packages upgrade (search for mesa
and mesa-vdpau
).
Also I know Ubuntu LTS (22.04.1) has mesa
at 22.0.x, but latest (22.10) has mesa
at 22.2.x. Weirdly enough I have no issues using Lubuntu 22.10 at work, but that one runs as Hyper-V virtual machine so no graphic card.
I downgraded mesa packages back to 2.1.7 and Firefox now started perfectly a few times even after machine reboot ⦠so it seems so far it has worked for me:
sudo downgrade mesa vulkan-radeon vulkan-intel lib32-vulkan-radeon lib32-vulkan-intel libva-mesa-driver lib32-mesa-vdpau lib32-mesa lib32-libva-mesa-driver mesa-vdpau
After reboot of machine it opened Firefox on first try. Also closing and re-opening turned out to be without any problems⦠so far.
But this is another ācan of wormsā solution, because mesa
and integrated drivers will be inevitably upgraded and shipped with all Linux distributions ⦠so eventually I will have to go along with these upgrades. Or something might just break eventually, since package x and y might become out-of-sync.
There were mesa Radeon driver upgrades this morning and for a few minutes I had hope that they would fix the issue, but no. It took me several tries to get Firefox to open. Even killing the process and trying again didnāt help. The only thing that eventually allowed me to start FF was starting it in Safe Mode (after being prompted). After that FF worked normally even when not in Safe Mode.
Yep, still the same problem for me, although I tried all the workarounds suggested above. And this is definitely not a KDE issue (Iām running GNOME).
I was hoping that yesterdays Manjaro update should solve the problem.
There were both an Firefox update, as well as a kernel update.
It didnāt help, though.
/ Hans Gatu
After the new system update and reboot, Firefox did not open its window, and I made different tests :
firefox --new-window about:support
and click on Clear startup cache⦠then click on Restart FF
FF reopens the single tab window and my FF window with all my tabs. Then I can close FF and start it without problem.
So, there is problem somewhere ā¦
firefox --new-window about:support
That didnāt work for me. That was the first thing I tried before having to attempt to open FF and kill the process a few times until it said something about safe mode. The problem is definitely with FF as this happens on my Ubuntu laptop now as well. I guess weāll just have to hope they figure out the issue sooner or later.
You are right. This workaround seems to work for me, too. Starting Firefox from the Konsole starts 3 processes called Firefox, but no window. Killing one of these 3 processes causes a Firefox window to appear. The Konsole produces the following messages when I kill one of the original 3 processes. I donāt know whether they are useful.
[GFX1-]: glxtest: VA-API test failed: process crashed. Please check your VA-API drivers.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
[2022-12-07T21:48:22Z ERROR glean_core::metrics::ping] Invalid reason code startup for ping background-update
So, there is problem somewhere ā¦
Thereās clearly a bug, indeed. On another topic, someone mentioned that this could be caused by specific Manjaro settings for Firefox (maybe in the package manjaro-browser-settings
). Donāt have any clue, and the process to report this kind of weird and unidentified bug to Manjaro devs is still unclear to me.
This really was just a guess of that āsomeoneā, I guess
but to rule that one out and for peace of mind
it is easy to deinstall that package.