Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030542AbbKDQWg (ORCPT ); Wed, 4 Nov 2015 11:22:36 -0500 Received: from mga09.intel.com ([134.134.136.24]:52327 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964932AbbKDQVn (ORCPT ); Wed, 4 Nov 2015 11:21:43 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,243,1444719600"; d="scan'208";a="593964243" Date: Wed, 4 Nov 2015 18:21:00 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: "Brown, Len" Cc: "Wysocki, Rafael J" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] intel_idle: Don't use on Lenovo Ideapad S10-3t Message-ID: <20151104162100.GT4437@intel.com> References: <1446499360-31984-1-git-send-email-ville.syrjala@linux.intel.com> <1A7043D5F58CCB44A599DFD55ED4C9484693D228@fmsmsx115.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1A7043D5F58CCB44A599DFD55ED4C9484693D228@fmsmsx115.amr.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2810 Lines: 87 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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/