[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.01.0909081502510.7458@localhost.localdomain>
Date: Tue, 8 Sep 2009 15:06:21 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jesse Barnes <jbarnes@...tuousgeek.org>
cc: reinette chatre <reinette.chatre@...el.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kernel Testers List <kernel-testers@...r.kernel.org>,
Eric Anholt <eric@...olt.net>, "Ma, Ling" <ling.ma@...el.com>,
"bugzilla-daemon@...zilla.kernel.org"
<bugzilla-daemon@...zilla.kernel.org>
Subject: Re: [Bug #13819] system freeze when switching to console
On Tue, 8 Sep 2009, Jesse Barnes wrote:
>
> Yeah, saw that. I don't think that's the root cause though. If we see
> a user interrupt after gem_idle is called we may have serious issues in
> our command handling code.
Quite frankly, I do not understand why you seem to be making excuses for
code that causes a very nasty and undebuggable oops, causing the machine
to die.
This regression is almost two months old, and apparently the Intel
graphics people DID ABSOLUTELY NOTHING about it during those two months,
because they couldn't be bothered to look at it.
And now, when I pinpointed exactly where the oops happens, and what the
cause is, you seem to be trying to hold things up. I wanted to do the
final 2.6.31 release yesterday, quite frankly I'm not in the _least_
interested in excuses, I'm interested in something that at least gets us
back to the 2.6.30 state that doesn't oops!
Get me a patch, please. If disabling the interrupts early won't work, get
me something else. Stop delaying it - it's been pending for 48 days
already.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists