Bug 95192

Please attach the Xorg log file and output of dmesg, preferably captured after at least one such hang occurred.

Yes, I observed those files over the course of the years, but in these cases there is nothing int he logs.

On other occasions (e.g. testing vdpau) there were GPU freezes and the driver had to reset it and that was in the logs (or at least was much longer and with screen going black). So I can distinguish the cases. But for these short hangs, there is nothing.

Created attachment 123363 [details]
sample Xorg.log

This is a sample xorg.log file with EXA enabled. It is NOT after the hang, but I think there is no difference. Also, it has Tearfree enabled, but that does not affect the hangs.

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).

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.

Does the problem also occur without the kernel parameter vmalloc=384000000? And without any non-default options in xorg.conf?

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.

(In reply to Michel Dänzer from comment #4)
> 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).

But on such a low card, wouldn't EXA be always faster than anything openGL?

> 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.

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.

> Does the problem also occur without the kernel parameter vmalloc=384000000?
> And without any non-default options in xorg.conf?

I'll try.

> 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.

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.

(In reply to aceman from comment #5)
> (In reply to Michel Dänzer from comment #4)
> > 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).
> 
> But on such a low card, wouldn't EXA be always faster than anything openGL?

No, why? glamor is generally on par with EXA and for some operations such as text rendering (which is among the most important in practice) significantly faster. If there are any cases where glamor is significantly slower than EXA for you, please file bug reports against the Server/Acceleration/glamor component.


> > It might be interesting to see a backtrace of the Xorg process during a
> > freeze.
> 
> 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.

If you can ssh in from another machine, that might allow you to get more information about the hangs.


> Also of interest could be that the kernel is 64bit, but all the userland
> (X.org and mesa too) are 32bit.

Any chance you could try if the problem also occurs with 64-bit Xorg?

(In reply to Michel Dänzer from comment #6)
> > But on such a low card, wouldn't EXA be always faster than anything openGL?
> 
> No, why? glamor is generally on par with EXA and for some operations such as
> text rendering (which is among the most important in practice) significantly
> faster. If there are any cases where glamor is significantly slower than EXA
> for you, please file bug reports against the Server/Acceleration/glamor
> component.

So far I've seen glxgears fullscreen (full HD) does not manage the normal 60fps that EXA does. With glamor it is like 30fps. But I need to determine if it isn't caused by Tearfree.

> If you can ssh in from another machine, that might allow you to get more
> information about the hangs.

I am not able to ssh to the machine and run a tracer in 10 seconds ;)

> > Also of interest could be that the kernel is 64bit, but all the userland
> > (X.org and mesa too) are 32bit.
> 
> Any chance you could try if the problem also occurs with 64-bit Xorg?

That would require upgrading the whole distro. But I have that in planning in the next 1-2 months.

>> Does the problem also occur without the kernel parameter vmalloc=384000000?
>> And without any non-default options in xorg.conf?

Yes it does. I've removed these non-default options but the hangs are back (default switched from glamor to exa again).

(In reply to aceman from comment #7)
> (In reply to Michel Dänzer from comment #6)
> > > But on such a low card, wouldn't EXA be always faster than anything openGL?
> > 
> > No, why? glamor is generally on par with EXA and for some operations such as
> > text rendering (which is among the most important in practice) significantly
> > faster. If there are any cases where glamor is significantly slower than EXA
> > for you, please file bug reports against the Server/Acceleration/glamor
> > component.
> 
> So far I've seen glxgears fullscreen (full HD) does not manage the normal
> 60fps that EXA does. With glamor it is like 30fps. But I need to determine
> if it isn't caused by Tearfree.

After the upgrade mentioned below, glamor+tearfree also manages 60fps now.

> > > Also of interest could be that the kernel is 64bit, but all the userland
> > > (X.org and mesa too) are 32bit.
> > 
> > Any chance you could try if the problem also occurs with 64-bit Xorg?
> 
> That would require upgrading the whole distro. But I have that in planning
> in the next 1-2 months.

I have upgraded the distro to full 64bit now (kernel and apps). That involved a forced upgrade of KDE desktop to 4.0. That one has the compositor set to OpenGL 3.1 .

I haven't seen the intermittent hangs with this upgraded system ever. Everything in the desktop is smooth and performs fine (except real OpenGL apps of course, due to the low GPU:)). I tried both glamor and EXA. Maybe KDE 4 is using the GPU more properly.

So I've settled on glamor, as you say it is the way forward.

Let's close the bug until I can reproduce it again. Thanks for the cooperation.