Why is max_cstate=1 still needed?

Why is max_cstate=1 still needed?

[Jiri Slaby]

Hello,

there are still reports against the latest kernels, that people need to
pass processor/intel_idle.max_cstate=1 to successfully boot the kernel.
The symptoms are always the same, until the parameter is specified OR
until the user presses a key, the system won't boot up.

This started to appear between 2.6.31 and 2.6.34 (possibly a 2.6.33
regression) and continues to be reported against the latest stable
2.6.37.3. For example:
https://bugzilla.kernel.org/show_bug.cgi?id=15289
https://bugzilla.novell.com/show_bug.cgi?id=579932
https://bugzilla.novell.com/show_bug.cgi?id=673589
https://bugzilla.novell.com/show_bug.cgi?id=675161

I see that there were some fixes in .38-rc in this bug report (they look
unrelated):
https://bugzilla.kernel.org/show_bug.cgi?id=29992

Should they give .38-rc a try?

Any help would be appreciated.

thanks,
-- 
js
suse labs

Why is max_cstate=1 still needed?

[Jiri Slaby]

Hello,

there are still reports against the latest kernels, that people need to
pass processor/intel_idle.max_cstate=1 to successfully boot the kernel.
The symptoms are always the same, until the parameter is specified OR
until the user presses a key, the system won't boot up.

This started to appear between 2.6.31 and 2.6.34 (possibly a 2.6.33
regression) and continues to be reported against the latest stable
2.6.37.3. For example:
https://bugzilla.kernel.org/show_bug.cgi?id=15289
https://bugzilla.novell.com/show_bug.cgi?id=579932
https://bugzilla.novell.com/show_bug.cgi?id=673589
https://bugzilla.novell.com/show_bug.cgi?id=675161

I see that there were some fixes in .38-rc in this bug report (they look
unrelated):
https://bugzilla.kernel.org/show_bug.cgi?id=29992

Should they give .38-rc a try?

Any help would be appreciated.

thanks,
-- 
js
suse labs

Re: Why is max_cstate=1 still needed?

[Thomas Gleixner]

On Fri, 11 Mar 2011, Jiri Slaby wrote:
> there are still reports against the latest kernels, that people need to
> pass processor/intel_idle.max_cstate=1 to successfully boot the kernel.
> The symptoms are always the same, until the parameter is specified OR
> until the user presses a key, the system won't boot up.
> 
> This started to appear between 2.6.31 and 2.6.34 (possibly a 2.6.33
> regression) and continues to be reported against the latest stable
> 2.6.37.3. For example:
> https://bugzilla.kernel.org/show_bug.cgi?id=15289
> https://bugzilla.novell.com/show_bug.cgi?id=579932
> https://bugzilla.novell.com/show_bug.cgi?id=673589
> https://bugzilla.novell.com/show_bug.cgi?id=675161
> 
> I see that there were some fixes in .38-rc in this bug report (they look
> unrelated):
> https://bugzilla.kernel.org/show_bug.cgi?id=29992
> 
> Should they give .38-rc a try?

Trying does no damage :(
 
> Any help would be appreciated.

I went through the bug reports briefly. While they all report the same
symptoms (hangs until key pressed) the root cause varies.

   - SMM C1E handler broken (affects AMD only)
   - HPET issues (mostly AMD)
   - The usual ACPI/BIOS madness

On most of those systems nohz=off hides the problem as well as it
prevents deeper power states, so the local apic timer just keeps
ticking and the broadcast via PIT/HPET is not activated. hpet=disable
is another way to work around it.

To be honest we have no real handle on all of this as much of the
wreckage is hidden deep in that black hole of ACPI/BIOS. We grew some
quirks and detection mechanisms over time, but there seems to be a
never ending source of trouble especially as HW vendors seem to add
more power related features into the BIOS. We've seen perf wreckage as
well as some of those abuse performance counters :(

Of course those "features" are only tested against that other OS, some
of them even require a driver counterpart for the other OS. Of course
we have no information about that at all and the HW vendors are
helpful as ever.

Yes, it's sad, but reality.

Thanks,

	tglx

Re: Why is max_cstate=1 still needed?

[Thomas Gleixner]

On Fri, 11 Mar 2011, Jiri Slaby wrote:
> there are still reports against the latest kernels, that people need to
> pass processor/intel_idle.max_cstate=1 to successfully boot the kernel.
> The symptoms are always the same, until the parameter is specified OR
> until the user presses a key, the system won't boot up.
> 
> This started to appear between 2.6.31 and 2.6.34 (possibly a 2.6.33
> regression) and continues to be reported against the latest stable
> 2.6.37.3. For example:
> https://bugzilla.kernel.org/show_bug.cgi?id=15289
> https://bugzilla.novell.com/show_bug.cgi?id=579932
> https://bugzilla.novell.com/show_bug.cgi?id=673589
> https://bugzilla.novell.com/show_bug.cgi?id=675161
> 
> I see that there were some fixes in .38-rc in this bug report (they look
> unrelated):
> https://bugzilla.kernel.org/show_bug.cgi?id=29992
> 
> Should they give .38-rc a try?

Trying does no damage :(
 
> Any help would be appreciated.

I went through the bug reports briefly. While they all report the same
symptoms (hangs until key pressed) the root cause varies.

   - SMM C1E handler broken (affects AMD only)
   - HPET issues (mostly AMD)
   - The usual ACPI/BIOS madness

On most of those systems nohz=off hides the problem as well as it
prevents deeper power states, so the local apic timer just keeps
ticking and the broadcast via PIT/HPET is not activated. hpet=disable
is another way to work around it.

To be honest we have no real handle on all of this as much of the
wreckage is hidden deep in that black hole of ACPI/BIOS. We grew some
quirks and detection mechanisms over time, but there seems to be a
never ending source of trouble especially as HW vendors seem to add
more power related features into the BIOS. We've seen perf wreckage as
well as some of those abuse performance counters :(

Of course those "features" are only tested against that other OS, some
of them even require a driver counterpart for the other OS. Of course
we have no information about that at all and the HW vendors are
helpful as ever.

Yes, it's sad, but reality.

Thanks,

	tglx