Core i7 & C-States

Core i7 & C-States

[Greg Oliver]

[-- Attachment #1: Type: text/plain, Size: 11587 bytes --]

Hi,

This is my first motherboard with ACPI issues, so I am in uncharted
water. It is an intel board, so no overclocking, etc.  Reading through
as much as I can this morning, I have hit the wall.  I have
disassembled all of my [DS]SDTs, and will attach them with a dmesg as
this seems to be the normal request from the archives.

About the issue though -

If I enable either/or C-STATES/C2-STATES, the system will freeze on
boot.  Disabling them both the system runs fine, but I would obviously
like the power savings if possible.  Now I know this BIOS has some
issues as some PCI devices (when disabled in the BIOS) still get
partially enumerated and assigned IRQs on the bus as well, but that
does not concern me as much as the power.  The latest update to the
BIOS from intel is installed.

This is the only ACPI error I get from dmesg currently though:

ACPI Warning: Incorrect checksum in table [SSDT] - 3F, should be 91
(20090903/tbutils-314)

I have also booted with "acpi.debug_layer=0xFFFFFFFF
acpi.debug_level=0x80000000" appended to my kernel cmdline and I am
unsure why, but even though the system showed all debugs enabled in
/sys, I did not receive any extra debug messages in dmesg!?!?

Thanks for any insight!

-Greg

Info follows:
pmtools-20071116/acpixtract/acpixtract -l acpidump.acpi

Signature Length  OemId     OemTableId   OemRevision CompilerId CompilerRevision

    DSDT   27404  "INTEL "  "DH55TC  "    00000000    "INTL"     20051117
    FACS      64
    FACP     244  "INTEL "  "DH55TC  "    01072009    "MSFT"     00010013
    APIC     204  "INTEL "  "DH55TC  "    01072009    "MSFT"     00010013
    SSDT     470  "INTEL "  "DH55TC  "    00000001    "MSFT"     03000001
    MCFG      60  "INTEL "  "DH55TC  "    01072009    "MSFT"     00000097
    HPET      56  "INTEL "  "DH55TC  "    01072009    "AMI."     00000003
    ASF!     160  "INTEL "  "DH55TC  "    00000001    "TFSM"     000F4240
    DMAR     104  "INTEL "  "DH55TC  "    00000001    "INTL"     00000001
    XSDT      92  "INTEL "  "DH55TC  "    01072009    "MSFT"     00010013
    FACS      64
    FACP     132  "INTEL "  "DH55TC  "    01072009    "MSFT"     00010013
    RSDT      64  "INTEL "  "DH55TC  "    01072009    "MSFT"     00010013
    RSDP          "INTEL "

Found 14 ACPI tables [20060324]

dmidecode (cpu portion):

SMBIOS 2.6 present.
79 structures occupying 3163 bytes.
Table at 0x000EAF70.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: Intel Corp.
	Version: TCIBX10H.86A.0040.2010.1018.1100
	Release Date: 10/18/2010
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 1024 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported

Handle 0x0004, DMI type 4, 42 bytes
Processor Information
	Socket Designation: XU1
	Type: Central Processor
	Family: Core i7
	Manufacturer: Intel
	ID: E5 06 01 00 FF FB EB BF
	Version: Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz
	Voltage: 0.0 V
	External Clock: 533 MHz
	Max Speed: 2926 MHz
	Current Speed: 2793 MHz
	Status: Populated, Enabled
	Upgrade: Other
	L1 Cache Handle: 0x0005
	L2 Cache Handle: 0x0006
	L3 Cache Handle: 0x0007
	Serial Number: To Be Filled By O.E.M.
	Asset Tag: To Be Filled By O.E.M.
	Part Number: To Be Filled By O.E.M.
	Core Count: 4
	Core Enabled: 1
	Thread Count: 2
	Characteristics:
		64-bit capable

Handle 0x0005, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L1-Cache
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 128 kB
	Maximum Size: 128 kB
	Supported SRAM Types:
		Other
	Installed SRAM Type: Other
	Speed: Unknown
	Error Correction Type: None
	System Type: Unified
	Associativity: 4-way Set-associative

Handle 0x0006, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L2-Cache
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Varies With Memory Address
	Location: Internal
	Installed Size: 1024 kB
	Maximum Size: 1024 kB
	Supported SRAM Types:
		Other
	Installed SRAM Type: Other
	Speed: Unknown
	Error Correction Type: None
	System Type: Instruction
	Associativity: 8-way Set-associative

Handle 0x0007, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L3-Cache
	Configuration: Enabled, Not Socketed, Level 3
	Operational Mode: Unknown
	Location: Internal
	Installed Size: 8192 kB
	Maximum Size: 8192 kB
	Supported SRAM Types:
		Other
	Installed SRAM Type: Other
	Speed: Unknown
	Error Correction Type: None
	System Type: Instruction
	Associativity: 16-way Set-associative

cpuinfo:
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 30
model name	: Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz
stepping	: 5
cpu MHz		: 2793.450
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3
cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi
flexpriority ept vpid
bogomips	: 5586.90
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 30
model name	: Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz
stepping	: 5
cpu MHz		: 2793.450
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 0
cpu cores	: 4
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3
cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi
flexpriority ept vpid
bogomips	: 5585.01
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 2
vendor_id	: GenuineIntel
cpu family	: 6
model		: 30
model name	: Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz
stepping	: 5
cpu MHz		: 2793.450
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 1
cpu cores	: 4
apicid		: 2
initial apicid	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3
cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi
flexpriority ept vpid
bogomips	: 5585.03
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 30
model name	: Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz
stepping	: 5
cpu MHz		: 2793.450
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 1
cpu cores	: 4
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3
cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi
flexpriority ept vpid
bogomips	: 5585.02
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 4
vendor_id	: GenuineIntel
cpu family	: 6
model		: 30
model name	: Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz
stepping	: 5
cpu MHz		: 2793.450
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 2
cpu cores	: 4
apicid		: 4
initial apicid	: 4
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3
cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi
flexpriority ept vpid
bogomips	: 5585.03
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 5
vendor_id	: GenuineIntel
cpu family	: 6
model		: 30
model name	: Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz
stepping	: 5
cpu MHz		: 2793.450
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 2
cpu cores	: 4
apicid		: 5
initial apicid	: 5
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3
cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi
flexpriority ept vpid
bogomips	: 5585.02
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 6
vendor_id	: GenuineIntel
cpu family	: 6
model		: 30
model name	: Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz
stepping	: 5
cpu MHz		: 2793.450
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 3
cpu cores	: 4
apicid		: 6
initial apicid	: 6
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3
cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi
flexpriority ept vpid
bogomips	: 5585.03
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 7
vendor_id	: GenuineIntel
cpu family	: 6
model		: 30
model name	: Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz
stepping	: 5
cpu MHz		: 2793.450
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 3
cpu cores	: 4
apicid		: 7
initial apicid	: 7
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3
cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi
flexpriority ept vpid
bogomips	: 5585.02
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

[-- Attachment #2: 20101117-acpi_dasm_dumps.tbz2 --]
[-- Type: application/x-bzip-compressed-tar, Size: 33455 bytes --]

Re: Core i7 & C-States

[Thomas Renninger]

On Wednesday 17 November 2010 09:34:43 pm Greg Oliver wrote:
> Hi,
> 
> This is my first motherboard with ACPI issues, so I am in uncharted
> water. It is an intel board, so no overclocking, etc.  Reading through
> as much as I can this morning, I have hit the wall.  I have
> disassembled all of my [DS]SDTs, and will attach them with a dmesg as
> this seems to be the normal request from the archives.
> 
> About the issue though -
> 
> If I enable either/or C-STATES/C2-STATES,
How do you enable them? I expect you disable them (disabling these
does vary depending whether intel_idle or acpi_idle is used, see below)?
> the system will freeze on 
> boot.  Disabling them both the system runs fine, but I would obviously
> like the power savings if possible.  Now I know this BIOS has some
> issues as some PCI devices (when disabled in the BIOS) still get
> partially enumerated and assigned IRQs on the bus as well, but that
> does not concern me as much as the power.  The latest update to the
> BIOS from intel is installed.
Interesting.
Which kernel are you running?
With latest kernel intel_idle should be used for C-states on such
a new CPU and it will totally
ignore ACPI C-state information. If it works, it's due to ACPI tables.
You can check here:
cat /sys/devices/system/cpu/cpuidle/current_driver
That should show acpi_idle if processor.ko driver is used and ACPI
tables are used or intel_idle.

> This is the only ACPI error I get from dmesg currently though:
> 
> ACPI Warning: Incorrect checksum in table [SSDT] - 3F, should be 91
> (20090903/tbutils-314)
Probably irrelvant to C-states.
> 
> I have also booted with "acpi.debug_layer=0xFFFFFFFF
> acpi.debug_level=0x80000000" appended to my kernel cmdline and I am
> unsure why, but even though the system showed all debugs enabled in
> /sys, I did not receive any extra debug messages in dmesg!?!?
For C-states this debug facility does not help much.

If intel_idle also freezes the machine, you should open a bug on
bugzilla.kernel.org, please add me and Len Brown to CC then.

     Thomas

Re: Core i7 & C-States

[Thomas Renninger]

Hi,

I add linux-acpi again, this is some nice info already...

On Saturday 20 November 2010 03:21:58 am Greg Oliver wrote:
> On Thu, Nov 18, 2010 at 6:59 PM, Thomas Renninger <trenn@suse.de> wrote:
> > On Wednesday 17 November 2010 09:34:43 pm Greg Oliver wrote:
> >> Hi,
> >>
> >> This is my first motherboard with ACPI issues, so I am in uncharted
> >> water. It is an intel board, so no overclocking, etc.  Reading through
> >> as much as I can this morning, I have hit the wall.  I have
> >> disassembled all of my [DS]SDTs, and will attach them with a dmesg as
> >> this seems to be the normal request from the archives.
> >>
> >> About the issue though -
> >>
> >> If I enable either/or C-STATES/C2-STATES,
> > How do you enable them? I expect you disable them (disabling these
> > does vary depending whether intel_idle or acpi_idle is used, see below)?
> 
> I disable them in the bios.  I do not know the kernel syntax to do it
> on boot since I did not know it existed, but I'll go find it.
I wonder whether the BIOS disabling also works with intel_idle driver (and
some MSRs are set) or whether intel_idle will still do C-states, because
only ACPI C-state entries not exposed. I expect the latter...

intel_idle driver is not used with your kernel, though, see below.

> >> the system will freeze on
> >> boot.  Disabling them both the system runs fine, but I would obviously
> >> like the power savings if possible.  Now I know this BIOS has some
> >> issues as some PCI devices (when disabled in the BIOS) still get
> >> partially enumerated and assigned IRQs on the bus as well, but that
> >> does not concern me as much as the power.  The latest update to the
> >> BIOS from intel is installed.
> > Interesting.
> > Which kernel are you running?
> 
> 2.6.32 stable
Ok, there acpi_idle should still be used and this one should take your
BIOS settings into account properly.

> > With latest kernel intel_idle should be used for C-states on such
> > a new CPU and it will totally
> > ignore ACPI C-state information. If it works, it's due to ACPI tables.
> > You can check here:
> > cat /sys/devices/system/cpu/cpuidle/current_driver
> > That should show acpi_idle if processor.ko driver is used and ACPI
> > tables are used or intel_idle.
> 
> acpi_idle is what shows
Yep.

> >> This is the only ACPI error I get from dmesg currently though:
> >>
> >> ACPI Warning: Incorrect checksum in table [SSDT] - 3F, should be 91
> >> (20090903/tbutils-314)
> > Probably irrelvant to C-states.
> 
> I guess I skimmed past these by accident:
> 
>     0.000000] ACPI Warning: 32/64 FACS address mismatch in FADT - two
> FACS tables! (20090903/tbfadt-369)
> [    0.000000] ACPI Warning: 32/64X FACS address mismatch in FADT -
> BBE19F40/00000000BBE19E40, using 32 (20090903/tbfadt-486)
This looks sever and chances are high that this is the reason for the
system freezes at boot up.
I could imagine the problem is that acpica/Linux behaves like old
Windowses (prior Windows Vista) and preferes 32-bit fadt addresses.
I opened a bug for that some time ago:
http://acpica.org/bugzilla/show_bug.cgi?id=885

> >> I have also booted with "acpi.debug_layer=0xFFFFFFFF
> >> acpi.debug_level=0x80000000" appended to my kernel cmdline and I am
> >> unsure why, but even though the system showed all debugs enabled in
> >> /sys, I did not receive any extra debug messages in dmesg!?!?
> > For C-states this debug facility does not help much.
> 
> Yeah, I was just surprised that it did not add any more verbosity to
> my boot at all..
> 
> > If intel_idle also freezes the machine, you should open a bug on
> > bugzilla.kernel.org, please add me and Len Brown to CC then.
> 
> Thanks for the pointer - I did not know the alternatives were out
> there.  I'll patch it in and rebuild the kernel to see how it goes.
But first above problem (FACS address mismatch) should be addressed.
Chances are high that the machine does not freeze anymore then.
Best is you open a bug here:
http://bugzilla.kernel.org
assign it to the ACPI component and attach acpidump output and at least
past above error message in there. A short description that the machine
freezes at boot (and disabling C-states in BIOS helps?) and the used
kernel should also show up there.

    Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Core i7 & C-States

[Koornstra, Reinoud]

> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Thomas Renninger
> Sent: Sunday, November 21, 2010 8:47 AM
> To: Greg Oliver
> Cc: linux-acpi@vger.kernel.org; Len Brown; Moore, Robert
> Subject: Re: Core i7 & C-States
> 
> Hi,
> 
> I add linux-acpi again, this is some nice info already...
> 
> On Saturday 20 November 2010 03:21:58 am Greg Oliver wrote:
> > On Thu, Nov 18, 2010 at 6:59 PM, Thomas Renninger <trenn@suse.de>
> wrote:
> > > On Wednesday 17 November 2010 09:34:43 pm Greg Oliver wrote:
> > >> Hi,
> > >>
> > >> This is my first motherboard with ACPI issues, so I am in
> uncharted
> > >> water. It is an intel board, so no overclocking, etc.  Reading
> through
> > >> as much as I can this morning, I have hit the wall.  I have
> > >> disassembled all of my [DS]SDTs, and will attach them with a dmesg
> as
> > >> this seems to be the normal request from the archives.
> > >>
> > >> About the issue though -
> > >>
> > >> If I enable either/or C-STATES/C2-STATES,
> > > How do you enable them? I expect you disable them (disabling these
> > > does vary depending whether intel_idle or acpi_idle is used, see
> below)?
> >
> > I disable them in the bios.  I do not know the kernel syntax to do it
> > on boot since I did not know it existed, but I'll go find it.
> I wonder whether the BIOS disabling also works with intel_idle driver
> (and
> some MSRs are set) or whether intel_idle will still do C-states,
> because
> only ACPI C-state entries not exposed. I expect the latter...
> 
> intel_idle driver is not used with your kernel, though, see below.
> 
> > >> the system will freeze on
> > >> boot.  Disabling them both the system runs fine, but I would
> obviously
> > >> like the power savings if possible.  Now I know this BIOS has some
> > >> issues as some PCI devices (when disabled in the BIOS) still get
> > >> partially enumerated and assigned IRQs on the bus as well, but
> that
> > >> does not concern me as much as the power.  The latest update to
> the
> > >> BIOS from intel is installed.
> > > Interesting.
> > > Which kernel are you running?
> >
> > 2.6.32 stable
> Ok, there acpi_idle should still be used and this one should take your
> BIOS settings into account properly.
> 
> > > With latest kernel intel_idle should be used for C-states on such
> > > a new CPU and it will totally
> > > ignore ACPI C-state information. If it works, it's due to ACPI
> tables.
> > > You can check here:
> > > cat /sys/devices/system/cpu/cpuidle/current_driver
> > > That should show acpi_idle if processor.ko driver is used and ACPI
> > > tables are used or intel_idle.
> >
> > acpi_idle is what shows
> Yep.
> 
> > >> This is the only ACPI error I get from dmesg currently though:
> > >>
> > >> ACPI Warning: Incorrect checksum in table [SSDT] - 3F, should be
> 91
> > >> (20090903/tbutils-314)
> > > Probably irrelvant to C-states.
> >
> > I guess I skimmed past these by accident:
> >
> >     0.000000] ACPI Warning: 32/64 FACS address mismatch in FADT - two
> > FACS tables! (20090903/tbfadt-369)
> > [    0.000000] ACPI Warning: 32/64X FACS address mismatch in FADT -
> > BBE19F40/00000000BBE19E40, using 32 (20090903/tbfadt-486)
> This looks sever and chances are high that this is the reason for the
> system freezes at boot up.
> I could imagine the problem is that acpica/Linux behaves like old
> Windowses (prior Windows Vista) and preferes 32-bit fadt addresses.
> I opened a bug for that some time ago:
> http://acpica.org/bugzilla/show_bug.cgi?id=885

