From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D13B3C4332F for ; Wed, 30 Nov 2022 14:17:35 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0EF3E10E0F8; Wed, 30 Nov 2022 14:17:35 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 59A6610E096; Wed, 30 Nov 2022 12:54:51 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6B102D6E; Wed, 30 Nov 2022 04:54:57 -0800 (PST) Received: from [10.57.71.118] (unknown [10.57.71.118]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 17D8E3F73D; Wed, 30 Nov 2022 04:54:49 -0800 (PST) Message-ID: Date: Wed, 30 Nov 2022 12:54:49 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: Screen corruption using radeon kernel driver Content-Language: en-GB To: Mikhail Krylov , Alex Deucher References: <20220423193145.3301ed06@desktop> From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 30 Nov 2022 14:17:31 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Maling list - DRI developers , amd-gfx list Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On 2022-11-29 17:11, Mikhail Krylov wrote: > On Tue, Nov 29, 2022 at 11:05:28AM -0500, Alex Deucher wrote: >> On Tue, Nov 29, 2022 at 10:59 AM Mikhail Krylov wrote: >>> >>> On Tue, Nov 29, 2022 at 09:44:19AM -0500, Alex Deucher wrote: >>>> On Mon, Nov 28, 2022 at 3:48 PM Mikhail Krylov wrote: >>>>> >>>>> On Mon, Nov 28, 2022 at 09:50:50AM -0500, Alex Deucher wrote: >>>>> >>>>>>>> [excessive quoting removed] >>>>> >>>>>>> So, is there any progress on this issue? I do understand it's not a high >>>>>>> priority one, and today I've checked it on 6.0 kernel, and >>>>>>> unfortunately, it still persists... >>>>>>> >>>>>>> I'm considering writing a patch that will allow user to override >>>>>>> need_dma32/dma_bits setting with a module parameter. I'll have some time >>>>>>> after the New Year for that. >>>>>>> >>>>>>> Is it at all possible that such a patch will be merged into kernel? >>>>>>> >>>>>> On Mon, Nov 28, 2022 at 9:31 AM Mikhail Krylov wrote: >>>>>> Unless someone familiar with HIMEM can figure out what is going wrong >>>>>> we should just revert the patch. >>>>>> >>>>>> Alex >>>>> >>>>> >>>>> Okay, I was suggesting that mostly because >>>>> >>>>> a) it works for me with dma_bits = 40 (I understand that's what it is >>>>> without the original patch applied); >>>>> >>>>> b) there's a hint of uncertainity on this line >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/radeon_device.c#n1359 >>>>> saying that for AGP dma_bits = 32 is the safest option, so apparently there are >>>>> setups, unlike mine, where dma_bits = 32 is better than 40. >>>>> >>>>> But I'm in no position to argue, just wanted to make myself clear. >>>>> I'm okay with rebuilding the kernel for my machine until the original >>>>> patch is reverted or any other fix is applied. >>>> >>>> What GPU do you have and is it AGP? If it is AGP, does setting >>>> radeon.agpmode=-1 also fix it? >>>> >>>> Alex >>> >>> That is ATI Radeon X1950, and, unfortunately, radeon.agpmode=-1 doesn't >>> help, it just makes 3D acceleration in games such as OpenArena stop >>> working. >> >> Just to confirm, is the board AGP or PCIe? >> >> Alex > > It is AGP. That's an old machine. Can you check whether dma_addressing_limited() is actually returning the expected result at the point of radeon_ttm_init()? Disabling highmem is presumably just hiding whatever problem exists, by throwing away all >32-bit RAM such that use_dma32 doesn't matter. Robin.