Bug 27284

Created attachment 34395 [details]
dmesg.log

Created attachment 34396 [details]
Xorg log

Created attachment 34397 [details]
xorg.conf

Created attachment 34414 [details] [review]
allow bo placement in vram or gart

Does this patch help?

I tried the patch and it did not solve the regression on my machine. I found that I can only duplicate this issue when running with a window manager that does not have composite enabled. (ie. stock metacity). Running with compiz makes the slowness go away.

Yes this patch seems to have fixed the problem. Thanks a lot!

*** Bug 27296 has been marked as a duplicate of this bug. ***

Created attachment 34424 [details]
switching tabs in firefox oprofile

Sorry, I was celebrating too early. Tab switching in Opera works fine now but it's slow when using firefox. I've created another oprofile for firefox.

Not yet resolved.

Created attachment 34425 [details]
switching tabs in firefox oprofile

Sorry, I was celebrating too early. Tab switching in Opera works fine now but it's slow when using firefox. I've created another oprofile for firefox.

(In reply to comment #7)
> *** Bug 27296 has been marked as a duplicate of this bug. ***
> 

Have done some more testing and it's the first commit - 

dda3f5a99e7a2dc5d57860f4d07df3498e1e21df
r6xx EXA/Xv: track src/dst domains

that introduces the problems for me.

(In reply to comment #11)

Testing head + the patch does seem to solve the seamonkey perf, but VT1 is still flooded with 

WRITE DOMAIN RELOC FAILURE 0xd 6 2
WRITE DOMAIN RELOC FAILURE 0xd 2 6

*** Bug 27283 has been marked as a duplicate of this bug. ***

Created attachment 34434 [details] [review]
flush command stream if bo domain changes

Can you try this patch both with and without the previous one?

(In reply to comment #12)
> (In reply to comment #11)
> 
> Testing head + the patch does seem to solve the seamonkey perf

After about 4 hrs of running this things fell apart -

7fps in glxgears

xv didn't draw.

screen taking 1/2 sec to update its self.

> --- Comment #15 from Andy Furniss <lists@andyfurniss.entadsl.com>  2010-03-25 10:50:32 PST ---
> (In reply to comment #12)
>> (In reply to comment #11)
>>
>> Testing head + the patch does seem to solve the seamonkey perf
>
> After about 4 hrs of running this things fell apart -
>
> 7fps in glxgears
>
> xv didn't draw.
>
> screen taking 1/2 sec to update its self.
>
Is there any errors in xorg.log or dmesg when the slow down happens?

(In reply to comment #14)
> Created an attachment (id=34434) [details]
> flush command stream if bo domain changes
> 
> Can you try this patch both with and without the previous one?
> 

Both patches seem to (while it lasts) fix the perf but whether alone or together I still get the RELOC errors to stderr.

Both in any combination seem to fix the dmesg error I get with unpatched head -

[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !

(In reply to comment #16)

> Is there any errors in xorg.log or dmesg when the slow down happens?

Nothing in dmesg - I briefly saw a different line scroll off when I quit X but my fbcon scroll back seems to be limited to a couple of lines so I can't say what it said. Now I've tried the other patch I'll try and recreate it and redirect to a file this time.

Created attachment 34449 [details]
oprofile only second patch applied

Created attachment 34450 [details]
oprofile, both patches applied

My system seems to be running fine with the second patch.

(In reply to comment #18)
> (In reply to comment #16)
> 
> > Is there any errors in xorg.log or dmesg when the slow down happens?
> 
> Nothing in dmesg - I briefly saw a different line scroll off when I quit X but
> my fbcon scroll back seems to be limited to a couple of lines so I can't say
> what it said. Now I've tried the other patch I'll try and recreate it and
> redirect to a file this time.
> 

After waiting ages and accumulating 22k reloc errors I decided to retrace my steps and so now I've managed to find a way to trigger this - just use flash - something which doesn't usually happen as I run flashblock. Unblocking a flash totally trashes perf even after seamonkey is closed

The error when perf is trashed is -

space check failed in flush

oprofile (not that I totally trust it) shows most time in -

1116680  80.3342  libpixman-1.so.0.17.3    libpixman-1.so.0.17.3    pixman_blt_mmx

It happens with unpatched head and the first patch.

Running with the second patch alone or + the first patch fixes it.

(In reply to comment #21)

> I've managed to find a way to trigger this - just use flash -
> something which doesn't usually happen as I run flashblock. Unblocking a flash
> totally trashes perf even after seamonkey is closed

More testing shows that not just any flash will trigger it, but this one does -

http://www.speedtest.bbmax.co.uk/

(In reply to comment #21)
> (In reply to comment #18)
> > (In reply to comment #16)
> > 
> > > Is there any errors in xorg.log or dmesg when the slow down happens?
> > 
> > Nothing in dmesg - I briefly saw a different line scroll off when I quit X but
> > my fbcon scroll back seems to be limited to a couple of lines so I can't say
> > what it said. Now I've tried the other patch I'll try and recreate it and
> > redirect to a file this time.
> > 
> 
> After waiting ages and accumulating 22k reloc errors I decided to retrace my
> steps and so now I've managed to find a way to trigger this - just use flash -
> something which doesn't usually happen as I run flashblock. Unblocking a flash
> totally trashes perf even after seamonkey is closed
> 
> The error when perf is trashed is -
> 
> space check failed in flush
> 
> oprofile (not that I totally trust it) shows most time in -
> 
> 1116680  80.3342  libpixman-1.so.0.17.3    libpixman-1.so.0.17.3   
> pixman_blt_mmx
> 
> It happens with unpatched head and the first patch.
> 
> Running with the second patch alone or + the first patch fixes it.
> 

It's much better with the patches (I've tested it only with both patches applied) but it's still possibly to provoke the slowdown. I just have to open a few youtube tabs (videos paused). pixman_blt_mmx still seems to be problematic.

Created attachment 34470 [details]
slowdown, both patches applied

I'm have no idea if those oprofiles are really needed. Please let me know if you find them useful. I don't want to flood this bug report with oprofiles which no one needs.

> Created an attachment (id=34470)
>  --> (http://bugs.freedesktop.org/attachment.cgi?id=34470)
> slowdown, both patches applied
>
> I'm have no idea if those oprofiles are really needed. Please let me know if
> you find them useful. I don't want to flood this bug report with oprofiles
> which no one needs.
>

They are good but there is still some missing information that has to be solved.

What is causing the pixman calls? (pixman is software rasterizer)

(In reply to comment #22)
> (In reply to comment #21)
> 
> > I've managed to find a way to trigger this - just use flash -
> > something which doesn't usually happen as I run flashblock. Unblocking a flash
> > totally trashes perf even after seamonkey is closed
> 
> More testing shows that not just any flash will trigger it, but this one does -
> 
> http://www.speedtest.bbmax.co.uk/
> 

Might be related to bug #15293. In that case the performance hit was caused by flash reading back the video in order to draw stuff (e.g. the controls) over it.
I did see a bit of activity in pixman, though it was nowhere near what you're seeing.

(In reply to comment #21)

> The error when perf is trashed is -
> 
> space check failed in flush
> 
> oprofile (not that I totally trust it) shows most time in -
> 
> 1116680  80.3342  libpixman-1.so.0.17.3    libpixman-1.so.0.17.3   
> pixman_blt_mmx
> 
> It happens with unpatched head and the first patch.
> 
> Running with the second patch alone or + the first patch fixes it.

I was too hasty in saying the second patch fixes it - I can still trigger, it just takes a bit longer.

With patch2 I don't see the "space check failed in flush" errors when it happens.

The pixman oprofile above was running glxgears after triggering and closing seamonkey.

If I take a profile while just moving an xterm around (which is only redrawing at 2fps) then libc memcpy is the cpu hog and libpixman barely shows.

Created attachment 34512 [details]
sysprof of glxgears running at 7fps

(In reply to comment #25)

> They are good but there is still some missing information that has to be
> solved.
> 
> What is causing the pixman calls? (pixman is software rasterizer)

In case it shows anything more than oprofile.
Here's a sysprof of glxgears running at 7fps after I've triggered the bug.

It does look like the X driver is falling back to software for everything for some reason.

bc93395b3eb5e3511c1b62af90693269f4fa6e13 should hopefully fix this.

(In reply to comment #30)
> bc93395b3eb5e3511c1b62af90693269f4fa6e13 should hopefully fix this.
> 

I'm using git version 6baa96c44ca93b88acf5233335cee233e59d5af4 and wasn't able to trigger the software fallback. Hopefully this bug is really fixed as it was not clear what actually triggered the bug.

i have no problem anymore ( Bug 27283), with last git.

thanks !

(In reply to comment #30)
> bc93395b3eb5e3511c1b62af90693269f4fa6e13 should hopefully fix this.
> 

Todays head is working OK for me.

I'm still experiencing similar effects. Firefox triggers the "[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !" messages when scrolling up/down fast. Sometimes Xorg freezes. Remote ssh is still possible, but I didn't get a shell, just motd. At one occasion it didn't crash complete and i got the following dmesg output (attachment). Xorg.0.log is not reporting anything special. Maybe it's a different bug, but the message is still the same...

Software is:
Kernel:    2.6.33-2-amd64 from Debian experimental
libdrm2:   2.4.18-4
libgl:     7.7.1-1
radeon:    1:6.13.0-1
xorg-core: 2:1.7.6-2

Hardware:
01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3470 (prog-if 00 [VGA controller])
	Subsystem: PC Partner Limited Device e390
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 34
	Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M]
	Region 2: Memory at d0100000 (64-bit, non-prefetchable) [size=64K]
	Region 4: I/O ports at 2000 [size=256]
	Expansion ROM at d0120000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: radeon

Created attachment 35012 [details] [review]
dmesg output on hang

Created attachment 35013 [details] [review]
Xorg.log after hang

*** Bug 27678 has been marked as a duplicate of this bug. ***

still seems to be problematic.

Alex, on bug 27678 Brian has identified that Ubuntu's 1:6.12.192-2ubuntu2 does not show the problem, so it looks like this is a regression between 6.12.192 and 6.13.0 if that helps.

(In reply to comment #39)
> Alex, on bug 27678 Brian has identified that Ubuntu's 1:6.12.192-2ubuntu2 does
> not show the problem, so it looks like this is a regression between 6.12.192
> and 6.13.0 if that helps.

Ubuntu's 6.12.192-2ubuntu2 mentioned above was a git checkout up to commit 5c256808cb5fea955eea96ffe9196473715156aa
"XAA: disable render accel"

after the 6.12.192 tag for future reference.

The debian version 1:6.12.192-2 also works fine on my system.

Can you narrow down with op is causing the problem?  Add:
return FALSE;
to the top of R600PrepareCopy() or R600PrepareSolid() or R600UploadToScreenCS() or R600DownloadFromScreenCS() or R600PrepareComposite() in r600_exa.c and see if any of them prevent the problem.

I tried disabling, one at a time. Results are not very useful, I fear:

1 Disabling R600PrepareCopy resulted in slow FF scrolling

2 Disabling R600PrepareSolid: Xorg freeze

3 Disabling R600UploadToScreenCS: Xorg freeze

4 Disabling R600DownloadFromScreenCS: Xorg freeze

5 Disabling R600PrepareComposite: no freeze, just slow scrolling. I tried it for ~20 minutes, methods 2, 3, 4 crashed after <5 minutes.

The funny thing is, that I got no "Failed to parse relocation" dmesg errors. Maybe debian/ubuntu isn't using the git tag xf86-video-ati-6.13.0 as I did in these tests...

*** Bug 24003 has been marked as a duplicate of this bug. ***

I don't know if it is helpful but here I just get slow scrolling in firefox.

A good example of extremely slow webpage is http://www.ofai.at/research/agents/conf/at2ai7/

And I also get the error:
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !

But that's all.

I am closing this bug as the original issue is fixed, please test a kernel which has the e86527533586259875f08fccb173e3347046cc3f commit and if such kernel fails open a new bug and attach full dmesg + full lspci -v output.

You can test :
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-testing

Hi. I have manually applied the patch that the mentioned commit consists of, but the problem only seems mitigated, not fixed.

In dmesg I just found this:
radeon 0000:01:05.0: ffff880109913200 reserve failed for wait

Video device is:
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3200 Graphics (prog-if 00 [VGA controller])

Also, I was wondering whether an issue which was apparently pinpointed as a radeon driver regression could be fixed by a kernel patch alone (of course it's possible, I was just wondering). And then, would it be possible that it's not that commit alone, but a "family" of patches that fixed the issue?

Honestly I don't feel I have the authority to reopen this bug, but I'm not sure it can actually be called "resolved-fixed".

I am obviously available to provide detailed information and to help troubleshooting and isolating even further the issue, if needed.