Date:	Sat, 20 Nov 2010 00:05:42 +0100
From:	Zdenek Kabelac <zdenek.kabelac@...il.com>
To:	Dave Airlie <airlied@...hat.com>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	intel-gfx@...ts.freedesktop.org
Subject: Re: Regressions in resume on intel graphics

2010/11/19 Dave Airlie <airlied@...hat.com>:
> On Fri, 2010-11-19 at 22:35 +0100, Zdenek Kabelac wrote:
>> 2010/11/19 Jesse Barnes <jbarnes@...tuousgeek.org>:
>> > On Fri, 12 Nov 2010 10:17:07 +0100
>> > Zdenek Kabelac <zdenek.kabelac@...il.com> wrote:
>> >
>> >> 2010/11/12 Zdenek Kabelac <zdenek.kabelac@...il.com>:
>> >> > Hi
>> >> >
>> >> > I've noticed that after resume  with 2.6.36 kernel I need to switch
>> >> > between console and back to Xorg to get usable Xsession again.
>> >> > (my hw - T61, gma965, 4GB)
>> >> >
>> >> > I've played bisect game -  and this is the first broken kernel:
>> >> >
>> >> > ---
>> >> > commit 8fd4bd22350784d5b2fe9274f6790ba353976415
>> >> > Author: Jesse Barnes <jbarnes@...tuousgeek.org>
>> >> > Date:   Wed Jun 23 12:56:12 2010 -0700
>> >> >
>> >> >    vt/console: try harder to print output when panicing
>> >> > ---
>> >>
>> >> I've been able to boot and test with 2.6.37-rc1-00170-gf6614b7
>> >> - and this problem seems to be fixed in this version (vt.c file seems
>> >> to be gone?).
>> >
>> > This is really weird; there was one issue Dave tracked down related to
>> > lockdep and the new oops code, but I think it's been fixed.  And it
>> > should manifest as something other than a GPU hang...
>> >
>>
>> Well - unsure - how this worked ok - for 2.6.37-rc1-00170-gf6614b7 (I
>> could try few more times - though this kernel seems to be crashing for
>> various other reasons - so I've had quite few testruns before I've
>> been able to test this in some very limited X environment - so maybe
>> it was just some lucky case - but I still keep it on my disk)
>>
>> Anyway - as an update - I'm now regularly using 2.6.37-rc2 - and it
>> has exactly same problems - as in my original report -  so the problem
>> has not magically disappeared and it is still there.  Is there
>> anything I should try ?
>>
>> Basically every time after resume from suspend I have to switch from X
>> to console and back to get usable screen back. Without this I seen
>> only black screen with mouse over it - is there some way for reverting
>> of this patch - or maybe just disabling some part of it ?
>>
>>
>> To have reliable resume I still have to keep drm_kms_help thread
>> disable - otherwise I observe GPU errors.
>> Switch between consoles is 'relatively' easy to overcome.
>>
>> And another thing which might help -  during suspend/resume  I could
>> usually see weird switch to console with some special text on the
>> whole console screen -
>>
>> [ ###.... ]
>> [ ###.... ]
>>
>> where  '###' is some changing number - and it seems to be different
>> between resumes.
>> Also I should add I'm using  'no-console-suspend'  kernel boot option.
>
> Can you see if e0fdace10e75dac67d906213b780ff1b1a4cc360 reverts cleanly?
> and fixes it?
>
> The problem is I think you are getting a lockdep splat or rcu issue
> before suspending, which sets oops_in_progress and never unsets it,
> which means on resume the fb resume path kicks in to show you the oops
> that is happening when there isn't actually anything to show. I've
> gotten acks to have this reverted I just need to send the patch.
>


Ok - tested  currentl 6656b3fc8aba2eb7ca00c06c7fe4917938b0b652 vanilla kernel
with reverted commit e0fdace10e75da - and it seems Xorg screen after
resume is again properly working.
So this was quick - now the remaining problem -
https://bugzilla.kernel.org/show_bug.cgi?id=19052

Zdenek
--
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