On Wed, Apr 01, 2026 at 08:54:19AM -0700, Van Snyder wrote:

I don't know whether Firefox does it, or Trixie does it, or the phase
of the Moon does it, but every time I push Firefox's "Restart to
continue using Firefox" button after an update, Trixie ÿcrashes.

kinfocenter reports

[...]

Does anybody else have this problem?

I haven't, but a bit more of detail for "crashes" would help others
help you:
- does the machine react to console switch (Ctrl-Alt-F1 or similar)?
- is the machine reachable via SSH? Ping?
- Anything in the logs?
That kind of stuff.
Cheers
--
t


--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hello,

Am Mittwoch, den 01. April schrieb Van Snyder:

I don't know whether Firefox does it, or Trixie does it, or the phase
of the Moon does it, but every time I push Firefox's "Restart to
continue using Firefox" button after an update, Trixie ÿcrashes.

kinfocenter reports

Operating System: Debian GNU/Linux 13
KDE Plasma Version: 6.3.6
KDE Frameworks Version: 6.13.0
Qt Version: 6.8.2
Kernel Version: 6.12.74+deb13+1-amd64 (64-bit)
Graphics Platform: X11
Processors: 32 ? Intel? Core? i9-14900K
Memory: 32 GiB of RAM (31.1 GiB usable)
Graphics Processor 1: AMD Radeon RX 580 Series
Graphics Processor 2: Intel? Graphics
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7E06
System Version: 3.0

Does anybody else have this problem?

Not the exact same, but similar. Firefox crashed my trixie. Logfiles
indicated a GPU problem (Radeon R7 250).
The solution was to disable hardware-acceleration in the firefox
settings.
Disabled ?Use recommended performance settings?
and ?Use hardware acceleration when available?

MfG
bmg

--
?Des is v”llig wurscht, was heut beschlos- | M G Berberich
sen wird: I bin sowieso dagegn!? | mail@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg) |

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Am Mittwoch, den 01. April schrieb Van Snyder:

On Wed, 2026-04-01 at 18:38 +0200, M G Berberich wrote:

Hello,

Am Mittwoch, den 01. April schrieb Van Snyder:

I don't know whether Firefox does it, or Trixie does it, or the
phase
of the Moon does it, but every time I push Firefox's "Restart to
continue using Firefox" button after an update, Trixie ÿcrashes.

kinfocenter reports

Operating System: Debian GNU/Linux 13
KDE Plasma Version: 6.3.6
KDE Frameworks Version: 6.13.0
Qt Version: 6.8.2
Kernel Version: 6.12.74+deb13+1-amd64 (64-bit)
Graphics Platform: X11
Processors: 32 ? Intel? Core? i9-14900K
Memory: 32 GiB of RAM (31.1 GiB usable)
Graphics Processor 1: AMD Radeon RX 580 Series
Graphics Processor 2: Intel? Graphics
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7E06
System Version: 3.0

Does anybody else have this problem?

Not the exact same, but similar. Firefox crashed my trixie. Logfiles indicated a GPU problem (Radeon R7 250).
The solution was to disable hardware-acceleration in the firefox
settings.
Disabled ?Use recommended performance settings?
and ?Use hardware acceleration when available?

What log did you look at? Where are the Firefox settings you changed?

The kernel-massages had GPU errors.

In the firefox settings (Hamburger-menu?Settings or
about:preferences): General ? Performance

MfG
bmg

--
?Des is v”llig wurscht, was heut beschlos- | M G Berberich
sen wird: I bin sowieso dagegn!? | mail@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg) |

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, Apr 01, 2026 at 01:45:27PM -0700, Van Snyder wrote:

On Wed, 2026-04-01 at 21:51 +0200, M G Berberich wrote:

The kernel-massages had GPU errors.

I used to look for such errors in /var/log/error*, but those files no
longer exist, at least not on my computer. Where are they now? "dmesg -
k" appears to show messages only since the most recent boot. Can I look
at previous errors using dmesg? If not dmesg, how?

Use journalctl -- use options --since & --until to select the part near the crash.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, Apr 01, 2026 at 06:38:59PM +0200, M G Berberich wrote:

Am Mittwoch, den 01. April schrieb Van Snyder:

I don't know whether Firefox does it, or Trixie does it, or the phase
of the Moon does it, but every time I push Firefox's "Restart to
continue using Firefox" button after an update, Trixie ÿcrashes.

kinfocenter reports

