Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <400f6ce9-e360-0860-ca2a-fb8bccdcdc9b@gmail.com>
 <20200109141436.GA22111@lst.de> <9ad75215-3ff1-ee76-9985-12fd78d6aa5f@amd.com>
 <801e4196-5e22-e805-4d45-0245efdaa508@mageia.org>
In-Reply-To: <801e4196-5e22-e805-4d45-0245efdaa508@mageia.org>
From:   Alex Deucher <alexdeucher@gmail.com>
Date:   Wed, 16 Sep 2020 18:15:21 -0400
Message-ID: <CADnq5_PgQq4U86sSvpXSP6d9LUQHhohi4u2d6TjAPRA--1vM5A@mail.gmail.com>
Subject: Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40
To:     Thomas Backlund <tmb@mageia.org>
Cc:     =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>,
        Christoph Hellwig <hch@lst.de>,
        Woody Suwalski <terraluna977@gmail.com>,
        "Deucher, Alexander" <alexander.deucher@amd.com>,
        Pavel Machek <pavel@ucw.cz>,
        LKML <linux-kernel@vger.kernel.org>,
        DRI mailing list <dri-devel@lists.freedesktop.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Feb 24, 2020 at 4:20 AM Thomas Backlund <tmb@mageia.org> wrote:
>
> Den 09-01-2020 kl. 17:12, skrev Christian K=C3=B6nig:
> > Hi Christoph,
> >
> > Am 09.01.20 um 15:14 schrieb Christoph Hellwig:
> >> Hi Woody,
> >>
> >> sorry for the late reply, I've been off to a vacation over the holiday=
s.
> >>
> >> On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote:
> >>> Regression in 5.4 kernel on 32-bit Radeon IBM T40
> >>> triggered by
> >>> commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713
> >>> Author: Christoph Hellwig <hch@lst.de>
> >>> Date:   Thu Aug 15 09:27:00 2019 +0200
> >>>
> >>> Howdy,
> >>> The above patch has triggered a display problem on IBM Thinkpad T40,
> >>> where
> >>> the screen is covered with a lots of random short black horizontal
> >>> lines,
> >>> or distorted letters in X terms.
> >>>
> >>> The culprit seems to be that the dma_get_required_mask() is returning=
 a
> >>> value 0x3fffffff
> >>> which is smaller than dma_get_mask()0xffffffff.That results in
> >>> dma_addressing_limited()=3D=3D0 in ttm_bo_device(), and using 40-bits=
 dma
> >>> instead of 32-bits.
> >> Which is the intended behavior assuming your system has 1GB of memory.
> >> Does it?
> >
> > Assuming the system doesn't have the 1GB split up somehow crazy over th=
e
> > address space that should indeed work as intended.
> >
> >>
> >>> If I hardcode "1" as the last parameter to ttm_bo_device_init() in
> >>> place of
> >>> a call to dma_addressing_limited(),the problem goes away.
> >> I'll need some help from the drm / radeon / TTM maintainers if there a=
re
> >> any other side effects from not passing the need_dma32 paramters.
> >> Obviously if the device doesn't have more than 32-bits worth of dram a=
nd
> >> no DMA offset we can't feed unaddressable memory to the device.
> >> Unfortunately I have a very hard time following the implementation of
> >> the TTM pool if it does anything else in this case.
> >
> > The only other thing which comes to mind is using huge pages. Can you
> > try a kernel with CONFIG_TRANSPARENT_HUGEPAGE disabled?
> >
>
>
> Any progress on this ?
>
> We have a bugreport in Mageia with the hw:
> Dell Inspiron 5100, 32-bit P4 processor, 2GB of RAM, Radeon Mobility
> 7500 (RV200) graphics
>
> that gets display issues too and reverting the offending commit restores
> normal behaviour.
>
> and the same issue is still there with 5.5 series kernels.

Does disabling HIMEM or setting radeon.agpmode=3D-1 on the kernel
command line in grub fix the issue?

Alex