Created attachment 34394 [details] switching tabs in opera Switching tabs in firefox and opera is really slow after the latest commits.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.