The acpi 4.0 standard requires that either a 32 bits address is used and that then the 64 bits address should be 0. (not used)
Or that when the 64 bits address is used then the 32 bits address isn't used and should be 0.
Some biosses actually use both the 32 bits and 64 bits addresses, but the 64 bits address is the same as the 32 bits address, this is not as it's supposed to be, but linux can deal with this. Some biosses, do use different addresses for the 32 bits address and 64 bits addresses which isn't good at all.
In this case linux doesn't know which one to use and by default it'll use the 32 bits table. In this case we actually have 2 fadt tables a 32 bits one and a 64 bits one.
Bios vendors might do this to support windows 2000.
 
> > >> I have also booted with "acpi.debug_layer=0xFFFFFFFF
> > >> acpi.debug_level=0x80000000" appended to my kernel cmdline and I
> am
> > >> unsure why, but even though the system showed all debugs enabled
> in
> > >> /sys, I did not receive any extra debug messages in dmesg!?!?
> > > For C-states this debug facility does not help much.

In order for acpi.debug parameters to work you need to recompile the kernel with CONFIG_ACPI_DEBUG=y

> >
> > Yeah, I was just surprised that it did not add any more verbosity to
> > my boot at all..
> >
> > > If intel_idle also freezes the machine, you should open a bug on
> > > bugzilla.kernel.org, please add me and Len Brown to CC then.
> >
> > Thanks for the pointer - I did not know the alternatives were out
> > there.  I'll patch it in and rebuild the kernel to see how it goes.
> But first above problem (FACS address mismatch) should be addressed.

