Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #84058 > unrolled thread

Bug#993670: closed by carnil@debian.org (Closing this bug (BTS maintenance for src:linux bugs))

Started byMikhail Krylov <sqarert@gmail.com>
First post2024-09-21 18:10 +0200
Last post2024-09-21 20:30 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Bug#993670: closed by carnil@debian.org (Closing this bug (BTS maintenance for src:linux bugs)) Mikhail Krylov <sqarert@gmail.com> - 2024-09-21 18:10 +0200
    Bug#993670: closed by carnil@debian.org (Closing this bug (BTS maintenance for src:linux bugs)) Salvatore Bonaccorso <carnil@debian.org> - 2024-09-21 20:30 +0200

#84058 — Bug#993670: closed by carnil@debian.org (Closing this bug (BTS maintenance for src:linux bugs))

FromMikhail Krylov <sqarert@gmail.com>
Date2024-09-21 18:10 +0200
SubjectBug#993670: closed by carnil@debian.org (Closing this bug (BTS maintenance for src:linux bugs))
Message-ID<JpaQh-dShn-1@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Just tested the thing again.

It is not fully fixed, and by that I mean, I still see an occastional
corruption here or there, but it is much better than it was. 95% of the
time I can't see a single corrupted pixel. I guess given that and the
fact that the patch was not accepted (the code was rewritten a lot
instead), it is reasonable to keep this bug closed.

On Sun, Aug 25, 2024 at 01:00:08PM +0000, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:linux package:
> 
> #993670: linux-image-5.10.0-8-686: Screen corruption using radeon kernel driver
> 
> It has been closed by carnil@debian.org.
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact carnil@debian.org by
> replying to this email.
> 
> 
> -- 
> 993670: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993670
> Debian Bug Tracking System
> Contact owner@bugs.debian.org with problems

> Date: Sun, 25 Aug 2024 14:58:35 +0200 (CEST)
> From: carnil@debian.org
> To: 993670-done@bugs.debian.org
> Cc: 993670-submitter@bugs.debian.org
> Subject: Closing this bug (BTS maintenance for src:linux bugs)
> 
> Hi
> 
> This bug was filed for a very old kernel or the bug is old itself
> without resolution.
> 
> If you can reproduce it with
> 
> - the current version in unstable/testing
> - the latest kernel from backports
> 
> please reopen the bug, see https://www.debian.org/Bugs/server-control
> for details.
> 
> Regards,
> Salvatore

> Date: Sat, 04 Sep 2021 18:30:34 +0300
> From: Krylov Michael <sqarert@gmail.com>
> To: Debian Bug Tracking System <submit@bugs.debian.org>
> Subject: linux-image-5.10.0-8-686: Screen corruption using radeon kernel
>  driver
> X-Mailer: reportbug 7.10.3
> 
> 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>

> From bff1b53f4ff2afcaeaadacc6e693e3939e025dd4 Mon Sep 17 00:00:00 2001
> From: Mikhail Krylov <sqarert@gmail.com>
> Date: Sat, 4 Sep 2021 15:34:02 +0300
> Subject: [PATCH] Revert "drm/radeon: handle PCIe root ports with addressing
>  limitations"
> 
> This reverts commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713.
> ---
>  drivers/gpu/drm/radeon/radeon.h        |  1 +
>  drivers/gpu/drm/radeon/radeon_device.c | 13 ++++++++-----
>  drivers/gpu/drm/radeon/radeon_ttm.c    |  2 +-
>  3 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index a6d8de01194..15d6de5dfbd 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2391,6 +2391,7 @@ struct radeon_device {
>  	struct radeon_wb		wb;
>  	struct radeon_dummy_page	dummy_page;
>  	bool				shutdown;
> +	bool				need_dma32;
>  	bool				need_swiotlb;
>  	bool				accel_working;
>  	bool				fastfb_working; /* IGP feature*/
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
> index 266e3cbbd09..f74c74ad8b5 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1363,25 +1363,28 @@ int radeon_device_init(struct radeon_device *rdev,
>  	else
>  		rdev->mc.mc_mask = 0xffffffffULL; /* 32 bit MC */
>  
> -	/* set DMA mask.
> +	/* set DMA mask + need_dma32 flags.
>  	 * PCIE - can handle 40-bits.
>  	 * IGP - can handle 40-bits
>  	 * AGP - generally dma32 is safest
>  	 * PCI - dma32 for legacy pci gart, 40 bits on newer asics
>  	 */
> -	dma_bits = 40;
> +	rdev->need_dma32 = false;
>  	if (rdev->flags & RADEON_IS_AGP)
> -		dma_bits = 32;
> +		rdev->need_dma32 = true;
>  	if ((rdev->flags & RADEON_IS_PCI) &&
>  	    (rdev->family <= CHIP_RS740))
> -		dma_bits = 32;
> +		rdev->need_dma32 = true;
>  #ifdef CONFIG_PPC64
>  	if (rdev->family == CHIP_CEDAR)
> -		dma_bits = 32;
> +		rdev->need_dma32 = true;
>  #endif
>  
> +	dma_bits = rdev->need_dma32 ? 32 : 40;
>  	r = dma_set_mask_and_coherent(&rdev->pdev->dev, DMA_BIT_MASK(dma_bits));
>  	if (r) {
> +		rdev->need_dma32 = true;
> +		dma_bits = 32;
>  		pr_warn("radeon: No suitable DMA available\n");
>  		return r;
>  	}
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 36150b7f31a..7fd117cf138 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -818,7 +818,7 @@ int radeon_ttm_init(struct radeon_device *rdev)
>  			       &radeon_bo_driver,
>  			       rdev->ddev->anon_inode->i_mapping,
>  			       rdev->ddev->vma_offset_manager,
> -			       dma_addressing_limited(&rdev->pdev->dev));
> +			       rdev->need_dma32);
>  	if (r) {
>  		DRM_ERROR("failed initializing buffer object driver(%d).\n", r);
>  		return r;
> -- 
> 2.30.2
> 


[toc] | [next] | [standalone]


#84063

FromSalvatore Bonaccorso <carnil@debian.org>
Date2024-09-21 20:30 +0200
Message-ID<Jpd1L-dTyV-3@gated-at.bofh.it>
In reply to#84058
Hi Mikhail,

Thanks a lot for reporting back, much appreciated.

On Sat, Sep 21, 2024 at 07:04:39PM +0300, Mikhail Krylov wrote:
> Just tested the thing again.
> 
> It is not fully fixed, and by that I mean, I still see an occastional
> corruption here or there, but it is much better than it was. 95% of the
> time I can't see a single corrupted pixel. I guess given that and the
> fact that the patch was not accepted (the code was rewritten a lot
> instead), it is reasonable to keep this bug closed.

Maybe, if you still arepartially able to trigger an issue, migh you
report it direcly to upstream? The best approach here is, get the
upstream issue addressed in a stable series update, which we pick
automatically at regular times as we follow the stable series.

So let's keep this bug closed, but if you manage to get it reproduced
and pinpointed and reported upstream feel free to open a new bug for
this, including the upstream information to track.

Regards,
Salvatore

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web