Re: radeon: writeback-issues since kernel 2.6.34 on ATI FireMV 2200 PCI

[Helge Deller <deller@gmx.de>]

On 01/04/2012 12:37 AM, Alex Deucher wrote:
> On Tue, Jan 3, 2012 at 6:12 PM, Helge Deller<deller@gmx.de>  wrote:
>> On 01/03/2012 03:27 PM, Alex Deucher wrote:
>>>
>>> On Mon, Jan 2, 2012 at 5:07 PM, Helge Deller<deller@gmx.de>    wrote:
>>>>
>>>> I'm facing the problem with the radeon drm driver, that I now manually
>>>> need
>>>> to set the kernel module parameter radeon.no_wb to 1 at bootup, else X
>>>> just
>>>> hangs in average up to 8 seconds per minute without any real activity (X
>>>> or
>>>> the video driver just seems to wait for something..).
>>>>
>>>> Fedora 13 (kernel 2.6.34.9-69.fc13.x86_64) worked without problems, while
>>>> all following Fedora distributions including F16 have this problem.
>>>> I'm using a dual-DVI ATI RV280 [FireMV 2200 PCI].
>>>>
>>>> I did compared the sources of those kernels and the only obvious change
>>>> to
>>>> me is in radeon_ring.c: radeon_ring_free_size() where those lines were
>>>> added
>>>> at the top of the function:
>>>>         if (rdev->wb.enabled)
>>>>                 rdev->cp.rptr =
>>>> le32_to_cpu(rdev->wb.wb[RADEON_WB_CP_RPTR_OFFSET/4]);
>>>>
>>>> Given the problems I'm seeing (X-Windows hangs for a few seconds every
>>>> time)
>>>> this fits with the idea, that the driver is waiting for a free slot but
>>>> can't find any (maybe due to wrong values returned by not-working WB?).
>>>>
>>>> I'm wondering, if "rdev->wb.enabled" is correct in this place and if
>>>> "dev_priv->writeback_works" shouldn't be used instead here?
>>>>
>>>
>>> It's possible that writeback doesn't work on your system in which case
>>> no_wb=1 is apprioriate.  dev_priv->writeback_works is part of the old
>>> UMS drm and is not used by KMS.  The KMS code does not test if
>>> writeback works prior to enabling it like UMS did.  The slow down you
>>> are seeing is caused by the driver waiting for the fence to be written
>>> back to memory.  If writeback does not work, the fence is never
>>> written by the hw and the driver has to wait for the fence to time
>>> out.
>>
>>
>> Alex, thanks for the explanations.
>> In my opinion this is a regression then. The old code worked without
>> problems, while with the new driver (or only because of the added code
>> lines) the driver doesn't work out of the box.
>
> I just posted a patch to disable writeback by default on KMS on pre-R300 chips:
> http://lists.freedesktop.org/archives/dri-devel/2012-January/017829.html

Thanks a lot for this patch and especially for scheduling it for inclusion into the stable kernel series!
It should fix my problems.

Helge

>
>
>> Wouldn't it be an idea to port over the old UMS writeback-check-test to the
>> new KMS code base to avoid the issues I'm seeing?
>
> Maybe, assuming the writeback test reliably fails which I'm not sure
> is the case.  UMS didn't utilize the hardware to the same extent that
> KMS does so it was less likely to be an issue there.
>
> Alex
>
>> I would be willing to test such code or even provide an initial patch if
>> necessary.
>>
>> Helge