Re: acpi_idle: Very idle Core i7 machine never enters C3

[Len Brown <lenb@kernel.org>]

> >> I am hopeful that the "right thing to do" is to not look at bm-status
> >> and that perhaps there is a bug where we are looking at it
> >> "by mistake".
> > 
> > https://patchwork.kernel.org/patch/58962/ - it seems to be a win.
> 
> Indeed. This patch does solve the C6 problem. I'm not in a position to
> speak about whether there's any undesirable I/O latency, but it
> passes the basic sanity check.
> 
> I have filed https://bugzilla.kernel.org/show_bug.cgi?id=15886 with
> my acpi dump - assuming that's still useful.

Luming's patch above basically deletes acpi_idle_bm_check() --
the BM_STS check -- from the C3 path on all Intel SMP boxes.
This is effectively the same as my test patch
https://patchwork.kernel.org/patch/77370/
that made acpi_idle_bm_check() do nothing.

I'm told by the hardware guys that BM_STS is _not_ always
a NOP, and so we're not supposed to simply ignore it on C3 --
though it should be extremely rare that we see it set.
If it is ever set, it should go on and off depending on 
activity on some latency sensitive device, like out on the LPC.
It may be possible for the BIOS writer to configure the chipset
so that BM_STS is enabled always, presumably to accomodate
some latency sensitve device -- or maybe by mistake.

(is it observed to be set always on your systems, or does
 it ever change its value?)

The logic in Luming's patch doesn't make sense to me.
bm_check and bm_control are related to C3 need to flush
the cache or ability to invoke ARB_DIS.  They are not
directly related to BM_STS -- which is a bit that tells
us if there has recently been bus master activity of
a type that would break us out of C3.

-Len Brown, Intel Open Source Technology Center