intel_idle.max_cstate=1 required on baytrail to prevent crashes

intel_idle.max_cstate=1 required on baytrail to prevent crashes

[Michal Feix]

Hello everyone,

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.

Could someone here please confirm if this is in or out of anyone's
current focus? I strongly believe this is not a minority issue and maybe
this just slipped through meny other important bug reports.

Thank you,

--
Michael

Re: intel_idle.max_cstate=1 required on baytrail to prevent crashes

[Rafael J. Wysocki]

On Thursday, March 17, 2016 08:05:25 AM Michal Feix wrote:
> Hello everyone,

Hi,

> 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.
> 
> Could someone here please confirm if this is in or out of anyone's
> current focus? I strongly believe this is not a minority issue and maybe
> this just slipped through meny other important bug reports.

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?

Thanks,
Rafael

Re: intel_idle.max_cstate=1 required on baytrail to prevent crashes

[Michal Feix]

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

Re: intel_idle.max_cstate=1 required on baytrail to prevent crashes

[Rafael J. Wysocki]

On Fri, Mar 18, 2016 at 9:32 PM, Michal Feix <michal@feix.cz> wrote:
>>> 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..

This is not an intel_idle problem in any case.  If anything, there
might be a way to work around it in that driver.