This isn't a linux problem, linux cannot help that some bios vendors use two FADT tables.
It should be fine to just use the 32 bits table though as linux does by default in that case.

> Chances are high that the machine does not freeze anymore then.
> Best is you open a bug here:
> http://bugzilla.kernel.org
> assign it to the ACPI component and attach acpidump output and at least
> past above error message in there. A short description that the machine
> freezes at boot (and disabling C-states in BIOS helps?) and the used
> kernel should also show up there.
> 
>     Thomas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Core i7 & C-States

[Thomas Renninger]

Hi,

On Monday 22 November 2010 02:30:51 Koornstra, Reinoud wrote:
> > -----Original Message-----
...
> > >     0.000000] ACPI Warning: 32/64 FACS address mismatch in FADT - two
> > > FACS tables! (20090903/tbfadt-369)
> > > [    0.000000] ACPI Warning: 32/64X FACS address mismatch in FADT -
> > > BBE19F40/00000000BBE19E40, using 32 (20090903/tbfadt-486)
> > This looks sever and chances are high that this is the reason for the
> > system freezes at boot up.
> > I could imagine the problem is that acpica/Linux behaves like old
> > Windowses (prior Windows Vista) and preferes 32-bit fadt addresses.
> > I opened a bug for that some time ago:
> > http://acpica.org/bugzilla/show_bug.cgi?id=885
> 
> The acpi 4.0 standard requires that either a 32 bits address
> is used and that then the 64 bits address should be 0. (not used)
> Or that when the 64 bits address is used then the 32 bits address
> isn't used and should be 0.
> Some biosses actually use both the 32 bits and 64 bits addresses,
> but the 64 bits address is the same as the 32 bits address,
> this is not as it's supposed to be, but linux can deal with this.
> Some biosses, do use different addresses for the 32 bits address
> and 64 bits addresses which isn't good at all.
Isn't good at all might might describe this well, but it doesn't
help.
If this would be a SLED bug, I'd point to the OEM, buying a non-Linux
certified/tested HW is a bad thing and you might run into quite some
work getting your HW going.

