On 2022-11-30 14:28, Alex Deucher wrote:
On Wed, Nov 30, 2022 at 7:54 AM Robin Murphy <robin.murphy@xxxxxxx> wrote:
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 <sqarert@xxxxxxxxx> 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 <sqarert@xxxxxxxxx> 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 <sqarert@xxxxxxxxx> 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.
The device in question only supports a 32 bit DMA mask so
dma_addressing_limited() should return true. Bounce buffers are not
really usable on GPUs because they map so much memory. If
dma_addressing_limited() returns false, that would explain it.
Right, it appears to be the only part of the offending commit that
*could* reasonably make any difference, so I'm primarily wondering if
dma_get_required_mask() somehow gets confused.
Thanks,
Robin.