Operating System: Debian GNU/Linux 13
KDE Plasma Version: 6.3.6
KDE Frameworks Version: 6.13.0
Qt Version: 6.8.2
Kernel Version: 6.12.74+deb13+1-amd64 (64-bit)
Graphics Platform: X11
Processors: 32 ? Intel? Core? i9-14900K
Memory: 32 GiB of RAM (31.1 GiB usable)
Graphics Processor 1: AMD Radeon RX 580 Series
Graphics Processor 2: Intel? Graphics
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7E06
System Version: 3.0

Does anybody else have this problem?

Not the exact same, but similar. Firefox crashed my trixie. Logfiles indicated a GPU problem (Radeon R7 250).
The solution was to disable hardware-acceleration in the firefox
settings.

I have been getting crashes on Debian Trixie that seem related to the video card, I can often ssh in to start a shutdown - a reboot is not enough. I have a Radeon HD 7850. I was going to replace the video card but have not got round to it.

lshw tells me:

*-display
description: VGA compatible controller
product: Pitcairn PRO [Radeon HD 7850 / R7 265 / R9 270 1024SP]
vendor: Advanced Micro Devices, Inc. [AMD/ATI]
physical id: 0
bus info: pci@0000:01:00.0
logical name: /dev/fb0
version: 00
width: 64 bits
clock: 33MHz
capabilities: pm pciexpress msi vga_controller bus_master cap_list rom fb
configuration: depth=32 driver=radeon latency=0 resolution=1920,1080
resources: irq:29 memory:d0000000-dfffffff memory:fdd80000-fddbffff ioport:ee00(size=256) memory:c0000-dffff

From journalctl I see:

Mar 01 14:56:24 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: ring 5 stalled for more than 10236msec
Mar 01 14:56:24 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: GPU lockup (current fence id 0x00000000000054ca last fence id 0x00000000000054cc on ring 5)

then many:

Mar 01 14:56:24 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: scheduling IB failed (-35).
Mar 01 14:56:24 mint.phcomp.co.uk kernel: [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)

A bit later:

Mar 01 14:56:25 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: ring 3 stalled for more than 10236msec
Mar 01 14:56:25 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: GPU lockup (current fence id 0x0000000000d8773d last fence id 0x0000000000d87a88 on ring 3)
Mar 01 14:56:25 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: ring 5 stalled for more than 10752msec
Mar 01 14:56:25 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: GPU lockup (current fence id 0x00000000000054ca last fence id 0x00000000000054cc on ring 5)
Mar 01 14:56:25 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: ring 0 stalled for more than 10908msec
Mar 01 14:56:25 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: GPU lockup (current fence id 0x00000000016b8554 last fence id 0x00000000016b85e5 on ring 0)
Mar 01 14:56:25 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: scheduling IB failed (-35).

Later a crash & back-trace (ask me if you really want it).

Disabled ?Use recommended performance settings?
and ?Use hardware acceleration when available?

I have done this (Firefox settings) ... if it does not crash again in the next week I will deem it fixed.

Regards

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, Apr 01, 2026 at 01:47:50PM -0700, Van Snyder wrote:

On Wed, 2026-04-01 at 21:51 +0200, M G Berberich wrote:

Disabled ?Use recommended performance settings?
and ?Use hardware acceleration when available?

What log did you look at? Where are the Firefox settings you
changed?

In the firefox settings (Hamburger-menu?Settings or
about:preferences): General ? Performance

Thanks. I found and disabled them.

It is now a week since I also disabled these in Firefox. Before so doing I had had a problem every day or few. I think that it is reasonable to assume a cause.

A user program should not be able to do this. Who should I report this to, a Debian maintainer or direct to the kernel mail list ?

I have the journal logs which, hopefully, will be useful at finding the problem.

Regards

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-04-08 at 03:49, alain williams wrote:

On Wed, Apr 01, 2026 at 01:47:50PM -0700, Van Snyder wrote:

On Wed, 2026-04-01 at 21:51 +0200, M G Berberich wrote:

In the firefox settings (Hamburger-menu?Settings or
about:preferences): General ? Performance

Thanks. I found and disabled them.

It is now a week since I also disabled these in Firefox. Before so
doing I had had a problem every day or few. I think that it is
reasonable to assume a cause.

A user program should not be able to do this. Who should I report
this to, a Debian maintainer or direct to the kernel mail list ?

