Created attachment 28976 [details] Xorg log System Environment: -------------------------- Host: x-855gm Arch: i386 Platform: 855GM Libdrm: (master)0a732983f059c353b267b6bf877e1f0eea4e033f Mesa: (master)ba87cbf2be04d9d14d7e0b6d40508edadd4705e9 Xserver: (master)2fba2eac0b4c8d07bdf7bea20ef75ff579621728 Xf86_video_intel: (master)7c48c21b22bf5862c5a35bda1635753cc5a7197c Kernel_unstable: (drm-intel-next)f8aed700c6ec46ddade6570004ce2533 Bug detailed description: ------------------------- On UMS mode, start X will result in system hang. Other platforms don't have this problem. This issue only happens on Xsever master branch. It works well on server-1.6-branch. Reproduce steps: ---------------- 1.Start system with i915.modeset=0 2.xinit&
*** Bug 24237 has been marked as a duplicate of this bug. ***
This problem becomes urgent with people moving from server 1.6 to 1.7.
Let me know if I can help with testing any way.
Now that UMS is completely removed in the master branch, any hope this bug will be ever fixed (to help 2.9.0 users) or should I forget about UMS and users are forced to use KMS? Thanks.
I'm confused, is this problem only happen in UMS driver? And _not_ in KMS? The X log here looks using KMS, and can't see any problem from it. Miklos, could you attach your failure X log? and is it just Xserver crash or real machine hang?
> --- Comment #5 from Wang Zhenyu <zhenyu.z.wang@intel.com> 2009-10-13 18:48:13 PST --- > I'm confused, is this problem only happen in UMS driver? And _not_ in KMS? The > X log here looks using KMS, and can't see any problem from it. Right, when KMS is not enabled by default in the kernel then: modprobe i915 -> machine hangs when X starts modprobe i915 modeset=1 -> everything is fine > Miklos, could you attach your failure X log? Unfortunately not, as X freezes before creating any log file. > and is it just Xserver crash or real machine hang? Sadly the later. Let me know if you need more info about the machine, though I think I provided everything I can in Bug 24237. (lspci output, dmesg, xorg config.) If you need the Xorg log in case KMS is enabled (and when everything is fine), then let me know. Also, I was reporting this as a bug, as I understood that KMS is optional at the moment, so UMS is a supported use case. Let me know if I (or to be more exact, wearing my distributor hat, we at Frugalware Linux) should tell users that UMS is no longer supported for the Intel card users, once they upgrade to 1.7.0.
Could you try with git bisect? which might be possible to find the culprit commit for this. As master has removed UMS, you may try it on 2.9 branch.
Hrm, due to recent header changes, I first had to use git bisect to find the oldest commit that builds for me. ;) It's 9a3b568d62a0b48f4a42ea5377740b2df1af432a (intel: update for resources/RAC API removal, 2009-07-28). And sadly I can reproduce the hard lock with that as well. Are you sure this is az xf86-video-intel bug? I mean after all I got this problem when upgrading xorg-server (from 1.6 to the first 1.7 prerelease). But it's also possible that it's caused by a kernel change. Should I try to bisect the kernel instead?
I've tried this within gdb, which finally showed that the problem is i830_crtc_load_lut(). Disable palette update workaround the problem... But I'm not sure the reason for this, does xserver master has anything change for this? or other UMS change has side effect?...
Actually we just went ahead and enabled KMS by default in the kernel, so it's no longer a blocker issue for us, but I'm happy to test if disabling palette update solves the problem here if you want, just tell me how to disable that. ;) OTOH, I'm okay with an "UMS is no longer supported by the master branch, use KMS" answer as well and a WONTFIX resolution.
Deprecate UMS. Mark this as WONTFIX.
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.