--- Begin Message --- 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 ---