On Tue, Jul 12, 2011 at 8:17 PM, Kirill Smelkov kirr@mns.spb.ru wrote:
On Sat, May 28, 2011 at 05:19:20PM +0400, Kirill Smelkov wrote:
Hello Chris, everyone,
On Sat, May 21, 2011 at 04:40:17PM +0100, Chris Wilson wrote:
On Sat, 21 May 2011 11:23:53 -0400, "Luke-Jr" luke@dashjr.org wrote:
On Saturday, May 21, 2011 4:41:45 AM Chris Wilson wrote:
On Fri, 20 May 2011 11:08:56 -0700, Ray Lee ray-lk@madrabbit.org wrote:
[ Adding Chris Wilson (author of the problematic patch) and Rafael Wysocki to the message ]
On Fri, May 20, 2011 at 10:06 AM, Luke-Jr luke@dashjr.org wrote: > I submitted https://bugzilla.kernel.org/show_bug.cgi?id=33662 a month > ago against 2.6.38. Now 2.6.39 was just released without the > regression being addressed. This bug makes the system unusable... Some > guys on IRC suggested I > email, so here it is.
See the bugzilla entry for the bisection history.
Which has nothing to do with Luke's bug. Considering the thousand things that can go wrong during X starting, without a hint as to which it is nigh on impossible to debug except by trial and error. If you set up netconsole, does the kernel emit an OOPS with it's last dying breath?
Why assume it's a different bug? I would almost wonder if it might affect all Sandy Bridge GPUs. In any case, I no longer have the original motherboard (it was recalled, as I said in the first post), nor even the revision of it (it had other issues that weren't being fixed). I *assume* I will have the same problem with my new motherboard (Intel DQ67SW), but I haven't verified that yet. I'll be sure to try a netconsole when I have to reboot next and get a chance to try the most recent 2.6.38 and .39 kernels, but at the moment it seems reasonable to address the problem bisected in the bug, even if it turns out to be different.
The bisection is into an old DRI1 bug on 945GM. That DRI has inadequate locking between release and IRQ and so is prone to such races as befell Kirill should not surprise anyone. As neither UMS nor DRI supported SNB, I can quite confidently state they are separate bugs. -Chris
I see DRI1 is maybe buggy and old, but still, pre-kms X used to work ok on kernels < 2.6.38, and starting from 2.6.38 the system is just unusable because X either crashes the kernel (2.6.38), or does not start at all (2.6.39):
https://bugzilla.kernel.org/show_bug.cgi?id=36052
It's a regression. It's blocking me to upgrade to newer kernels. I've done my homework -- digged it and came with detailed OOPS on netconsole and bisected to single commit. Could this please be fixed?
Silence...
Still, reverting the bisected patch helps even for 3.0:
Keith, Chris, what's up with this regression from 2.6.38? It seems commit e8616b6 ("drm/i915: Initialise ring vfuncs for old DRI paths") caused problems on other machines.