Created attachment 16632 [details] Xorg server configuration When using the xorg-xf86-video-intel driver (2.3.1 current port version at time of writing) with DRI enabled, display corruption and a system lockup occur when exiting an X session via menus or using Ctrl+Alt+Backspace. The system is unresponsive, however NumLock and other similar indicators respond correctly, but I cannot switch to any other consoles or otherwise control the system. The corruption is a collection of lines covering the screen, usually purple and white. Sometimes this is not the case, with the screen being partially covered in these lines and otherwise black, or black entirely. This problem also occurs using the older i810 driver. I've tried revisions 2.1.1 through to 2.3.1 (including version of 2.2.99 which fixes the problem for some) of the intel driver by modifying the xorg-xf86-video-intel port for my distribution, all to no avail. It is worth noting that I've returned to using the 2.3.1 port as in the xorg repository for my distribution. I am using an Intel 950GMA graphics controller, listed by lspci as the following - "00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)" I'm running CRUX 2.4, with Linux 2.6.25.4. I have been able to reproduce the problem on Linux 2.6.24.7 and 2.6.25.3. I'm running the latest Xorg server build as per the xorg repository (1.4), with the system fully up-to-date at the time of writing. I've spent hours searching mailing lists and forums, even building my own version of the xorg-xf86-video-intel driver using patches reported to fix the problem (http://www.archlinux.org/packages/14160/). I have attached my X configuration file. It is of note that a variety of options mentioned by other people with this problem, such as what is mentioned in http://bugs.archlinux.org/task/7106 and http://bugs.archlinux.org/task/8976, have not fixed the problem. The only way I am able to use the intel driver is by disabling DRI. Disabling the composite extension, or using any other combination of options excluding DRI disabling, does not able me to exit X without a lockup. The load module line for dri has no effect if enabled or disabled, as with all other module load lines. If I enable DRI, the driver performs without issue until exiting. Regarding the examples used, I appreciate Arch Linux is not CRUX, but due to the similar nature of the problems described the references are of relevance to this bug. At the risk of sounding stupid, the xorg-xf86-video-intel driver, "used to work". Recent updates to X and the kernel have resulted in this bug, but I am unable to pinpoint it in terms of it being a driver, X server or kernel issue. When the system locks up, no further writing to the X log occurs (i.e. no error messages are listed), which is why I have not attached it to this post. If the log is required, I apologise in advance for not including it and will provide a copy on request. Using the vesa driver does not produce this bug, meaning (to my knowledge) only the intel and i810 drivers are experiencing problems. I have rebuilt my kernel, mesa3d, xorg-server and the drivers but this has not solved the problem. I would appreciate any insight into this problem. I apologise if the information I have given is inadequate - if anything is missing let me know and I will provide what is needed. Thanks for taking the time to help. I've marked the bug severity as high due to the fact that the bug causes a system lockup and could therefore lead to data loss. Updating to the prerelease version of xorg-server (1.4.99.901) does not address the problem, neither does using the git versions of the intel driver or DRM library. For reference, the original bug report submitted for my distribution is at http://crux.nu/bugs/index.php?do=details&task_id=276.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.