From: Michal Feix <michal@feix.cz>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: linux-pm@vger.kernel.org, Len Brown <len.brown@intel.com>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Chen Yu <yu.c.chen@intel.com>
Subject: Re: intel_idle.max_cstate=1 required on baytrail to prevent crashes
Date: Fri, 18 Mar 2016 21:32:26 +0100 [thread overview]
Message-ID: <56EC65DA.2030701@feix.cz> (raw)
In-Reply-To: <3870417.33uAD9HvER@vostro.rjw.lan>
>> for the past few months, I'm fighting random hard lock-ups on my
>> Baytrail machine with different linux kernels. Freezes are quite
>> frequent, between few minutes to few hours of uptime. According to other
>> reporters, this was pinpointed as an intel_idle problem on Baytrail. The
>> bug report originally started as i915 regression at
>> https://bugs.freedesktop.org/show_bug.cgi?id=88012 and was moved to
>> kernel Bugzilla few months ago -
>> https://bugzilla.kernel.org/show_bug.cgi?id=109051
>>
>> This bug seems to be a serious showstopper for Baytrail users and was
>> already confirmed by many, but there is no obvious progress on this bug
>> report for last few months. Meny reporters have confirmed
>> intel_idle.max_cstate=1 or intel_idle.max_cstate=2 as a half-working
>> workaround, which makes the interval between freezes on Baytrail longer.
> No, it hasn't, but it turns out difficult to root-cause.
>
> Tell me one thing: does disabling intel_idle entirely on the affected systems
> make the problem go away?
>
> That is, does intel_idle.max_cstate=0 in the kernel command line help?
>
> Or does idle=nomwait in the kernel command line help?
intel_idle.max_cstate=1 - no hard-lockups
intel_idle.max_cstate=0 - no hard-lockups
idle=nomwait - with hard-lockups
Someone on Bugzilla suggested to try latest 4.5 kernel, as he believes
it's fixed already on his BYT laptop. I'm running on the longterm branch
so I just upgraded to 4.1.19 LTS which is the latest in Arch distro for
the moment. And yes - my uptime is 4 hours and still counting! :-) I'll
see during next few days but maybe it's fixed.
intel_idle would then be probably out of suspision, as it haven't been
touched for last few months..
Michael
next prev parent reply other threads:[~2016-03-18 20:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-17 7:05 intel_idle.max_cstate=1 required on baytrail to prevent crashes Michal Feix
2016-03-17 14:18 ` Rafael J. Wysocki
2016-03-18 20:32 ` Michal Feix [this message]
2016-03-18 21:17 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56EC65DA.2030701@feix.cz \
--to=michal@feix.cz \
--cc=len.brown@intel.com \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=yu.c.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.