OK those X lockups don't want to disappear. When I try to switch TTY ( alt+ctrl+F{1,2..} ) I get a X lock_up. System doesnt respond to keyboard . The only way to reset it is via sysrq button. Reproducible: Always Steps to Reproduce: 1.emerge gentoo-sources-2.6.28-gentoo-r3 2.switch tty via alt+ctrl+F{1,2,etc} I am not sure if this is related to intel drivers. Seems to me like a pure kernel issue Actual Results: X lock up. System doesn't respond to keyboard input Expected Results: everything to work fine You will find a dmesg log attached Xorg.0.log doesnt report any issues about the lockup
Created attachment 184846 [details] dmesg log
Seems to me that this bug is related to this one http://bugzilla.kernel.org/show_bug.cgi?id=12491 There is a fix but I am not sure how to backport the commit. I need to take a closer look to see if the upstream bug is exactly like mine
Would you mind testing vanilla-2.6.28.6 and letting me know the results?
No Mike, it still fails :(
Which is the last known working kernel? The upstream bug does not seem related. Which versions of xf86-video-intel? Are you using compiz? Which version of libdrm? Possibly related to #253813 although that one lacks details too. What is on the screen at the point of crash?
Daniel, changing TTYs worked back on 2.6.27 kernels. I did some tests and doesnt work anymore on any gentoo-sources with 2.6.28 kernel. I have 2.6.3 intel driver, I dont have compiz or kde4 3d effects. I am using libdrm-2.4.5 When I return back to TTY 7, i get the lock up, All I can see is a mouse pointer that doesnt moves at all, and a black or corrupted screen. If I use 2.5.1-r1 intel driver, everything works fine. I dont remember if i was using that driver or 2.6.3 on 2.6.27 kernels, and unfortunately I cant go back cause I use ext4 fs now
OK, then we can't be sure that this is a kernel regression. Can you find the first intel driver version which fails?
The latest working driver was 2.5.1 . Every 2.6.X driver causes this problem. The first faulty driver is 2.6.1
This bug is not reproducable anymore with 2.6.3 drivers, xorg-1.6 and 2.6.29 kernel. Should I close this bug as "invalid" ?
Remi, we have a few bugs like this (also hangs when starting X) which seem to go away when xorg-server is upgraded to v1.6. What do you think about patching out KMS support from xorg-server-1.5 once 1.6 is in portage?
sorry, should have addressed this at the entire herd: (In reply to comment #10) > Remi, we have a few bugs like this (also hangs when starting X) which seem to > go away when xorg-server is upgraded to v1.6. What do you think about patching > out KMS support from xorg-server-1.5 once 1.6 is in portage? >
(In reply to comment #10) > Remi, we have a few bugs like this (also hangs when starting X) which seem to > go away when xorg-server is upgraded to v1.6. What do you think about patching > out KMS support from xorg-server-1.5 once 1.6 is in portage? Actually, there's no "KMS support" within xorg-server at all, so there's nothing to patch out per se. Now I hear you ask "but why then xorg-server 1.6 fixes so many bugs?!". That's because xorg-server 1.6 provides the DRI2 infrastructure. In a nutshell, the initialization paths within xf86-video-intel make up like 20% of the code. And there's a different initialization path for every combination of {DRI1,DRI2}x{XAA,EXA,UXA}x{UMS,KMS}x{!GEM,GEM}. And since upstream has been busy testing out DRI2 first, the older DRI1 code paths are just bit-rotting. Which is why xf86-video-intel won't have all those code paths anymore [1]. My plan here is to get xorg-server 1.6 out into ~arch pretty soon so we can finally see those last few intel bugs whither away. I hope that clarifies a few things for everybody :) Cheers [1] http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/
OK, complicated! But as for stable users, they will be running 2.6.28, xorg-server-1.5 and xf86-video-intel-2.6.3. Hence they will likely run into issues such as this one if they enable KMS in the kernel, right? What options do we have for forcing/helping users avoid such a configuration?
Even if KMS is enabled in the kernel, it can be disabled by appending "i915.modeset=0" to the kernel command line. So that's definitely the first thing to recommend. Other than that, users might have to : - upgrade the kernel to ~arch (or even git-sources) - upgrade xf86-video-intel to 2.7.x - upgrade the whole X stack to 1.6 That's all I can think of right now. There's not much else to do :/ Cheers
OK...will maybe try and get upstream to make the help text for that kernel option be more scary towards xorg-server-1.5 users. Workaround for this bug: disable kernel mode setting by default, boot with i915.modeset=0 kernel parameter, or upgrade to xorg-server-1.6.
*** Bug 264128 has been marked as a duplicate of this bug. ***
