Created attachment 25941 [details]
Xorg log related to a second user

is this still an issue with KMS or a newer version of the driver?

Another user with the same problem:
SuSE 11.3 (Xorg 7.5_1.8.0) with ATI HD4650 AGP.
When selecting the radeon driver (no 3d acceleration!) the system (KDE) freezes within very few mouseclicks.
I'm back to fbdev now, since otherwise the box is unusable.
Hardware works fine under vista (even Furmark for hours), but I loathe to use that OS.
This is reproducible, so if there's anything I can do (logs, debug versions, etc), feel free to ask.
BR Holger

Might be a duplicate of:
https://bugzilla.kernel.org/show_bug.cgi?id=19002

(In reply to comment #4)
> Might be a duplicate of:
> https://bugzilla.kernel.org/show_bug.cgi?id=19002

Sure sounds like it. Is there anything I can do to verify that?
I.e. try with and without "nomodeset" or "radeon.agpmode=-1" ?

Should the driver be stable without AGP?

Please try the patch I attached there.

(In reply to comment #6)
> Please try the patch I attached there.

Sorry, second hunk of the patch does not work on my kernel (2.6.34.7-0.5-desktop) - it has a different version of r600.c.

In r600_ioctl_wait_idle, there is no reference to rdev->vram_scratch.ptr, but only the following code:

void r600_ioctl_wait_idle(struct radeon_device *rdev, struct radeon_bo *bo)
{
        /* r7xx hw bug.  write to HDP_DEBUG1 followed by fb read
         * rather than write to HDP_REG_COHERENCY_FLUSH_CNTL
         */
        if ((rdev->family >= CHIP_RV770) && (rdev->family <= CHIP_RV740)) {
                void __iomem *ptr = (void *)rdev->gart.table.vram.ptr;
                u32 tmp;

                WREG32(HDP_DEBUG1, 0);
                tmp = readl((void __iomem *)ptr);
        } else
                WREG32(R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
}

(In reply to comment #7)
> (In reply to comment #6)
> > Please try the patch I attached there.
> 
> Sorry, second hunk of the patch does not work on my kernel
> (2.6.34.7-0.5-desktop) - it has a different version of r600.c.
> 

Your distro does't seem to have ported over all the latest stable patches.

> In r600_ioctl_wait_idle, there is no reference to rdev->vram_scratch.ptr, but
> only the following code:

The patch that checks the scratch pointer may fix your issue.
> 
> void r600_ioctl_wait_idle(struct radeon_device *rdev, struct radeon_bo *bo)
> {
>         /* r7xx hw bug.  write to HDP_DEBUG1 followed by fb read
>          * rather than write to HDP_REG_COHERENCY_FLUSH_CNTL
>          */
>         if ((rdev->family >= CHIP_RV770) && (rdev->family <= CHIP_RV740)) {

For now, just add:
!(rdev->flags & RADEON_IS_AGP)
to the if clause.  E.g.,
	if ((rdev->family >= CHIP_RV770) && (rdev->family <= CHIP_RV740) &&
	    !(rdev->flags & RADEON_IS_AGP)) {



>                 void __iomem *ptr = (void *)rdev->gart.table.vram.ptr;
>                 u32 tmp;
> 
>                 WREG32(HDP_DEBUG1, 0);
>                 tmp = readl((void __iomem *)ptr);
>         } else
>                 WREG32(R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
> }

Tried the part of the patch that checked for AGP as you said.
Did not improve things much, system still freezes within the first few windows I open. May have improved somewhat, but is hard to tell.
Is there a way to get the latest patches applied to the kernel I'm using?
BR

(In reply to comment #9)
> Is there a way to get the latest patches applied to the kernel I'm using?

Easiest method is to try 2.6.37 kernels.  I'm not sure exactly which drm patches each distro kernel is carrying.

Now using a 2.6.37 kernel.
Vanilla radeon driver (which checks the scratch pointer) still freezes the machine.
Patched driver seems stable (not much uptime yet), but 2D performance seems even worse than fbdev.
Running with nomodeset for historical reasons.

(In reply to comment #11)
> Patched driver seems stable (not much uptime yet), but 2D performance seems
> even worse than fbdev.
> Running with nomodeset for historical reasons.

This patch only affects kms.  If you are forcing ums, you are seeing some other issue.

(In reply to comment #12)
> This patch only affects kms.  If you are forcing ums, you are seeing some other
> issue.
Marginal improvement as a side effect ;-)
I'll see if the driver is stable as it is.
Maybe file a new bug against the unpatched driver in ums mode?

(In reply to comment #13)
> Maybe file a new bug against the unpatched driver in ums mode?

Or we can make this bug about ums.  If you are using ums, you can try adding:
Option "BusType" "PCIE"
to the device section of your xorg.conf

Also i think we can say that we don't care about UMS (at least i don't)

Kudret Güler, Jaunty reached EOL as of October 23, 2010. For more on this, please see https://wiki.ubuntu.com/Releases .

If this is reproducible in a supported release, it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal:
ubuntu-bug xorg

Also, please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.