Bug 16023

Can you ssh into the system after the crash?  Does it also occur when you VT switch?

Oh wait, you've got a funky xorg.conf...  There should only be one driver section for the main PCI device (0:2.0), the other one is just for Windows legacy use; and zaphod mode is no longer supported, so the "Screen 0" and "Screen 1" options shouldn't be used.

You might try running with an empty xorg.conf or following the instructions at http://www.intellinuxgraphics.org/dualhead.html if you want a dual screen setup.

Created attachment 16707 [details]
Xorg server configuration (Updated)

(In reply to comment #1)
> Can you ssh into the system after the crash?  Does it also occur when you VT
> switch?
> 
> Oh wait, you've got a funky xorg.conf...  There should only be one driver
> section for the main PCI device (0:2.0), the other one is just for Windows
> legacy use; and zaphod mode is no longer supported, so the "Screen 0" and
> "Screen 1" options shouldn't be used.
> 
> You might try running with an empty xorg.conf or following the instructions at
> http://www.intellinuxgraphics.org/dualhead.html if you want a dual screen
> setup.
> 
Thanks for your reply. Sorry I haven't gotten back to you until now, I have been away.
The system is completely dead. SSH connections do not work, nor does terminal switching. I've attached my new Xorg.conf without any references to dual head usage (since dynamic setup with xrandr makes more sense to me). This does not address my problem, and lockups still occur. I retested SSH connections and terminal switching, which don't work either. Obviously, when testing the Xorg.conf, I ensured the driver was set to, "intel" and not, "vesa".

I was wondering what the status is of this bug in terms of diagnosing the cause. I apologise if the information I have provided is inadequate, if more information is required please ask and I will provide.

An X log file might help here, but it may not have useful information since your system crashed.

This may be a duplicate of one of the other bugs we have, it sounds a bit like 15168, can you try the "ForceEnablePipeA" option in your xorg.conf?

Either way, the fact that you've narrowed things down a bit to DRI is hopeful; I gather from your earlier comments that things work ok as long as DRI is disabled?

(In reply to comment #5)
> An X log file might help here, but it may not have useful information since
> your system crashed.
> 
> This may be a duplicate of one of the other bugs we have, it sounds a bit like
> 15168, can you try the "ForceEnablePipeA" option in your xorg.conf?
> 
> Either way, the fact that you've narrowed things down a bit to DRI is hopeful;
> I gather from your earlier comments that things work ok as long as DRI is
> disabled?
> 
Although looking at X log files hasn't revealed anything useful to me, I'll post a copy since I'm hardly qualified to say it's of no use. I've tried the ForceEnablePipeA option in the past, it doesn't work. The manpages make it sound as if it's the option most relevant to my problem.
Disabling DRI enables the driver to work, but occasionally the screen will flicker. Sessions of more than 30 minutes see the screen go completely black. I can switch to other terminals or kill X using the three finger salute or manually terminating the process, but the intel driver only displays a black screen until I reboot.

I'll post an X log tomorrow - I'm off to bed since I've got an A-level Economics exam tomorrow (the only conceivable advantage of being a student?). Thanks for your continued help.

Created attachment 16999 [details]
Xorg server configuration (Working)

(In reply to comment #5)
> An X log file might help here, but it may not have useful information since
> your system crashed.
> 
> This may be a duplicate of one of the other bugs we have, it sounds a bit like
> 15168, can you try the "ForceEnablePipeA" option in your xorg.conf?
> 
> Either way, the fact that you've narrowed things down a bit to DRI is hopeful;
> I gather from your earlier comments that things work ok as long as DRI is
> disabled?
> 

The bug is fixed, seemingly. I changed the driver section in my Xorg configuration to use the Intel driver (with DRI enabled). With and without, "ForceEnablePipeA" I can now exit X when using the Intel driver without a lock-up. I have tried shutting down the system and starting up again to make sure it's not a fluke, and everything works OK. I have left an X session running for 30 minutes with a glxgears window open, a Prison Break video playing in MPlayer, xcompmgr running and Firefox running with five tabs with Flash objects active and the session has not gone to a black window as usually happens.

The versions of xorg-server and xorg-xf86-video-intel are identical to the original post and haven't been recompiled. I'm using the same copy of the kernel, and no system changes have occurred.

I've attached the xorg.conf which I'm using now. I'm not sure if I should mark this bug as resolved or leave as assigned, since the fix has literally come out of thin air. I'll leave it to the discretion of you to decide - something in this post may indicate if it's resolved or not. Either way, I'll update you on if the bug returns.

To satisfy my curiosity, is there any plausible explanation as to why the bug has seemingly vanished?

Sounds pretty weird...  If nothing's really changed, then I don't know why this problem would have fixed itself.  Maybe you have a hardware problem?  Loose RAM or connection somewhere?  I'll close it for now since things seem to be working for you, but don't hesitate to file another bug if you run into another reproducible problem.