Re: 2.6.38-rc8 regressions

[Chris Wilson <chris@chris-wilson.co.uk>]

On Mon, 14 Mar 2011 10:08:12 +0100, Jan Niehusmann <jan@gondor.com> 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 <chris@chris-wilson.co.uk>
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 <chris@chris-wilson.co.uk>

> 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