Re: Regression, host crash with 4.5rc1

[Steve Freitas <sflist@ihonk.com>]

On 11/27/2014 01:27 AM, Jan Beulich wrote:
> This was precisely the reason why I told you that the numbering
> differs (and is confusing and has nothing to do with actual C state
> numbers): What max_cstate refers to in the mwait-idle driver is
> what above is listed as type[Cx], i.e. the state at index 1 is C1, at
> 2 we've got C1E, and at 3 we've got C2. And those still aren't in
> line with the numbering the CPU documentation uses, it's rather
> kind of meant to refer to the ACPI numbering (but probably also
> not fully matching up).

Ah, thanks for the explanation.

> So max_cstate=2 working suggests a problem with what the CPU
> calls C6, which presumably isn't all that surprising considering the
> many errata (BD35, BD38, BD40, BD59, BD87, and BD104). Not
> sure how to proceed from here - I suppose you already made
> sure you run with the latest available BIOS.

Yes, latest available BIOS.

> And with 6 errata
> documented it's not all that unlikely that there's a 7th one with
> MONITOR/MWAIT behavior. The commit you bisected to (and
> which you had verified to be the culprit by just forcing
> arch_skip_send_event_check() to always return false) could be
> reasonably assumed to be broken only when MWAIT use for all
> C states didn't work.

Now I did get a hang with max_cstate=3 and mwait-idle=0. May I assume 
that mwait-idle=0 means that ACPI is responsible for the throttling?

Thanks again for all your help!

Steve