On 01/04/2012 12:37 AM, Alex Deucher wrote: > On Tue, Jan 3, 2012 at 6:12 PM, Helge Deller<deller at 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 at 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
