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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 8 Sep 2010 09:00:46 +0800
From:	"Zou, Nanhai" <nanhai.zou@...el.com>
To:	Chris Wilson <chris@...is-wilson.co.uk>,
	Eric Anholt <eric@...olt.net>,
	Andy Isaacson <adi@...apodia.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	"He, Shuang" <shuang.he@...el.com>
Subject: RE: [2.6.36-rc2 regression] X201s: resume-from-S2R hangs

We've had tried every kind of G45 and G45M machines here for many times, 
But can not reproduce #29406, 
We will see if we can reproduce this issue on X201

Thanks
Zou Nan hai

-----Original Message-----
From: Chris Wilson [mailto:chris@...is-wilson.co.uk] 
Sent: 2010年9月8日 1:38
To: Eric Anholt; Andy Isaacson; linux-kernel@...r.kernel.org
Cc: Zou, Nanhai
Subject: Re: [2.6.36-rc2 regression] X201s: resume-from-S2R hangs

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.  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.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