radeonhd doesn't work with kms.

if you filed this against the wrong component and are using radeon instead, please include the full X config and log as well as dmesg.

Created attachment 33967 [details]
output of dmesg

For the X config,  i'm using the autodetected magic and there isn't an xorg.conf file.  I can make one if I need to.

The X log file is more important than the config file anyway.

Created attachment 33994 [details]
xorg.0.log file

This is the xorg.0.log file.

Created attachment 33995 [details]
xorg.0.log.old file

Just in case this file may be of use.

Xorg.0.log.old shows an event queue overflow, but unfortunately there's no backtrace. Usually EQ overflows are just a symptom of a GPU lockup, but if the X server comes up again after the crash, that seems unlikely (but if it was the case, there should be something about it in dmesg, please attach the output of that). So I wonder if the queue could just be overflowing while ksnapshot is taking a screenshot... are you moving the mouse when it happens?

Created attachment 34011 [details]
dmesg output

I must have been moving the mouse.  I started ksnapshot several times and did not move the mouse and it didn't crash.  Then I started ksnapshot and moved the mouse and it took me back to the login screen.  So I reckon the event queue is filling up or something?

I forgot to mention that I am running dual 22 inch monitors, if that is useful.

[gkx]dm.log might be helpful too. Could you attach one where crash happens?

Created attachment 34143 [details]
kdm.log file

I apologize for the long delay in getting the kdm.log file.  x does crash if you move the mouse while ksnapshot is loading.  If you leave the mouse alone and wait till the initial capture is done, everything is ok.  

I noticed "[mi] EQ overflowing. the server is probably stuck in an infinite loop" inside the log file.

So it looks like the server abort is spurious, the event queue just overflows temporarily due to a request taking a long time to process. I think it would be better if the events were just dropped on the floor in that case. Peter, what do you think?

(In reply to comment #11)
> So it looks like the server abort is spurious, the event queue just overflows
> temporarily due to a request taking a long time to process. I think it would be
> better if the events were just dropped on the floor in that case. Peter, what
> do you think?

actually, this is what mieqEnqueue does when it happens, it simply stops appending events to the queue and returns early (see mi/mieq.c). This shouldn't crash the server though, I think there might be something else going on but I'd need to see an actual backtrace. Not sure why it is missing in the log file.

If there is something I can do to get a backtrace, I can do that because I can make it crash any time I need to.  

(In reply to comment #13)
> If there is something I can do to get a backtrace, I can do that because I can
> make it crash any time I need to.  
> 

do you have a second computer available? if so, you could ssh & gdb in and get a full backtrace when it happens.
See http://wiki.x.org/wiki/Development/Documentation/ServerDebugging
a simple "bt full" in gdb when it happens would already be quite helpful I guess.

Created attachment 34249 [details]
gdb debugging output

This is the debugging output from gdb.

(In reply to comment #15)
> Created an attachment (id=34249) [details]
> gdb debugging output
> 
> This is the debugging output from gdb.

It actually looks like it's seqfaulting _inside_ xorg_backtrace(). The mieqEnqueue() line indicated here (178) is the one where it prints the backtrace but then should continue otherwise. the backtrace generation fails however. weird.

(In reply to comment #16)
> It actually looks like it's seqfaulting _inside_ xorg_backtrace().

Indeed; given this and that the traces from it tend to be not too useful anyway, maybe the xorg_backtrace() calls should be disabled at least by default?

Submitter, if you disable the xorg_backtrace() call, does the server continue working properly under the same circumstances?

I'm looking up on how to disable the xorg_backtrace and then I'll try it.

It's still crashing, and I never did figure out how to disable xorg_backtrace.

(In reply to comment #19)
> It's still crashing, and I never did figure out how to disable xorg_backtrace.

Probably easiest to remove/disable the call in mi/mieq.c.

I upgraded to xorg-x11-server version 1.8.0-12 and this problem went away.

(In reply to comment #21)
> I upgraded to xorg-x11-server version 1.8.0-12 and this problem went away.

Closing this as fixed. Reopen if it shows up again.