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

Thomas Schwinge <thomas@xxxxxxxxxxxxxxxx> · Sat, 14 Mar 2020 23:06:51 +0100

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
--- Begin Message ---

Subject: Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40
From: Thomas Schwinge <thomas@xxxxxxxxxxxxxxxx>
Date: Sat, 14 Mar 2020 23:06:51 +0100
Cc: <dri-devel@xxxxxxxxxxxxxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>,	Alexander Deucher <alexander.deucher@xxxxxxx>, Pavel Machek <pavel@xxxxxx>,	Thomas Backlund <tmb@xxxxxxxxxx>, Meelis Roos <mroos@xxxxxxxx>
In-reply-to: <66a6b0ea-4ee8-1a0d-b259-568059d54e09@gmail.com>
References: <400f6ce9-e360-0860-ca2a-fb8bccdcdc9b@gmail.com> <20200109141436.GA22111@lst.de> <9ad75215-3ff1-ee76-9985-12fd78d6aa5f@amd.com> <67f60d13-a245-5561-1372-7d68f35969f3@gmail.com> <66a6b0ea-4ee8-1a0d-b259-568059d54e09@gmail.com>
User-agent: Notmuch/0.29.1+93~g67ed7df (https://notmuchmail.org) Emacs/26.1 (i686-pc-linux-gnu)

Hi!

Has any progress been made regarding the issue reported here?

Having updated the software (here: Linux kernel), I'm running into the
same issue on my venerable ;-) Thinkpad T42 with:

    01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV200/M7 [Mobility Radeon 7500]

I lack knowledge of the specific graphics hardware/memory interface as
well as Linux kernel graphics/memory stack at that level, but I'll be
happy to try any suggestions, or test patches etc.

On 2020-01-09T21:40:50-0500, Woody Suwalski <terraluna977@xxxxxxxxx> wrote:
> Woody Suwalski wrote:
>> Christian König wrote:
>>> Am 09.01.20 um 15:14 schrieb Christoph Hellwig:
>>>> 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@xxxxxx>
>>>>> Date:   Thu Aug 15 09:27:00 2019 +0200
>>>>>
>>>>> 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'm confirming that hack "resolves" the issue.

>>>> 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?
>>
>> Yes, the box has 1G of RAM, and unfortunately nope, 
>> TRANSPARENT_HUGEPAGE is not on. I am attaching the .config, maybe you 
>> can find some insanity there... Also - for reference - a minimalistic 
>> patch fixing symptoms (but not addressing the root cause  :-( )
>>
>> I can try to rebuild the kernel with HIGHMEM off, although I am not 
>> optimistic it will change anything. But at least it should simplify 
>> the 1G split...
>>
>> So if you have any other ideas - pls let me know..
>>
> Interesting. Rebuilding the kernel with HIMEM disabled actually solves 
> the display problem. The debug lines show exactly same values for 
> dma_get_required_mask() and dma_get_mask(), yet now it works OK... So 
> what has solved it???

That I have not yet tried.

Grüße
 Thomas
Attachment:
signature.asc

Description: PGP signature

--- End Message ---
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel