linux-kernel - Re: [PATCH] intel_idle: Don't use on Lenovo Ideapad S10-3t

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]

Message-ID: <20151104162100.GT4437@intel.com>
Date:	Wed, 4 Nov 2015 18:21:00 +0200
From:	Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:	"Brown, Len" <len.brown@...el.com>
Cc:	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] intel_idle: Don't use on Lenovo Ideapad S10-3t

On Tue, Nov 03, 2015 at 03:04:21AM +0000, Brown, Len wrote:
> > Lenovo Ideapad S10-3t hangs coming out of S3 with intel_idle.
> > The two workaround that seem to help are "intel_idle.max_cstate=0"
> > or "nohz=off highres=off".
> > 
> > At a first glance quirk_tigerpoint_bm_sts() seemed promising, but
> > even when moved to early_resume it didn't do anything.
> > 
> > I have no idea what's wrong here, so let's just disable intel_idle
> > for these machines using a DMI match.
> 
> Ville, 
> 
> It is great that several workarounds have been discovered.
> 
> But it would be better to get a good idea of the root-cause
> before permanently ignoring the problem via a new
> black-list in the upstream kernel.
> 
> Is it possible for you to file a bug at bugzilla.kernel.org
> against Product: power-management; component: intel_idle?

https://bugzilla.kernel.org/show_bug.cgi?id=107151

> 
> In it, please put the following information.
> 
> If this is a regression, the oldest kernel that broke.

I'll repeat the details here just in case people are too lazy to look at
the bug:

It seems intel_idle has always been flaky with this hardware. It used to
work a little better in the past, but not perfectly.

I tried to bisect the total breakage starting from v3.11, and found the
following commit to be at fault:
commit a8d46b9e4e487301affe84fa53de40b890898604
Author: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
Date:   Tue Sep 30 02:29:01 2014 +0200

    ACPI / sleep: Rework the handling of ACPI GPE wakeup from
    suspend-to-idle

Before that I observed three different behaviours for S3 resume:
a) sometimes it resumed OK
b) sometimes it resumed part way, but kbd/network etc. were still
   dead, but then pressing the power button made it finish the resume
   somehow
c) same as the previous, except the power button press also made it
   all the way to userspace and initiated a normal shutdown
The same kernel could exhibit both a) and b), or both a) and c).

After a8d46b9e4e48 it never resumes, no matter if I press the power
button or not.

> When booted with intel_idle, and then without:
> 
> dmesg | grep idle
> grep . /sys/devices/system/cpu/cpu0/cpuidle/*/*
> # turbostat --debug sleep 10 2> turbostat.out
> 
> # cd /sys/devices/system/clocksource/clocksource0
> grep . available_clocksource current_clocksource
> 
> 
> Other boot options to test:
> 
> maxcpus=1
> nohpet
> 
> intel_idle.max_cstate=3
> and if that fails
> intel_idle.max_cstate=2
> and if that fails
> intel_idle.max_cstate=1

None of these help.

-- 
Ville Syrjälä
Intel OTC
--
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/