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

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

[Helge Deller]

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?

Helge

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

[Alex Deucher]

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

> Helge
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Helge Deller]

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.
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?
I would be willing to test such code or even provide an initial patch if necessary.

Helge

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

[Alex Deucher]

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


> 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

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

[Helge Deller]

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