Bug 20454

Created attachment 23510 [details]
Xorg.0.log.HANG

try removing this option:
Option       "DynamicClocks"

Also, does this option help?
Option "BusType" "PCI"

Dear Alex,

Sry, I forgot to add, that I had played with the Dynamic Clocks after the EXA experiments.

The output: It's not a matter of dynamic clocks. everything works perfectly well with XAA and locks with EXA.

--> Your suggestion

trying the BusType: That solved the lockups, but left me with very very poor performance and strange artifacts around every piece of text.
So I added EXAVsync - which didn't help...

So it has something to do with AGP, doesn't it?

---

do you at least get paid for the awsome work you're doing here?

(In reply to comment #2)
> try removing this option:
> Option       "DynamicClocks"
> 
> Also, does this option help?
> Option "BusType" "PCI"
> 

Can my answers actually reach you? I've seen, that the bug is mailed to a wrong list... I'll correct this in a minute.

You know, with a BuyType "PCI" videos are laggy and the overall performance is worth than with XAA.

I need the notebook for presentations and videos - so I can't stand not having clean playback. This also is the reason why I actually wanted EXA - I encountered jittering in some videos using XAA (and xv as xine-parameter), which was not the case when I switched to EXA and xshm (as a xine-parameter). But how should I explain to the audience, that the system just froze and we have to restart to see how the presentation goes on...?  :)

But we have a first hint: It seems to have sth to do with AGP. As described above, we've also had problems with the AGP Mode back in 6.9.0 - times. Because of the qirk which was added back then, the Server uses an AGPMode of "1" - this is all I can say, unfortunately.


Thank you very much,

Simon

(In reply to comment #4)
> As described above, we've also had problems with the AGP Mode back in 6.9.0 -
> times. Because of the qirk which was added back then, the Server uses an
> AGPMode of "1"

Have you tried if other values work better now?


P.S. The QA contact address was correct, see 'Assigned To:'.

(In reply to comment #5)
> (In reply to comment #4)
> > As described above, we've also had problems with the AGP Mode back in 6.9.0 -
> > times. Because of the qirk which was added back then, the Server uses an
> > AGPMode of "1"
> 
> Have you tried if other values work better now?
> 
> 
> P.S. The QA contact address was correct, see 'Assigned To:'.
> 

Yep, I have tried it and the Bus Type "PCI" makes the freezes go away (I wrote that above).

However, the disadvantages are: Very poor performance and artifacts around written text (on desktop / menus etc.) with and wihout EXAVsync...

With BusType "AGP" this was not the case, but this also made the system hang after 1-2 minutes.

===!!!===

There is a strong relationship between the freezes and the cairo-dock! Without the cairo-dock running, X freezes after 10-15 minutes instead of 1-2 minutes. 
But this can't be caused by a total lack of composition, because I keep using compiz-fusion...

(In reply to comment #6)
> > > As described above, we've also had problems with the AGP Mode back in 6.9.0 -
> > > times. Because of the qirk which was added back then, the Server uses an
> > > AGPMode of "1"
> > 
> > Have you tried if other values work better now?
> 
> Yep, I have tried it and the Bus Type "PCI" makes the freezes go away (I wrote
> that above).

Yes, I asked if you tried different values for Option "AGPMode". BusType is a different option, setting it to "PCI" disables AGP.

(In reply to comment #7)
> (In reply to comment #6)
> > > > As described above, we've also had problems with the AGP Mode back in 6.9.0 -
> > > > times. Because of the qirk which was added back then, the Server uses an
> > > > AGPMode of "1"
> > > 
> > > Have you tried if other values work better now?
> > 
> > Yep, I have tried it and the Bus Type "PCI" makes the freezes go away (I wrote
> > that above).
> 
> Yes, I asked if you tried different values for Option "AGPMode". BusType is a
> different option, setting it to "PCI" disables AGP.
> 

Ok, sorry, I didn't get that.

I can only set AGPMode to "1". Every other value also freezes X.

http://bugs.freedesktop.org/show_bug.cgi?id=19406

Alex Deucher informed me back then, that there is a quirk in newer versions than 6.9.0...


So, experimenting with values for AGPMode is unfortunately impossible.

you might try a newer drm with the ring padding patch, Dave's drm-next tree (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary) which will require you to compile a new kernel, or the r6xx-r7xx-support branch of the drm tree at fdo (I've pulled in the padding patch).
http://cgit.freedesktop.org/mesa/drm/log/?h=r6xx-r7xx-support

(In reply to comment #9)
> you might try a newer drm with the ring padding patch, Dave's drm-next tree
> (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary) which
> will require you to compile a new kernel, or the r6xx-r7xx-support branch of
> the drm tree at fdo (I've pulled in the padding patch).
> http://cgit.freedesktop.org/mesa/drm/log/?h=r6xx-r7xx-support
> 

Hi Alex,

I tried the latest drm from git with the r6xx-r7xx-support-patch. Sorry for not knowing these sort of things ... did I do it right?
I went here: http://cgit.freedesktop.org/mesa/drm/commit/?h=r6xx-r7xx-support&id=cf8196e6eb9723a13f2155a4e253e4f3c2698148 and downloaded the zip file.
extracted it INTO the drm folder which was cloned from git overwriting (and therefore patching) all the files in there.

Is that how u do it?

Then I bulit drm. The README told me to copy the (freshly built) *.ko files from the subfolder "linux-core" to "/lib/modules/VERSION/kernel/drivers/char/drm/" but in MY directory there was no subfolder "drm" in "char"!!!
is that normal, or shall I put the *.ko files elsewhere on OpenSUSE?

Can I somehow find out which DRM version is used at the moment? I didn't find anything like that in the Xorg.0.log


thank you and sorry for this mess of stupidity :)

you can either download the zip file, or clone the tree using git, don't do both :)

if you grab the zip, extract it, change to the linux-core folder, and run:
make drm.o radeon.o
then copy radeon.ko and drm.ko to your kernel module tree.
/lib/modules/VERSION/kernel/drivers/char/drm/
or on newer kernels:
/lib/modules/VERSION/kernel/drivers/gpu/drm/ for drm.ko
and
/lib/modules/VERSION/kernel/drivers/gpu/drm/radeon/ for radeon.ko

(In reply to comment #11)
> you can either download the zip file, or clone the tree using git, don't do
> both :)
> 
> if you grab the zip, extract it, change to the linux-core folder, and run:
> make drm.o radeon.o
> then copy radeon.ko and drm.ko to your kernel module tree.
> /lib/modules/VERSION/kernel/drivers/char/drm/
> or on newer kernels:
> /lib/modules/VERSION/kernel/drivers/gpu/drm/ for drm.ko
> and
> /lib/modules/VERSION/kernel/drivers/gpu/drm/radeon/ for radeon.ko
> 

thx for the how-to - I've done everything accordingly.

with the cairo-dock it still keeps hanging but without the dock it doesn't!!!

I stopped using it and I am at the moment in a long-term experiment. It looks like the server only freezes due to cairo-dock...

is there a way to find out which progress exactly locks up X ?

I'll let you know, if the server keeps hanging without the dock.

(In reply to comment #12)
> thx for the how-to - I've done everything accordingly.
> 
> with the cairo-dock it still keeps hanging but without the dock it doesn't!!!
> 
> I stopped using it and I am at the moment in a long-term experiment. It looks
> like the server only freezes due to cairo-dock...
> 
> is there a way to find out which progress exactly locks up X ?
> 

Not really.  It's usually a bad combination of commands in the accel code.  Also it sounds like cairo dock is hits some path that causes the problem.

> I'll let you know, if the server keeps hanging without the dock.
> 

The trick is to find out what cairo dock is doing that causes the lockup.

(In reply to comment #13)
> (In reply to comment #12)
> > thx for the how-to - I've done everything accordingly.
> > 
> > with the cairo-dock it still keeps hanging but without the dock it doesn't!!!
> > 
> > I stopped using it and I am at the moment in a long-term experiment. It looks
> > like the server only freezes due to cairo-dock...
> > 
> > is there a way to find out which progress exactly locks up X ?
> > 
> 
> Not really.  It's usually a bad combination of commands in the accel code. 
> Also it sounds like cairo dock is hits some path that causes the problem.
> 
> > I'll let you know, if the server keeps hanging without the dock.
> > 
> 
> The trick is to find out what cairo dock is doing that causes the lockup.
> 

allright...

I've already searched in the cairo-dock wiki and googled the cairo-dock lockup problem, but I seem to be quite alone with that, besides cairo-dock is documented in french better than in english and I don't speak french...

Unfortunately cairo-dock2 is only present as a deb package so I'll just wait whether cairo-dock 2 will do the same thing.

Maybe I can use alien to convert the debs - We'll see.

I aliened the debs and tried cairo-dock II which froze imediately.

now I'm changing to AWN - good luck to me.

Now freezes without cairo-dock so probably the only people how could help with this issue are the cairo-dock developers who might be able to log which process scrumbles up the video driver.

thank you!

I'll close the bug because it seems to be a cairo-dock issue, ok?

(In reply to comment #15)
> I'll close the bug because it seems to be a cairo-dock issue, ok?

No, a GPU lockup is a driver bug no matter how badly an application may behave.

(In reply to comment #16)
> No, a GPU lockup is a driver bug no matter how badly an application may behave.

That is assuming it isn't a hardware issue...

Well, it could be an hardware issue, but on the other hand lockups only appear with this one program - thats reproducably now.

Never had other problems with the GPU, neither with XAA or Window$.
Isn't it unlikely for a hardware problem to only occur in one situation with one program and not in any other gpu-using program?

Can you suggest any tests which I could run to narrow down the problem?

(In reply to comment #18)
> Never had other problems with the GPU, neither with XAA or Window$.
> Isn't it unlikely for a hardware problem to only occur in one situation with
> one program and not in any other gpu-using program?

Unlikely, but not entirely impossible.

> Can you suggest any tests which I could run to narrow down the problem?

Does

    Option "RenderAccel" "off"

work around the problem with EXA?

(In reply to comment #19)
> (In reply to comment #18)
> > Never had other problems with the GPU, neither with XAA or Window$.
> > Isn't it unlikely for a hardware problem to only occur in one situation with
> > one program and not in any other gpu-using program?
> 
> Unlikely, but not entirely impossible.
> 
> > Can you suggest any tests which I could run to narrow down the problem?
> 
> Does
> 
>     Option "RenderAccel" "off"
> 
> work around the problem with EXA?
> 

Nope, didn't work around. I'm simply using AWN now.

thanks,

Simon

I think I have the same problem with my Radeon Mobility 9600. The system completely freezes, even the music stops to play. This happens sometimes when I scroll in firefox. I don't know cairo-dock, but as the name suggests I think it uses the cairo libs, as well as gtk+ which is used by firefox.
So it seems cairo/glitz does some things the radeon driver doesn't like.
I'd post a log of my hangs but there's nothing special in it - feel free to ask for it if you need it anyway. ;)

(In reply to comment #21)
> I think I have the same problem with my Radeon Mobility 9600. The system
> completely freezes, even the music stops to play. This happens sometimes when I
> scroll in firefox. I don't know cairo-dock, but as the name suggests I think it
> uses the cairo libs, as well as gtk+ which is used by firefox.
> So it seems cairo/glitz does some things the radeon driver doesn't like.
> I'd post a log of my hangs but there's nothing special in it - feel free to ask
> for it if you need it anyway. ;)
> 

Is it the same thing, that only EXA makes your System freeze sometimes?

btw: Now that you mention it. Once or twice MY X froze due to firefox as well. Whereas the probability with cairo-dock was like 100% that it freezes in minutes while it's almost usable without cairo-dock right now!
As described above, I didn't have a freeze in 2 days, using EXA and Firefox all the time...

I don't want to use this bug for an off-topic discussion and I neither want to file another bug report for my stupid question. That is why it's written here.

It's still the same as above: Is there a global variable or similar to have FSAA with compiz? My cube looks like staircases :)

You know like "export __GL_FSAA_MODE=x" or so...

thx

(In reply to comment #23)
> I don't want to use this bug for an off-topic discussion [...]

Yet you are...

> It's still the same as above: Is there a global variable or similar to have
> FSAA with compiz?

FSAA isn't implemented yet in the free Radeon 3D drivers.

Thank you.
Sorry...

(In reply to comment #22)
> Is it the same thing, that only EXA makes your System freeze sometimes?

Let's see. I've been using XAA since I posted my comment above and it hasn't crashed so far. I'll post again here if it freezes again with XAA.

(In reply to comment #26)
> (In reply to comment #22)
> > Is it the same thing, that only EXA makes your System freeze sometimes?
> 
> Let's see. I've been using XAA since I posted my comment above and it hasn't
> crashed so far. I'll post again here if it freezes again with XAA.
> 

Did you mix XAA and EXA in your post? It doesn't make sense to me... :)

Like described I, too, can use EXA without crashes now, if not using cairo-dock.

(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #22)
> > > Is it the same thing, that only EXA makes your System freeze sometimes?
> > 
> > Let's see. I've been using XAA since I posted my comment above and it hasn't
> > crashed so far. I'll post again here if it freezes again with XAA.
> > 
> 
> Did you mix XAA and EXA in your post? It doesn't make sense to me... :)

Oh, maybe I didn't explain it clearly enough. My system freezes with EXA sometimes (mostly when I use firefox), but with XAA there haven't been any problems _so far_ (except that it is a bit slower).

My versions are:
xf86-video-ati-6.11.0
xorg-server-1.5.3-r4 (gentoo)
Linux 2.6.27-gentoo-r9

I had the same problem with 6.10.0, too. I think 6.9.0 worked fine with EXA, but it didn't have render acceleration. 6.8.0 and older were unusable with EXA for me, as they used 50% cpu time when idle and everything was sluggish as hell, so I didn't test that further - it could have been a problem with xorg-server-1.3 as well.

Created attachment 24460 [details] [review]
possible fix

Does this patch (against xf86-video-ati git master) help?

thank u for taking care.

I will try your fix - unfortunately I quite do not know how to deal with the flush_after_each_sequence.diff file that was created saving your patch into a file.

I tried the patch tool, which only told me of missing arguments.

can you tell me how to apply the patch against the cloned git master directory?

thank you

patch -p1 -i flush_after_each_sequence.diff

Sorry. I had to use

patch -p 1 -i flush_after_each_sequence.diff

that worked.

I am now building and testing - I'll be back.

(In reply to comment #32)
> Sorry. I had to use
> 
> patch -p 1 -i flush_after_each_sequence.diff
> 
> that worked.
> 
> I am now building and testing - I'll be back.
> 

LOL!!! figured it out as fast as u replied.

As written, I'll be right back :)

I applied the patch successfully, built the hole thing with --prefix=/opt/radeon, went there and copied everything with "-R" to /usr

however, it didn't work - cairo-dock froze X after less than one minute.

thats sad

dunno whether this helps, maybe it's another bug.

I've just had some strange issues: I was just logged out of KDE after the splash screen. The login screen appeared and I gave it a second try - without any success. So I wanted to switch into runlevel 3 and pressed ctrl, alt, F1 - and only saw a lot of strange, red and pink artifacts!

Switching back to F7 made a corrupt login screen reappear, without being able to move the mouse. Well, I thought it would be a heavy hang again, but I've been able to reboot via ctrl, alt, del.
Next boot everything was OK...

these problems increase, when I use renderaccel or acceldfs.

And I can add a very unspecific suspicion.

Over the last days, X froze frequently as it did with the cairo-dock (no mouse move, no shutdown possible).
This happened since I'd been using compiz 0.8.2. I think the problem described in the last comment was (as well) caused by either compiz or X or KDE...

However, I switched back to XAA. And then I realized a very funny thing which I quite don't get: Watching a video with kaffeine (xine output) using xshm as output option, the CPU load had been MUCH MORE than now using xv output and XAA.

Only with xshm and EXA I had been able to use the compositing effects on a video window. My thought was that only xshm would use the GPU for video decoding. This does not seem to be true, though. At least the reduced CPU load (on xv output and XAA) indicates a better use of the ressources, doesn't it? The video also seemed to be playing more fluently. 

I can't see the video while using alt/tab (ring switcher) and I can not zoom into a video, but I can WATCH it with reduced CPU load more fluently and that is what counts, isn't it?

summary:
We unfortunately do not seem to be able to log what exactly locks up the GPU sometimes on my system. It could have been the cairo-dock, but not only that one, cause the problem occured without the cairo-dock as well.

Of course, EXA is better for compositing and zooming into videos but in my case stability has a higher priority.

Thank you!

And if you happen to want me to test some patches or so, just give me a hint. I would be glad to be able to support your marvelous work with this driver, even if I could only help a tiny tiny bit.

I'm not sure what you're getting at... you can use Xv or XSHM with EXA just as well. Also, the textured XVideo adaptor integrates properly with compositing. Not sure how to select it in kaffeine though.

Can you attach one log file each from EXA with RenderAccel off and from XAA? It's weird that those two cases would behave differently...

Also, you're saying the problem only occurs with compositing? With kwin, does it only happen with the OpenGL backend or also with XRender?

Created attachment 24861 [details]
Xorg with EXA logfile

Created attachment 24862 [details]
Xorg with XAA logfile

Created attachment 24863 [details]
Screenshot of my EXA Cpu Load on idle

Created attachment 24864 [details]
Screenshot of my XAA Cpu Load on idle

(In reply to comment #37)
> I'm not sure what you're getting at... you can use Xv or XSHM with EXA just as
> well. Also, the textured XVideo adaptor integrates properly with compositing.
> Not sure how to select it in kaffeine though.
> 
> Can you attach one log file each from EXA with RenderAccel off and from XAA?
> It's weird that those two cases would behave differently...
> 
> Also, you're saying the problem only occurs with compositing? With kwin, does
> it only happen with the OpenGL backend or also with XRender?
> 

I might be able to have both Xv or XSHM with EXA but with XAA I can only use Xv, because using xshm the videos become a slideshow :)

Right now I am testing Kwin with Xrender and OpenGL. The problem is that my freezes occur quite randomly, so I can't tell for sure when a configuration works stable.

===

can you think of an explenation of the CPU-Load issue? It was definitely the process "Xorg" eating 100% (or nearly) of my CPU on EXA.

I played with XAA and EXA and Kwin's OpenGL and Xrender with following output:

XAA and OpenGL: OK
XAA and Xrender: UNUSABLY SLOW
EXA and both: UNUSABLY SLOW

EXA still has it's CPU Load problems which make the hole system feel sticky (it takes ages to open dolphin). btw: with EXA I can never (no matter which window manager I use) see the Systray Icons!

(In reply to comment #43)
> EXA still has it's CPU Load problems which make the hole system feel sticky (it
> takes ages to open dolphin). btw: with EXA I can never (no matter which window
> manager I use) see the Systray Icons!

The latter sounds like maybe you're using a non-default value of Option "MigrationHeuristic", or maybe your distribution changed the default from upstream. The former issue may also be related to that, but it's hard to say without a specific profile.

Anyway this is getting rather off-topic for this report...

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.