> -----Original Message----- > From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- > owner@xxxxxxxxxxxxxxx] On Behalf Of Thomas Renninger > Sent: Sunday, November 21, 2010 8:47 AM > To: Greg Oliver > Cc: linux-acpi@xxxxxxxxxxxxxxx; 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@xxxxxxx> > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶›¡Ü}©ž²ÆzÚj:+v‰¨þø®w¥þŠàÞ¨è&¢)ß«a¶Úÿûz¹ÞúŽŠÝjÿŠwèf
