Bug 15886

Patch available.
ping Len...

Created attachment 26539 [details]
lspci from HP DL360G6

Created attachment 26540 [details]
acpidump from HP dl360g6

This machine sets the BM_STS flag several times a second. I've unloaded all drivers except for storage and see the same behaviour.

Created attachment 27187 [details]
patch vs 2.6.35-rc5

Please give this patch a try.
You should notice that in /proc/acpi/processor/*/power
that the C3 type C-states are now C2-type.
As such, BM_STS will not be checked on entry
and deep c-states will be used even if the chipset reports BM_STS.

According to "Intel Processor Vendor-Specific ACPI Interface Specification":
http://download.intel.com/technology/IAPC/acpi/downloads/30222305.pdf

table 4 "_CST FFH GAS Field Encoding"

Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-state

This means that Linux should not be checking BM_STS on these states
unless this bit is set.  However, Linux is always checking BM_STS
for C3-type states.

The Good news is that according to Philip's acpidump for the
failing gigabyte motherboard in the original description above,
Gigabyte does not set this bit in _CST.GAS -- only bit 0
is set in access size, which indicates HW coordiation:


            If (CondRefOf (\_OSI, Local0))
            {
                If (LAnd (\_OSI ("Windows 2001.1"), LAnd (LNot (\_OSI ("Windows 2006")), LNot (\_OSI (
                    "Windows 2001.1 SP1")))))
                {
                    Store (0x00, CSEN)
                }
            }

            If (CSEN)
            {
                If (LAnd (MWOS, And (TYPE, 0x0200)))
                {
                    Return (Package (0x04)
                    {
                        0x03,
                        Package (0x04)
                        {
                            ResourceTemplate ()
                            {
                                Register (FFixedHW,
                                    0x01,               // Bit Width
                                    0x02,               // Bit Offset
                                    0x0000000000000000, // Address
                                    0x01,               // Access Size
                                    )
                            },

                            0x01,
                            0x0001,
                            0x000003E8
                        },

                        Package (0x04)
                        {
                            ResourceTemplate ()
                            {
                                Register (FFixedHW,
                                    0x01,               // Bit Width
                                    0x02,               // Bit Offset
                                    0x0000000000000010, // Address
                                    0x01,               // Access Size
                                    )
                            },

                            0x02,
                            0x0040,
                            0x000001F4
                        },

                        Package (0x04)
                        {
                            ResourceTemplate ()
                            {
                                Register (FFixedHW,
                                    0x01,               // Bit Width
                                    0x02,               // Bit Offset
                                    0x0000000000000020, // Address
                                    0x01,               // Access Size
                                    )
                            },

                            0x03,
                            0x0060,
                            0x0000015E
                        }
                    })

The Bad news is that according to the acpidump in comment #3,
HP is asking for BM_STS checking on the DL360G6
via access size 3 for C2 and C3:


       Method (_CST, 0, NotSerialized)
        {
            If (CSEN)
            {
                If (LAnd (MWOS, And (TYPE, 0x0200)))
                {
                    Return (Package (0x04)
                    {
                        0x03,
                        Package (0x04)
                        {
                            ResourceTemplate ()
                            {
                                Register (FFixedHW,
                                    0x01,               // Bit Width
                                    0x02,               // Bit Offset
                                    0x0000000000000000, // Address
                                    0x01,               // Access Size
                                    )
                            },

                            0x01,
                            0x0001,
                            0x000003E8
                        },

                        Package (0x04)
                        {
                            ResourceTemplate ()
                            {
                                Register (FFixedHW,
                                    0x01,               // Bit Width
                                    0x02,               // Bit Offset
                                    0x0000000000000010, // Address
                                    0x03,               // Access Size
                                    )
                            },

                            0x03,
                            0x0040,
                            0x000001F4
                        },

                        Package (0x04)
                        {
                            ResourceTemplate ()
                            {
                                Register (FFixedHW,
                                    0x01,               // Bit Width
                                    0x02,               // Bit Offset
                                    0x0000000000000020, // Address
                                    0x03,               // Access Size
                                    )
                            },

                            0x03,
                            0x0060,
                            0x0000015E
                        }
                    })
                }

So if we fix Linux to check this bit, the Gigabyte will be fixed,
but the HP appears to be explicitly asking us to check BM_STS.
Unclear if that is HP's intention or if it is a BIOS bug.

Seems to be working fine on the Gigabyte board.

I never understood the meaning of this bit.

table 4 "_CST FFH GAS Field Encoding"
Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-state

Does it mean OS should check BM_STS or does it mean OS OS should do ARB_DIS to avoid BM activity before entering this C-state?

I always felt that its the second one. But, never saw any BIOS having this bit set..

Created attachment 27211 [details]
acpidump from HP DL380G6

The BWG says:

if a device can't tolerate the latency then...
"report this C-state with the BM_STS avoidance bit set".

I thought they were referring to enabling BM_STS in the chipset.
I didn't realize that they were referring to FFH.GAS.access_size.

So I think our policy should be for FADT and _CST IOspace C3,
to continue checking BM_STS.

For _CST FFH Intel C3, check BM_STS only if this bit is set.

Created attachment 27212 [details]
patch vs 2.6.35-rc6 to disable BM_STS checking via ACPI _CST.FFH flag

Philip,
Please test this one.
It should solve the problem on your gigabyte.

The HP DL360G6 will be tougher, as the BIOS is asking us to check BM_STS...

Created attachment 27213 [details]
patch vs 2.6.35-rc6 to add "processor.bm_check_disable1=1"

Matthew, Iain,

Please boot your HP DL3690 G6 with "processor.bm_check_disable1=1"
and verify with turbostat that you can get into deep c-states.

Len,

Latest patch works great.

Thanks!

Created attachment 27216 [details]
DL360G6 acpidump, powertop & turbostat logs

bios date and power regulator settings on the end of the filenames

Iain,
Turbostat output shows that BIOS 07-24-2010 does not enter c3, pc3, pc6
and BIOS 05-15-2010 enters all of them.

This is independent of the "balanced" vs "oscontrol" BIOS setting.

So it appears that while the older BIOS didn't work well,
the newer BIOS is working fine.

Looking at the AML, the newer BIOS has Access Size 1 on _CST
no matter if balanced or oscontrol.
The older BIOS has Access Size 3 on C3-type _CST's.
Again, independent of "balanced" vs "oscontrol".
Of course you are running a kernel that doesn't look at _CST.GAS.Access Width,
so apparently the new BIOS is programming the chip-set to not assert BM_STS...

In summary, you have no problem with the new BIOS
and the lack of package c-states appears to be a problem associated
only w/ the old BIOS, yes?

patch in comment #11 shipped upstream after linux-2.6.35-rc6-git1

and has been sent to stable@kernel.org for 2.6.32.y, 2.6.33.y, 2.6.34.y

commit 718be4aaf3613cf7c2d097f925abc3d3553c0605
Author: Len Brown <len.brown@intel.com>
Date:   Thu Jul 22 16:54:27 2010 -0400

    ACPI: skip checking BM_STS if the BIOS doesn't ask for it

It appears that the problem with the HP DL380G6
occurs only with an old BIOS, and so that doesn't seem
to justify any modification to Linux.

closed.