<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [EXA] X server intermittently hangs for short moments with rv710 card"
href="https://bugs.freedesktop.org/show_bug.cgi?id=95192#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [EXA] X server intermittently hangs for short moments with rv710 card"
href="https://bugs.freedesktop.org/show_bug.cgi?id=95192">bug 95192</a>
from <span class="vcard"><a class="email" href="mailto:acelists@atlas.sk" title="aceman <acelists@atlas.sk>"> <span class="fn">aceman</span></a>
</span></b>
<pre>(In reply to Michel Dänzer from <a href="show_bug.cgi?id=95192#c4">comment #4</a>)
<span class="quote">> First of all, I consider using glamor a very good workaround. In fact, I'm
> planning to try enabling glamor by default on >= R(V)6xx once DRI3 is
> enabled by default (which I'm planning to try soon).</span >
But on such a low card, wouldn't EXA be always faster than anything openGL?
<span class="quote">> If the mouse cursor is frozen as well during the hangs, it indicates that
> the Xorg process is hung so badly that it can't even react to SIGIO
> generated by the mouse input device (actually I'm not 100% sure that's still
> true with the mouse driver; does the mouse cursor also freeze during the
> hangs using the evdev driver instead of the mouse driver?). It might be
> interesting to see a backtrace of the Xorg process during a freeze.</span >
Maybe, but I can't produce it as I can't do anything during the freeze. And it
is not that long enough that I would manage to switch to virtual terminal and
run some trace.
<span class="quote">> Does the problem also occur without the kernel parameter vmalloc=384000000?
> And without any non-default options in xorg.conf?</span >
I'll try.
<span class="quote">> P.S. It would probably have been easier to identify the change or at least
> component which introduced the problem if it was reported sooner after it
> started happening.</span >
Surely. But I tried to find out what is causing it and made various long
experiments until I finally filed the bug.
E.g. I have an overclocked CPU on watercooling and due to this the kernel
disables TSC clock. So the current clock source is HPET (which is supposedly
slow). But I also tried acpi_pm without success.
Also of interest could be that the kernel is 64bit, but all the userland (X.org
and mesa too) are 32bit.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>