Created attachment 28976 [details]
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.
1.Start system with i915.modeset=0
*** 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?
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 <email@example.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.