On Wed, Nov 30, 2022 at 10:42 AM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > 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. Mikhail, Can you see that dma_addressing_limited() and dma_get_required_mask() return in this case? Alex > > Thanks, > Robin.
