| Summary: | Gem+i915 locks up xorg-server-1.5 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Markos Chandras (RETIRED) <hwoarang> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | gentoo, x11 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | dmesg log | ||
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. *** |
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