> In this case linux doesn't know which one to use and by default
> it'll use the 32 bits table. In this case we actually have 2 fadt
> tables a 32 bits one and a 64 bits one.
> Bios vendors might do this to support windows 2000.
Mainline policy always is/was to be compatible to Windows.
I expect this machine does not freeze on Windows and telling people
their machine won't ever boot with Linux isn't good at all as well.

...

> > > Thanks for the pointer - I did not know the alternatives were out
> > > there.  I'll patch it in and rebuild the kernel to see how it goes.
> > But first above problem (FACS address mismatch) should be addressed.
> 
> This isn't a linux problem, linux cannot help that some bios
> vendors use two FADT tables.
It can. If it works on Windows we can make it work as well.

> It should be fine to just use the 32 bits table though as linux
> does by default in that case.
Let's track this in a bug. Greg, can you open one as described below.
We want to know why this machine freezes.

If it's really because Windows picks up 32 bit FADT addresses with older
versions and prefers 64 bit addresses with Vista and later, at
least a boot param should be added to force the use of the XSDT or
RSDT pointed to FADT addresses. Then it could be easily checked now whether
this is the problem and if it works, people would have a workaround
to be able to boot their systems.
 
> > Chances are high that the machine does not freeze anymore then.
> > Best is you open a bug here:
> > http://bugzilla.kernel.org
> > assign it to the ACPI component and attach acpidump output and at least
> > past above error message in there. A short description that the machine
> > freezes at boot (and disabling C-states in BIOS helps?) and the used
> > kernel should also show up there.

      Thomas

