All of lore.kernel.org
 help / color / mirror / Atom feed
From: Woody Suwalski <terraluna977@gmail.com>
To: "Christian König" <christian.koenig@amd.com>,
	"Christoph Hellwig" <hch@lst.de>
Cc: DRI mailing list <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Deucher, Alexander" <alexander.deucher@amd.com>,
	Pavel Machek <pavel@ucw.cz>
Subject: Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40
Date: Thu, 9 Jan 2020 21:40:50 -0500	[thread overview]
Message-ID: <66a6b0ea-4ee8-1a0d-b259-568059d54e09@gmail.com> (raw)
In-Reply-To: <67f60d13-a245-5561-1372-7d68f35969f3@gmail.com>

Woody Suwalski wrote:
> Christian König wrote:
>> 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@lst.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?
>>
>> Thanks,
>> Christian.
>
> Happy New Year :-)
>
> 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..
>
> Thanks, Woody
>
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???

Woody


WARNING: multiple messages have this Message-ID (diff)
From: Woody Suwalski <terraluna977@gmail.com>
To: "Christian König" <christian.koenig@amd.com>,
	"Christoph Hellwig" <hch@lst.de>
Cc: "Deucher, Alexander" <alexander.deucher@amd.com>,
	Pavel Machek <pavel@ucw.cz>, LKML <linux-kernel@vger.kernel.org>,
	DRI mailing list <dri-devel@lists.freedesktop.org>
Subject: Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40
Date: Thu, 9 Jan 2020 21:40:50 -0500	[thread overview]
Message-ID: <66a6b0ea-4ee8-1a0d-b259-568059d54e09@gmail.com> (raw)
In-Reply-To: <67f60d13-a245-5561-1372-7d68f35969f3@gmail.com>

Woody Suwalski wrote:
> Christian König wrote:
>> 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@lst.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?
>>
>> Thanks,
>> Christian.
>
> Happy New Year :-)
>
> 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..
>
> Thanks, Woody
>
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???

Woody

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

  reply	other threads:[~2020-01-10  2:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-15  3:17 Regression in 5.4 kernel on 32-bit Radeon IBM T40 Woody Suwalski
2019-12-15  3:17 ` Woody Suwalski
2019-12-15 16:04 ` Meelis Roos
2020-01-09 14:14 ` Christoph Hellwig
2020-01-09 15:12   ` Christian König
2020-01-09 15:12     ` Christian König
2020-01-09 22:40     ` Woody Suwalski
2020-01-09 22:40       ` Woody Suwalski
2020-01-10  2:40       ` Woody Suwalski [this message]
2020-01-10  2:40         ` Woody Suwalski
2020-03-14 22:06         ` Thomas Schwinge
2020-03-14 22:06           ` Thomas Schwinge
2020-02-22 16:16     ` Thomas Backlund
2020-02-22 16:16       ` Thomas Backlund
2020-09-16 22:15       ` Alex Deucher
2020-09-16 22:15         ` Alex Deucher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=66a6b0ea-4ee8-1a0d-b259-568059d54e09@gmail.com \
    --to=terraluna977@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.