Tuesday, 30 September 2008

X being unstable in F9?

Dear lazy web, I just hit a strange bug again that I know not at all how to handle. My screen just went all "broken" - some sort of black/purple/I-don't-remember-the-other-colours pattern was displayed there - meaning the X was dead. I knew that something's wrong because it hasn't happened for the first time and in the past I was more patient and tried to do something with that state. If I wait, X restarts but goes wrong again and this repeats several times until it stays in the broken state. The only thing I can do is to turn the computer off by hitting the power button which inhibits correct turn off of the computer - meaning the kernel is still accepting messages and working but the broken X block every keyboard input. If I recall correctly, I can still see and move the mouse pointer.

This happens really scarce, so scarce I don't remember what I was doing when it happened last time, but this time it happened when I tried to switch tabs in firefox and I have a feeling it happened in a similar situation before, but I don't remember. So in case this happens again, next time I can check with this post if the situation is same...

And until then, can someone directs me what to do? I tried looking in XOrg.log and /var/log/messages but there does not seem to be anything indicating the problem. I don't know what's causing it, where the bug is, how to triage it. Does anyone have similar experience or even better already know about a bug that's causing this? Or know where else can I look to for more info? I'd appreciate any input.

I have an intel video card and appart from having metacity 2.23.21 pulled from rawhide with compositing turned on I have pretty much ordinary, up-to-date F9 environment...

UPDATE: As per mcepl's suggestion, I've filled a bug against xserver. Hope it helps. If you suffer similar issue, leave your comments and logs there.
https://bugzilla.redhat.com/show_bug.cgi?id=464878

9 comments:

Jud said...

I still don't trust compositing; it's very useful, but whenever X crashes or glitches up I am always suspicious of it.

At any rate, if you run composite-less, you'll be sure the crashes aren't the fault of the compositor.

--McD said...

Why not Cntl+Alt+F1. Then log onto the text console and shutdown -r

Sometimes you can get X started. Usually I'm not so lucky. But at least you can don *something*

Anonymous said...

F9 shipped a pre-release version of xorg 1.5 IIRC, maybe that is it.

Martin said...

--mcd: Well, seems like I wasn't self-explanatory enough in the post - what I meant that the keyboard input seems blocked by the busted XOrg is that I cannot swith to text console or kill the XOrg myself. I might be able to ssh to the machine, but don't have from where :-)

Martin said...

anonymous, no that's not it (I think). There has been released a stable X version since then and I have it installed.

mcepl said...

Hi, Martin,

instead of writing a blog post, write a bug to http://bugzilla.redhat.com. I would then tell you that there is not that much interesting in /var/log/messages, because all interesting stuff is in Xorg.*.log, which I would then ask you to attach to the blog, together with /etc/X11/xorg.conf. :)

Matěj Cepl

Martin said...

mcepl, thanks for the offer. I reexamined XOrg.0.log.old file and there seems to be something indicating the issue, but nothing prefixed with (EE). I am not sure if filling a bug helps, as I am not at all sure if we are able to successfully triage the issue - I am not able to reproduce it and random crashes that happen with a little of trace are hard to fix... But I'll file the bug nevertheless.

I wrote it in a blog in hope that I might run into someone who has similar issue, which might help with triaging.

Andrew said...

There seems to be some issue with the update of xorg-x11-server-Xorg-1.5.0. On my RV280 ATI machine Flash stopped being able to be played without consuming 100% of the CPU. Downgrading back to xorg-x11-server-Xorg-1.4.99.905-2.20080702.fc9.i386 and xorg-x11-server-common-1.4.99.905-2.20080702.fc9.i386 fixed it. I was going to open a bug, but, since I had no (EE) entries in my xorg.*.log file either I figured that mcepl would just close it as NOTABUG.

In any event I doubted my problem with F9 xorg would get any attention, considering the effort going into trying to get kernel mode setting to work well enough for F10. They barely got xorg libdrm and mesa working in the days leading up to F9 that any changes are likely to upset the apple cart.

nicu said...

@Martin: but if you fill a bug report you are sure that you did "the right thing" and nobody will ask you to fill one.
A good policy is to fill the bug and *then* ask on your blog/forum/list, with a link to BZ.

The additional benefit from using BZ it that someone else may have the same problem and find your report/solution/workaround in BZ.