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

[Thomas Schwinge <thomas@codesourcery.com>]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

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

[-- Attachment #2: Type: message/rfc822, Size: 7163 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 3354 bytes --]

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@gmail.com> 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@lst.de>
>>>>> 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 #2.1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]