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] [thread-next>] [day] [month] [year] [list]

Message-ID: <801e4196-5e22-e805-4d45-0245efdaa508@mageia.org>
Date:   Sat, 22 Feb 2020 18:16:28 +0200
From:   Thomas Backlund <tmb@...eia.org>
To:     Christian König <christian.koenig@....com>,
        Christoph Hellwig <hch@....de>,
        Woody Suwalski <terraluna977@...il.com>
CC:     DRI mailing list <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "Deucher, Alexander" <alexander.deucher@....com>,
        Pavel Machek <pavel@....cz>
Subject: Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40

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.

--
Thomas