RE: Core i7 & C-States

[Koornstra, Reinoud]

> -----Original Message-----
> From: Thomas Renninger [mailto:trenn@suse.de]
> Sent: Monday, November 22, 2010 1:22 AM
> To: Koornstra, Reinoud
> Cc: Greg Oliver; linux-acpi@vger.kernel.org; Len Brown; Moore, Robert
> Subject: Re: Core i7 & C-States
> 
> Hi,
> 
> On Monday 22 November 2010 02:30:51 Koornstra, Reinoud wrote:
> > > -----Original Message-----
> ...
> > > >     0.000000] ACPI Warning: 32/64 FACS address mismatch in FADT -
> two
> > > > FACS tables! (20090903/tbfadt-369)
> > > > [    0.000000] ACPI Warning: 32/64X FACS address mismatch in FADT
> -
> > > > BBE19F40/00000000BBE19E40, using 32 (20090903/tbfadt-486)
> > > This looks sever and chances are high that this is the reason for
> the
> > > system freezes at boot up.
> > > I could imagine the problem is that acpica/Linux behaves like old
> > > Windowses (prior Windows Vista) and preferes 32-bit fadt addresses.
> > > I opened a bug for that some time ago:
> > > http://acpica.org/bugzilla/show_bug.cgi?id=885
> >
> > The acpi 4.0 standard requires that either a 32 bits address
> > is used and that then the 64 bits address should be 0. (not used)
> > Or that when the 64 bits address is used then the 32 bits address
> > isn't used and should be 0.
> > Some biosses actually use both the 32 bits and 64 bits addresses,
> > but the 64 bits address is the same as the 32 bits address,
> > this is not as it's supposed to be, but linux can deal with this.
> > Some biosses, do use different addresses for the 32 bits address
> > and 64 bits addresses which isn't good at all.
> Isn't good at all might might describe this well, but it doesn't
> help.
> If this would be a SLED bug, I'd point to the OEM, buying a non-Linux
> certified/tested HW is a bad thing and you might run into quite some
> work getting your HW going.
> 
> > In this case linux doesn't know which one to use and by default
> > it'll use the 32 bits table. In this case we actually have 2 fadt
> > tables a 32 bits one and a 64 bits one.
> > Bios vendors might do this to support windows 2000.
> Mainline policy always is/was to be compatible to Windows.
> I expect this machine does not freeze on Windows and telling people
> their machine won't ever boot with Linux isn't good at all as well.

