linux-kernel - Re: [2.6.36-rc2 regression] X201s: resume-from-S2R hangs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20100908064714.GM23291@hexapodia.org>
Date:	Tue, 7 Sep 2010 23:47:14 -0700
From:	Andy Isaacson <adi@...apodia.org>
To:	Chris Wilson <chris@...is-wilson.co.uk>
Cc:	Eric Anholt <eric@...olt.net>, linux-kernel@...r.kernel.org,
	Zou Nan hai <nanhai.zou@...el.com>
Subject: Re: [2.6.36-rc2 regression] X201s: resume-from-S2R hangs

On Tue, Sep 07, 2010 at 06:37:55PM +0100, Chris Wilson wrote:
> On Tue, 07 Sep 2010 10:12:34 -0700, Eric Anholt <eric@...olt.net> wrote:
> > On Mon, 6 Sep 2010 02:05:36 -0700, Andy Isaacson <adi@...apodia.org> wrote:
> > > I have a Thinkpad X201s on which suspend-to-RAM was quite reliable until
> > > after 2.6.36-rc1; with problematic kernels, suspend seems to work OK
> > > (the machine goes to sleep with the moon LED steadily lit) but on resume
> > > the LCD never lights up (and it's not just the backlight, the screen
> > > isn't drawing at all) and the keyboard and network are dead.  Nothing
> > > makes it to syslog, either.  The moon LED is turned off though.
> > > 
> > > There seems to be some timing component to the problem -- some problem
> > > kernels will suspend reliably 25% or 50% of the time and hang the rest.
> > > There also seems to be some per-reboot state involved; one problem
> > > kernel suspended successfully and survived 25 suspends in a row without
> > > triggering a failure.  (But after a reboot, the first suspend hung...)
> > > Other problem kernels fail on 4 out of 4 reboots.
> 
> We introduced a timing regression which should be fixed by 
> http://cgit.freedesktop.org/~ickle/drm-intel/ drm-intel-fixes
> [http://cgit.freedesktop.org/~ickle/drm-intel/commit/?id=300387c0b57d75e5218e2881d6ad2720657a8bcf]
> 
> > > Bisecting is pretty hard under these conditions, but it seems to point
> > > to
> > 
> > Weird.  That's exactly the hardware that I tested RC6 on, and I haven't
> > seen a single resume failure on mine.

I have BIOS 1.05 (6QET35WW) and the 1440x900 panel, perhaps something is
slightly different?  I suspend by running pm-suspend from an xterm.

> >  Sounds like time to revert for
> > this release.
> 
> At the moment we have a second resume regression that has been difficult to
> reproduce, https://bugs.freedesktop.org/show_bug.cgi?id=29406 :
> 
> commit d1b851fc0d105caa6b6e3e7c92d2987dfb52cbe0
> Author: Zou Nan hai <nanhai.zou@...el.com>
> Date:   Fri May 21 09:08:57 2010 +0800
> 
>     drm/i915: implement BSD ring buffer V2
> 
> The workaround for this is to #define HAS_BSD(dev) 0 [i915_drv.h].
> 
> Andy, can you try the workaround to see if this is the same issue in a
> different guise?
> 
> Alternatively, we can be optimistic that it is just a timing issue fixed
> in drm-intel-next. :)
> 
> Otherwise we will revert that patch. Thanks.

Tried d56557a (which includes 300387c), same hang at resume.

Tried #define HAS_BSD(dev) 0, same hang at resume.

Reverted ce171780 on top of d56557a, resume works great.

-andy
--
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/