linux-kernel - Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CADnq5_PgQq4U86sSvpXSP6d9LUQHhohi4u2d6TjAPRA--1vM5A@mail.gmail.com>
Date:   Wed, 16 Sep 2020 18:15:21 -0400
From:   Alex Deucher <alexdeucher@...il.com>
To:     Thomas Backlund <tmb@...eia.org>
Cc:     Christian König <christian.koenig@....com>,
        Christoph Hellwig <hch@....de>,
        Woody Suwalski <terraluna977@...il.com>,
        "Deucher, Alexander" <alexander.deucher@....com>,
        Pavel Machek <pavel@....cz>,
        LKML <linux-kernel@...r.kernel.org>,
        DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40

On Mon, Feb 24, 2020 at 4:20 AM Thomas Backlund <tmb@...eia.org> wrote:
>
> Den 09-01-2020 kl. 17:12, skrev Christian König:
> > 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 holidays.
> >>
> >> 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@....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()==0 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 the
> > 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 are
> >> 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 and
> >> 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=-1 on the kernel
command line in grub fix the issue?

Alex