With 2.6.32 and your machine having 2 different FADT tables, a 32 bits one and a 64 bits one should not cause linux to hang.
Well, I CANNOT say this for sure, but in general it should be alright to just use the 32 bits one because if should just do the same as when you use the 64 bits FADT.
This is the default behavior in this case, linux doesn't know which one to use in this case and just picks the 32 bits FADT table which should be just fine.
In these cases whether you use the 32 bits or 64 bits one it shouldn't matter, because they should be the same.

> 
> ...
> 
> > > > Thanks for the pointer - I did not know the alternatives were out
> > > > there.  I'll patch it in and rebuild the kernel to see how it
> goes.
> > > But first above problem (FACS address mismatch) should be
> addressed.
> >
> > This isn't a linux problem, linux cannot help that some bios
> > vendors use two FADT tables.
> It can. If it works on Windows we can make it work as well.
> 
> > It should be fine to just use the 32 bits table though as linux
> > does by default in that case.
> Let's track this in a bug. Greg, can you open one as described below.
> We want to know why this machine freezes.
> 
> If it's really because Windows picks up 32 bit FADT addresses with
> older
> versions and prefers 64 bit addresses with Vista and later, at
> least a boot param should be added to force the use of the XSDT or
> RSDT pointed to FADT addresses. Then it could be easily checked now
> whether
> this is the problem and if it works, people would have a workaround
> to be able to boot their systems.

