2.6.36-rc3 suspend issue (was: 2.6.35-rc4 / X201 issues)

[Nico Schottelius <nico-linux-20100709@schottelius.org>]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

Good morning LKML,

after some time away from the kernel sources, here my latest report
using Linux on the X201:

  vmlinuz-2.6.36-rc1-00051-g3b89f56
  vmlinuz-2.6.36-rc2-00237-gd4348c6
  vmlinuz-2.6.36-rc3

all come up with a black screen at resume.

I "lost" my last working 2.6.34 kernel, which mostly worked.
On the other hand,

  vmlinuz-2.6.35
  vmlinuz-2.6.35-rc2
  vmlinuz-2.6.35-rc3-00262-g984bc96

do suspend and resume some times, afterwards I see a very slow
refreshing screen, with almost no colours, partly windows
no refresh. Error from xorg at that point (log attached):

[304145.409] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or 
even a frozen display: Input/output error.

Also with 2.6.35* I saw freezes during suspend or during resume.

As I had an xorg update somewhere in between, I'm not sure whether there
are some bits conflicting from both sidse.

I'll go back to 2.6.34 today to see whether I get that one working "stable"

If you need more information, just let me know.

Cheers,

Nico


Jesse Barnes [Fri, Jul 09, 2010 at 10:29:35AM -0700]:
> On Fri, 9 Jul 2010 19:04:32 +0200
> Nico Schottelius <nico-linux-20100709@schottelius.org> wrote:
> 
> > Good evening hackers,
> > 
> > latest report from 2.6.35-rc4 on X201:
> > 
> >   - (almost) everytime I close and reopen the lid, the image is screwed up
> >     - switching to vt1 (away from xorg) and back to vt7 fixes that almost always
> >     - did not happen on 2.6.34 (iirc)
> 
> Can you bisect this issue?
> 
> >   - if it's not screwed up, the system is frozen
> >     - does not react on ping, last image is displayed, no keyboard shortcut works
> >     - ATTENTION: it's *NOT* needed to suspend directly before to get a freeze!
> >       - simplying closing & opening the lid is enough
> 
> Presumably this used to work too, so a bisect might help here as well.
> 
> FWIW mine doesn't behave this way; I have an x201s and it works pretty
> well with current bits (note that a bunch of 2D, Mesa and libdrm fixes
> have landed recently as well).
> 
> -- 
> Jesse Barnes, Intel Open Source Technology Center

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]