drm/radeon: "ring test failed" on PA-RISC Linux

Alex Deucher alexdeucher at gmail.com
Tue Sep 10 05:37:09 PDT 2013


On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov <gnidorah at p0n4ik.tk> wrote:
> Alex,
>
> 09.09.2013, в 21:43, Alex Deucher <alexdeucher at gmail.com> написал(а):
>
>> On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov <gnidorah at p0n4ik.tk> wrote:
>>> Folks,
>>>
>>> We (people at linux-parisc @ vger.kernel.org mail list) are trying to make
>>> native video options of the latest PA-RISC servers and workstations
>>> (these are ATIs, most of which are based on R100/R300/R420 chips) work
>>> correctly on this platform (big endian pa-risc).
>>>
>>> However, we hadn't much success. DRM fails every time with
>>> "ring test failed" for both AGP & PCI.
>>>
>>> Maybe you would give us some suggestions that we could check?
>>>
>>> Topic started here:
>>> http://www.spinics.net/lists/linux-parisc/msg04908.html
>>> And continued there:
>>> http://www.spinics.net/lists/linux-parisc/msg04995.html
>>> http://www.spinics.net/lists/linux-parisc/msg05006.html
>>>
>>> Problems we've already resolved without any signs of progress:
>>> - Checked the successful microcode load
>>> "parisc AGP GART code writes IOMMU entries in the wrong byte order and
>>> doesn't add the coherency information SBA code adds"
>>> "our PCI BAR setup doesn't really work very well together with the Radeon
>>> DRM address setup. DRM will generate addresses, which are even outside
>>> of the connected LBA"
>>>
>>> Things planned for a check:
>>> "The drivers/video/aty uses
>>> an endian config bit DRM doesn't use, but I haven't tested whether
>>> this makes a difference and how it is connected to the overall picture."
>>
>> I don't think that will any difference.  radeon kms works fine on
>> other big endian platforms such as powerpc.
>
> Good! I'll opt it out then.
>
>>
>>>
>>> "The Rage128 product revealed a weakness in some motherboard
>>> chipsets in that there is no mechanism to guarantee
>>> that data written by the CPU to memory is actually in a readable
>>> state before the Graphics Controller receives an
>>> update to its copy of the Write Pointer. In an effort to alleviate this
>>> problem, we"ve introduced a mechanism into the
>>> Graphics Controller that will delay the actual write to the Write Pointer
>>> for some programmable amount of time, in
>>> order to give the chipset time to flush its internal write buffers to
>>> memory.
>>> There are two register fields that control this mechanism:
>>> PRE_WRITE_TIMER and PRE_WRITE_LIMIT.
>>>
>>> In the radeon DRM codebase I didn't found anyone using/setting
>>> those registers. Maybe PA-RISC has some problem here?..."
>>
>> I doubt it.  If you are using AGP, I'd suggest disabling it and first
>> try to get things working using the on chip gart rather than AGP.
>> Load radeon with agpmode=-1.
>
> Already tried this without any luck. Anyway, a radeon driver fallbacks
> to the PCI mode in our case, so does it really matter?
>
> In addition, people with PCI cards experiencing the same issue...
>
>> The on chip gart always uses cache
>> snooped pci transactions and the driver assumes pci is cache coherent.
>> On AGP/PCI chips, the on-chip gart mechanism stores the gart table in
>> system ram.  On PCIE asics, the gart table is stored in vram.  The
>> gart page table maps system pages to a contiguous aperture in the
>> GPU's address space.  The ring lives in gart memory.  The GPU sees a
>> contiguous buffer and the gart mechanism handles the access to the
>> backing pages via the page table.  I'd suggest verifying that the
>> entries written to the gart page table are valid and then the
>> information written to the ring buffer is valid before updating the
>> ring's wptr in radeon_ring_unlock_commit().  Changing the wptr is what
>> causes the CP to start fetching data from the ring.
>
> Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to
> dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(
>

The dummy page isn't really going to help much.  That page is just
used as a safety placeholder for gart entries that aren't mapped on
the GPU.  TTM (drivers/gpu/drm/ttm) actually does the allocation of
the backing pages for the gart.  You may want to look there.

Alex

> --- radeon_device.c.orig        2013-09-10 08:55:05.000000000 +0000
> +++ radeon_device.c     2013-09-10 09:12:17.000000000 +0000
> @@ -673,15 +673,13 @@ int radeon_dummy_page_init(struct radeon
>  {
>         if (rdev->dummy_page.page)
>                 return 0;
> -       rdev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO);
> -       if (rdev->dummy_page.page == NULL)
> +       rdev->dummy_page.page = dma_alloc_coherent(&rdev->pdev->dev, PAGE_SIZE,
> +               &rdev->dummy_page.addr, GFP_DMA32|GFP_KERNEL);
> +       if (!rdev->dummy_page.page)
>                 return -ENOMEM;
> -       rdev->dummy_page.addr = pci_map_page(rdev->pdev, rdev->dummy_page.page,
> -                                       0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
>         if (pci_dma_mapping_error(rdev->pdev, rdev->dummy_page.addr)) {
>                 dev_err(&rdev->pdev->dev, "Failed to DMA MAP the dummy page\n");
> -               __free_page(rdev->dummy_page.page);
> -               rdev->dummy_page.page = NULL;
> +               radeon_dummy_page_fini(rdev);
>                 return -ENOMEM;
>         }
>         return 0;
> @@ -698,9 +696,8 @@ void radeon_dummy_page_fini(struct radeo
>  {
>         if (rdev->dummy_page.page == NULL)
>                 return;
> -       pci_unmap_page(rdev->pdev, rdev->dummy_page.addr,
> -                       PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
> -       __free_page(rdev->dummy_page.page);
> +       dma_free_coherent(&rdev->pdev->dev, PAGE_SIZE,
> +               rdev->dummy_page.page, rdev->dummy_page.addr);
>         rdev->dummy_page.page = NULL;
>  }
>
>>
>> Alex
>>
>>>
>>> Thanks.
>>>
>>> -------- Пересылаемое сообщение  --------
>>> 04.08.2013, 15:06, "Alex Ivanov" <gnidorah at p0n4ik.tk>:
>>>
>>> 11.07.2013, 23:48, "Helge Deller" <deller at gmx.de>:
>>>
>>>> adding linux parisc mailing list...:
>>>>
>>>> On 07/11/2013 09:46 PM, Helge Deller wrote:
>>>>>  On 07/10/2013 11:29 PM, Alex Ivanov wrote:
>>>>>>  11.07.2013, 01:14, "Matt Turner" <mattst88 at gmail.com>:
>>>>>>>  On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah at p0n4ik.tk> wrote:
>>>>>>>>   Thank you so much! Your guess looks to be right. After applying of your
>>>>>>>>   patch there was no more KP and X just worked.
>>>>>>>  Nice! Does DRI work?
>>>>>>  Not on my side. Plus i can't visually jump over 8bit depth, although Xorg
>>>>>>  states 24bit in it's log.
>>>>>>  As for DRI, i'm experiencing
>>>>>>  "ring test failed (scratch(0x15E4)=0xCAFEDEAD)" with a firegl x3.
>>>>>  FWIW, I'm seeing the same failure on my FireGL X1:
>>>>>  80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Radeon R300 NG [FireGL X1] (rev 80)
>>>>>
>>>>>  [drm] radeon: irq initialized.
>>>>>  [drm] Loading R300 Microcode
>>>>>  [drm] radeon: ring at 0x0000000060001000
>>>>>  [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD)
>>>>>  [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
>>>>>  radeon 0000:80:00.0: failed initializing CP (-22).
>>>>>  radeon 0000:80:00.0: Disabling GPU acceleration
>>>>>  [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
>>>>>  [drm] radeon: cp finalized
>>>>>  [drm] radeon: cp finalized
>>>
>>> I still have no clue why this happens. Broken SBA IOMMU / DRM code? Missing syncing primitives?
>>> Should we forward this to dri-devel mail list?
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> -------- Завершение пересылаемого сообщения --------
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>


More information about the dri-devel mailing list