Windows XP should also be able to pick up the 64 bits table.
I guess this would concern windows version older than xp.
Bob What do you say about windows versions on this issue?

> 
> > > Chances are high that the machine does not freeze anymore then.
> > > Best is you open a bug here:
> > > http://bugzilla.kernel.org
> > > assign it to the ACPI component and attach acpidump output and at
> least
> > > past above error message in there. A short description that the
> machine
> > > freezes at boot (and disabling C-states in BIOS helps?) and the
> used
> > > kernel should also show up there.
> 
>       Thomas

RE: Core i7 & C-States

[Moore, Robert]

Sounds like we are back to the old question on this: What does Windows *really* do?


-----Original Message-----
From: Koornstra, Reinoud [mailto:koornstra@hp.com] 
Sent: Monday, November 22, 2010 2:32 AM
To: Thomas Renninger
Cc: Greg Oliver; linux-acpi@vger.kernel.org; Len Brown; Moore, Robert
Subject: RE: Core i7 & C-States

> -----Original Message-----
> From: Thomas Renninger [mailto:trenn@suse.de]
> Sent: Monday, November 22, 2010 1:22 AM
> To: Koornstra, Reinoud
> Cc: Greg Oliver; linux-acpi@vger.kernel.org; Len Brown; Moore, Robert
> Subject: Re: Core i7 & C-States
> 
> Hi,
> 
> On Monday 22 November 2010 02:30:51 Koornstra, Reinoud wrote:
> > > -----Original Message-----
> ...
> > > >     0.000000] ACPI Warning: 32/64 FACS address mismatch in FADT -
> two
> > > > FACS tables! (20090903/tbfadt-369)
> > > > [    0.000000] ACPI Warning: 32/64X FACS address mismatch in FADT
> -
> > > > BBE19F40/00000000BBE19E40, using 32 (20090903/tbfadt-486)
> > > This looks sever and chances are high that this is the reason for
> the
> > > system freezes at boot up.
> > > I could imagine the problem is that acpica/Linux behaves like old
> > > Windowses (prior Windows Vista) and preferes 32-bit fadt addresses.
> > > I opened a bug for that some time ago:
> > > http://acpica.org/bugzilla/show_bug.cgi?id=885
> >
> > The acpi 4.0 standard requires that either a 32 bits address
> > is used and that then the 64 bits address should be 0. (not used)
> > Or that when the 64 bits address is used then the 32 bits address
> > isn't used and should be 0.
> > Some biosses actually use both the 32 bits and 64 bits addresses,
> > but the 64 bits address is the same as the 32 bits address,
> > this is not as it's supposed to be, but linux can deal with this.
> > Some biosses, do use different addresses for the 32 bits address
> > and 64 bits addresses which isn't good at all.
> Isn't good at all might might describe this well, but it doesn't
> help.
> If this would be a SLED bug, I'd point to the OEM, buying a non-Linux
> certified/tested HW is a bad thing and you might run into quite some
> work getting your HW going.
> 
> > In this case linux doesn't know which one to use and by default
> > it'll use the 32 bits table. In this case we actually have 2 fadt
> > tables a 32 bits one and a 64 bits one.
> > Bios vendors might do this to support windows 2000.
> Mainline policy always is/was to be compatible to Windows.
> I expect this machine does not freeze on Windows and telling people
> their machine won't ever boot with Linux isn't good at all as well.

