Bug#993670: linux-image-5.10.0-8-686: Screen corruption using radeon kernel driver

[Krylov Michael]

Package: linux-image-5.10.0-8-686
Version: 5.10.46-4
Severity: important
Tags: patch

Dear maintainer,

After updating from buster to bullseye I've noticed that the image
displayed on my older computer, 32-bit Pentium 4 using ATI Radeon X1950
AGP video card is severely corrupted in the graphical (Xorg and Wayland)
mode: all kinds of black and white stripes across the screen, some
letters missing, etc.

I've checked several options (Xorg drivers, Wayland instead of Xorg and
so on), but the problem persisted. I've managed to find that the problem
was in the kernel, as everything worked well with buster's kernel with
everything else being from bullseye.

I have managed to find the culprit of that corruption, that is the
commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713 on the linux kernel.
Reverting this commit and building the kernel with that commit reverted
fixes the problem, and I'm writing this bug report with the kernel I've
built with that commit reverted.

Apparently this problem is somewhat known, as I can tell after googling
for the commit id, see https://lkml.org/lkml/2020/1/9/518 this link for
example.

Mageia distro, for example, reverted this commit in the kernel they are
building: http://sophie.zarb.org/distrib/Mageia/7/aarch64/by-pkgid/b9193a4f85192bc57f4d770fb9bb399c/files/32
and I would like to suggest adding the reverting patch (attached) to the
debian kernel as well (at least for 32-bit x86 architecture as 64-bit is
unaffected).

This took me several days to debug, so I hope it will be included in one
of the point releases :)

Thanks in advance!


-- System Information:
Debian Release: 11.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-8-686 (SMP w/1 CPU thread)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages linux-image-5.10.0-8-686 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.140
ii kmod 28-1
ii linux-base 4.6

Versions of packages linux-image-5.10.0-8-686 recommends:
pn apparmor <none>
pn firmware-linux-free <none>

Versions of packages linux-image-5.10.0-8-686 suggests:
pn debian-kernel-handbook <none>
ii extlinux 3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
pn linux-doc-5.10 <none>

[Mikhail Krylov]

Forgot to add that disabling HIMEM also gets rid of that problem. But it
also leaves the system with less that 1G of RAM, which is, of course,
undesirable

[Diederik de Haas]

Can you still reproduce this issue with a more recent kernel?

There was another suggestion: "setting radeon.agpmode=-1 on the kernel
command line (in grub)"
If a recent kernel hasn't fixed it, does the other suggestion fix the issue?

[Mikhail Krylov]

On Mon, Apr 18, 2022 at 05:21:28PM +0200, Diederik de Haas wrote:
> Can you still reproduce this issue with a more recent kernel?

Yup, tried with linux-image-5.17.0-1-686_5.17.3-1_i386.deb a few moments
ago, unfortunately, the problem still persists.

> There was another suggestion: "setting radeon.agpmode=-1 on the kernel
> command line (in grub)"
> If a recent kernel hasn't fixed it, does the other suggestion fix the issue?

For me, the only thing it does is that it disables acceleration.
Basically everything that uses it, like openarena stops working, even
some 2d apps because they use glamor I guess.

[Debian Bug Tracking System]

Processing control commands:

> tag -1 upstream
Bug #993670 [src:linux] linux-image-5.10.0-8-686: Screen corruption using radeon kernel driver
Added tag(s) upstream.
> found -1 linux/5.17.3-1
Bug #993670 [src:linux] linux-image-5.10.0-8-686: Screen corruption using radeon kernel driver
Marked as found in versions linux/5.17.3-1.

--
993670: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993670
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

[Diederik de Haas]

Control: tag -1 upstream
Control: found -1 linux/5.17.3-1

Yeah, that's indeed not much of a solution.

This is an upstream kernel issue which should be fixed there.
AFAICT you have all the information you'd need, including the offending commit
and the skills to test an upstream suggested (proper*) fix.
(I/We can try to help if you still run into issues on that)

Can you report this upstream? The appropriate place is
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
When you have, please also mention the URL of that, so that we can track any
progress here too.

TIA,
Diederik

*) I consider the Mageia revert a workaround (which also seems wrt aarch64/
arm64, not x86?), not a fix. If upstream considers that a proper and does
revert
that commit themselves too, then it's more likely Debian will incorporate it
(until it trickles down from updated upstream version(s)).

[Mikhail Krylov]

On Sat, Apr 23, 2022 at 04:53:24PM +0200, Diederik de Haas wrote:
> Can you report this upstream? The appropriate place is
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> When you have, please also mention the URL of that, so that we can track any
> progress here too.
>

Done. I'll post the link tomorrow, because it seems like their archives
get updated once in a day or so, and the link is not available at the
moment.

> *) I consider the Mageia revert a workaround (which also seems wrt aarch64/
> arm64, not x86?), not a fix. If upstream considers that a proper and does
> revert
> that commit themselves too, then it's more likely Debian will incorporate it
> (until it trickles down from updated upstream version(s)).

The correct link to the 32-bit x86 is http://sophie.zarb.org/distrib/Mageia/7/i586/by-pkgid/b9193a4f85192bc57f4d770fb9bb399c/files/32
by the way.

[Mikhail Krylov]

Here's the link in amd-gfx mail list:

https://lists.freedesktop.org/archives/amd-gfx/2022-April/078134.html