Based on how I understand matters, the user program (Firefox) is not, in
fact, doing this; it's just the triggering factor. The thing producing
the freeze/crash in cases like this is, from what I understand,
invariably in one of three places: the graphics driver, the GPU
*firmware*, or the userspace graphics stack (between the driver and the user-facing application).
So the bug report should go to wherever the code for the component in
question is maintained.
For the graphics driver, if you're using one of the open graphics
drivers, that will likely be either the kernel or a separate tree where
the driver is developed. If you're using a proprietary graphics driver, however, it will almost certainly be the company who provides that
opaque binary driver (and, as of the last time I was paying close
attention to such things, sometimes an opaque binary graphics stack
along with it) - in which case, good luck.
For the userspace graphics stack, it will *probably* be the Mesa
project. For proprietary drivers, however, see the parenthetical above.
And if the problematic component is the firmware, you're almost
*certainly* going to be dealing with the company who provides the GPU,
since if there are any successful open-GPU-firmware projects out there - especially ones for anything vaguely like current/modern GPUs - I'm not
aware of them.
I don't think I have enough information about the issue to be able to
advise as to which of these is the most likely appropriate place. If I
were in such a situation myself, I'd either ask for advice on how to
figure that out (whether by asking here, or asking in a bug report
against the Debian package of the graphics driver, or asking on the LKML
or in Mesa support forums, or wherever else seemed like the best fit for
such a question), or give up and just file the report against the
graphics driver and hope (politely) that they'd be able to figure out
where it should be redirected to.

I have the journal logs which, hopefully, will be useful at finding
the problem.

One may hope, but unless (and possibly even if) there's a stack trace in
those logs, I suspect it more likely that it will be necessary to enable
debug logging in some way - which might involve installing a custom
debug build of the graphics driver, or of the stack component in
question - and then reproduce the failure.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw


--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, Apr 08, 2026 at 01:48:13PM +0000, David wrote:

Hi, that was all good advice. I'd add that before making a bug report,
I'd suggest checking something like:

$ sudo journalctl -b -g 'not supported'

I get:

Apr 05 00:12:03 mint.phcomp.co.uk xdg-desktop-por[3009]: A backend call failed: Inhibiting other than idle not supported

So are you saying that there is no point in telling anyone and just use the FF config workaround (which appears to make no difference to what I see) ?

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 8 Apr 2026 at 14:00, alain williams <addw@phcomp.co.uk> wrote:

On Wed, Apr 08, 2026 at 01:48:13PM +0000, David wrote:

Hi, that was all good advice. I'd add that before making a bug report,
I'd suggest checking something like:

$ sudo journalctl -b -g 'not supported'

I get:

Apr 05 00:12:03 mint.phcomp.co.uk xdg-desktop-por[3009]: A backend call failed:
Inhibiting other than idle not supported

That particular message is not from your graphics driver, so it's not relevant. My graphics driver is 'amdgpu'. You would need to check all the messages
issued by whatever graphics driver you are using.

So are you saying that there is no point in telling anyone and just use the FF
config workaround (which appears to make no difference to what I see) ?

That's my situation here. Some graphic things in Firefox don't work
correctly, but
at least it doesn't crash. Your situation might be different. So I'm
just suggesting
to check your logs as a first step, before complaining that something "doesn't work", if the log already told you that it won't work because it isn't supported.

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi, that was all good advice. I'd add that before making a bug report,
I'd suggest checking something like:

$ sudo journalctl -b -g 'not supported'

because if the GPU driver is reporting that certain graphics capabilities
are not supported, then the bug would be in the software that attempts
to use those capabilities when they aren't available.

If it crashes the whole OS, the bug is not just in the application but
further down (somewhere in the stack, as described by the Wanderer).


=== Stefan

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, Apr 08, 2026 at 10:48:32AM -0400, Stefan Monnier wrote:

Hi, that was all good advice. I'd add that before making a bug report,
I'd suggest checking something like:

$ sudo journalctl -b -g 'not supported'

because if the GPU driver is reporting that certain graphics capabilities are not supported, then the bug would be in the software that attempts
to use those capabilities when they aren't available.

If it crashes the whole OS, the bug is not just in the application but further down (somewhere in the stack, as described by the Wanderer).

Usually, but not always, I can ssh in, send a few signals to some applications and then type 'poweroff'. This kills the ssh session so I cannot see what happens after that but on subsequent reboot I see complaints about the system journal being corrupt/not-cleanly-closed - so I guess that it does not shut down cleanly/completely.