With 2.6.32 and your machine having 2 different FADT tables, a 32 bits one and a 64 bits one should not cause linux to hang.
Well, I CANNOT say this for sure, but in general it should be alright to just use the 32 bits one because if should just do the same as when you use the 64 bits FADT.
This is the default behavior in this case, linux doesn't know which one to use in this case and just picks the 32 bits FADT table which should be just fine.
In these cases whether you use the 32 bits or 64 bits one it shouldn't matter, because they should be the same.

> 
> ...
> 
> > > > Thanks for the pointer - I did not know the alternatives were out
> > > > there.  I'll patch it in and rebuild the kernel to see how it
> goes.
> > > But first above problem (FACS address mismatch) should be
> addressed.
> >
> > This isn't a linux problem, linux cannot help that some bios
> > vendors use two FADT tables.
> It can. If it works on Windows we can make it work as well.
> 
> > It should be fine to just use the 32 bits table though as linux
> > does by default in that case.
> Let's track this in a bug. Greg, can you open one as described below.
> We want to know why this machine freezes.
> 
> If it's really because Windows picks up 32 bit FADT addresses with
> older
> versions and prefers 64 bit addresses with Vista and later, at
> least a boot param should be added to force the use of the XSDT or
> RSDT pointed to FADT addresses. Then it could be easily checked now
> whether
> this is the problem and if it works, people would have a workaround
> to be able to boot their systems.

Windows XP should also be able to pick up the 64 bits table.
I guess this would concern windows version older than xp.
Bob What do you say about windows versions on this issue?

> 
> > > Chances are high that the machine does not freeze anymore then.
> > > Best is you open a bug here:
> > > http://bugzilla.kernel.org
> > > assign it to the ACPI component and attach acpidump output and at
> least
> > > past above error message in there. A short description that the
> machine
> > > freezes at boot (and disabling C-states in BIOS helps?) and the
> used
> > > kernel should also show up there.
> 
>       Thomas

Re: Core i7 & C-States

[Thomas Renninger]

On Monday 22 November 2010 11:36:49 pm Moore, Robert wrote:
> Sounds like we are back to the old question on this: What does Windows
> *really* do? 
Yep and for now it's only guessing, I should not have been
so verbose and just ask to open a bug. Greg, please attach there
(https://bugzilla.kernel.org):
- dmesg of the not freezing kernel
- acpidump output
- dmidecode output
- version of used kernel
- short description of the problem
- whatever else might be interesting

Possibly this is just resolved with a BIOS update?

Thanks,

     Thomas