From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: 2.6.38-rc8 regressions Date: Mon, 14 Mar 2011 09:53:36 +0000 Message-ID: References: <20110314090811.GA4779@x61s.reliablesolutions.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id A9DC99E744 for ; Mon, 14 Mar 2011 02:53:39 -0700 (PDT) In-Reply-To: <20110314090811.GA4779@x61s.reliablesolutions.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Jan Niehusmann , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Mon, 14 Mar 2011 10:08:12 +0100, Jan Niehusmann wrote: > Hello, > > just to provide some testing feedback. I didn't have time (and probably > not even the necessary skills) to further diagnose these issues. But > as I don't remember seeing these problems with 2.6.37, maybe the > observations are interesting to you: > > With 2.6.38-rc8 I see the following graphics related regressions > (relative to 2.6.37) on a Thinkpad X61s with "Intel Corporation Mobile > GM965/GL960 Integrated Graphics Controller" (PCI ID 8086:2a02). > Userspace is debian/squeeze. > > 1) Every now and then, terminal windows (urxvt) do not properly update > their contents. After issueing a command like 'ls', which writes > several lines of text at once, some lines are completely missing. It's > not garbled glyphs, but full lines of text completely missing. > > Interestingly, sometimes the correct contents of the full window become visible > for a split second. So they seem to be 'somewhere' accessible to the GPU, just > not shown on the screen. > > When a single character in an affected line gets updated (e.g. by marking > it with the cursor - or even by an update in a different console window > next to the one affected) the correct contents of the full line become > and stay visible. > > When this problem occurs, it does so reproducibly: About every third > command writing to the terminal shows the behaviour. In that situation, > just closing and reopening the lid solves the problem: Console windows > work as expected again, and AFAICT the problem doesn't reoccur until the > next reboot or suspend/resume cycle. There was a bug in the DDX where we missing a flush (for precisely this style of bug): commit 4a186a612376bdd6f86c026e8b8b442108868a0a Author: Chris Wilson Date: Tue Dec 7 16:56:57 2010 +0000 Always flush the batch before blocking for new X requests This should prevent any lag when waiting upon user input, for example whilst logging in with gdm. Signed-off-by: Chris Wilson > 2) I just had a full hang of the GPU (black screen) after opening a web > page containing a video. kernel.log contains the following messages: The next kernel also includes the hint to look in /sys/kernel/debug/dri/0/i915_error_state, or at least to provide that file for us for debugging GPU hangs. Outside of initialisation, suspend and resume, and modesetting the cause of a GPU hang is usually an invalid batch buffer submitted by userspace. The i915_error_state should capture that erroneous batch buffer. -Chris -- Chris Wilson, Intel Open Source Technology Centre