This could be because anything that tries to write to the screen freezes due to the crashed video card; there are many messages send on system shutdown. But this is a guess as I cannot see anything.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi, that was all good advice. I'd add that before making a bug report,
I'd suggest checking something like:

$ sudo journalctl -b -g 'not supported'

because if the GPU driver is reporting that certain graphics capabilities >> > are not supported, then the bug would be in the software that attempts
to use those capabilities when they aren't available.

If it crashes the whole OS, the bug is not just in the application but
further down (somewhere in the stack, as described by the Wanderer).

Usually, but not always, I can ssh in, send a few signals to some applications and then type 'poweroff'.

Aha: I assumed "crashes Trixie" means the whole OS crashed.

If you can still access the machine via SSH, then presumably only the
video part is wedged. Still: if the whole user session is made unusable
and the graphics stack is sufficiently confused that you can't "log out and
log back in" (as seems to be the case based on your description), then
the problem is not just in the application but somewhere within the
graphics stack.


=== Stefan

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, Apr 09, 2026 at 09:32:22AM -0400, Stefan Monnier wrote:

Hi, that was all good advice. I'd add that before making a bug report, >> > I'd suggest checking something like:

$ sudo journalctl -b -g 'not supported'

because if the GPU driver is reporting that certain graphics capabilities
are not supported, then the bug would be in the software that attempts >> > to use those capabilities when they aren't available.

If it crashes the whole OS, the bug is not just in the application but
further down (somewhere in the stack, as described by the Wanderer).

Usually, but not always, I can ssh in, send a few signals to some applications and then type 'poweroff'.

Aha: I assumed "crashes Trixie" means the whole OS crashed.

If you can still access the machine via SSH, then presumably only the
video part is wedged. Still: if the whole user session is made unusable
and the graphics stack is sufficiently confused that you can't "log out and log back in" (as seems to be the case based on your description), then
the problem is not just in the application but somewhere within the
graphics stack.

Your description is correct. Graphics/console becomes unusable, it freezes showing whatever was being displayed. Curiously the mouse still moves. Sometimes (wild estimate of 1 in 5 times) the screen goes completely white.

I set firefox (& librewolf) config to not use hardware acceleration.

Stable for a week, but a couple of hours after me telling the list it happened again. I clicked on a link in Firefox and it froze. I was able to ssh in send HUP to important applications & start shutdown.

Messages in the system journal, many like this:

Apr 08 16:22:16 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: ring 0 stalled for more than 10484msec
Apr 08 16:22:16 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: GPU lockup (current fence id 0x0000000002bf98d1 last fence id 0x0000000002bf9958 on ring 0)
Apr 08 16:22:16 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: ring 5 stalled for more than 10236msec
Apr 08 16:22:16 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: GPU lockup (current fence id 0x0000000000041106 last fence id 0x0000000000041107 on ring 5)
Apr 08 16:22:16 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: ring 3 stalled for more than 10236msec

Then some:

Apr 08 16:22:17 mint.phcomp.co.uk kernel: radeon 0000:01:00.0: scheduling IB failed (-35).
Apr 08 16:22:17 mint.phcomp.co.uk kernel: [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)

lshw says that is a Pitcairn PRO [Radeon HD 7850 / R7 265 / R9 270 1024SP]

I prolly ought to just replace it, it is 14 years old.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hallo,


Am Donnerstag, den 09. April schrieb alain williams:

On Thu, Apr 09, 2026 at 09:32:22AM -0400, Stefan Monnier wrote:

Aha: I assumed "crashes Trixie" means the whole OS crashed.

If you can still access the machine via SSH, then presumably only the
video part is wedged. Still: if the whole user session is made unusable and the graphics stack is sufficiently confused that you can't "log out and log back in" (as seems to be the case based on your description), then
the problem is not just in the application but somewhere within the graphics stack.

Your description is correct. Graphics/console becomes unusable, it freezes showing whatever was being displayed. Curiously the mouse still moves. Sometimes (wild estimate of 1 in 5 times) the screen goes completely white.

In my case neither ssh-ing in nor switching to another console nor magic-sysrq-keys worked. In one case it even damages the root-fs
(btrfs). I had to hard power-off the system (4 sec power-button). So I
assume a kernel-crash, not only graphics-stack.

MfG
bmg

--
?Des is v”llig wurscht, was heut beschlos- | M G Berberich
sen wird: I bin sowieso dagegn!? | mail@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg) |

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)