> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
