From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 22:55:44 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F82216A404; Wed, 20 Feb 2008 22:55:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 53F2D13C43E; Wed, 20 Feb 2008 22:55:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 0B6B7744007; Thu, 21 Feb 2008 00:55:37 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 99tCpyNppiy9; Thu, 21 Feb 2008 00:55:36 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id A7BCA744006; Thu, 21 Feb 2008 00:55:35 +0200 (EET) Message-ID: <47BCAFE3.9050703@icyb.net.ua> Date: Thu, 21 Feb 2008 00:55:31 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, freebsd-i386@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> <47BB375C.5010208@icyb.net.ua> <47BB4D5C.9000406@icyb.net.ua> <47BC7287.6000301@icyb.net.ua> In-Reply-To: <47BC7287.6000301@icyb.net.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: PIIX4 chipset: (non-)exit from CPU states C2, C3 on interrupt X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 22:55:44 -0000 This is a report on an issue that I had with using C2 CPU power state on a system based on PIIX4E chipset. I think that other users of the chipsets from PIIX4 family might be affected as well. Also, this might be an informative reading for hackers chasing similar problems. Reference material: Intel(R) 82371AB PCI-TO-ISA/IDE Xcelerator (PIIX4) Datasheet http://www.intel.com/design/intarch/datashts/290562.htm Intelｮ 82371AB PIIX4, Intelｮ 82371EB PIIX4E and Intelｮ 82371MB PIIX4M Specification Update http://www.intel.com/design/chipsets/specupdt/297738.htm Intelｮ 82371EB (PIIX4E) Specification Update http://www.intel.com/design/chipsets/specupdt/290635.htm Relevant information can be found in the following sections of the original document and in updates/corrections/errata for them: 11.2. Clock Control 7.2.3. PMCNTRL猶OWER MANAGEMENT CONTROL REGISTER (IO) 7.1.16. DEVACTB優EVICE ACTIVITY B (FUNCTION 3) My summarized understanding: To behave in ACPI-compliant way with respect to C2 and C3 states the chipset must generate "Stop Break" events on any interrupt. This is because ACPI specification says the following about C2 state: "The hardware can exit this state for any reason, but must always exit this state whenever an interrupt is to be presented to the processor." For C3 it repeats the same and adds the following: "or when BM_RLD is set and a bus master is attempting to gain access to memory." According to PIIX4 documents the chipset exits "clock control state" either on "Stop Break" event or on "Burst" event. I leave the latter out of consideration because it is not ACPI compliant, CPU state is controlled by hardware, not by OS. Here's an excerpt from description of DEVACTB register, 6 lower bits are described: 5 IRQ8# Clock Event Enable (BRLD_EN_IRQ8)由/W. 1=Enable an unmasked IRQ8# to, when asserted, generate a Fast Burst Timer reload or Stop Break event. 0=Disable. 4 PME Clock Event Enable (BRLD_EN_PME)由/W. 1=Enable an asserted SMI#, GPI1#, PWRBTN#, or LID signal to generate a Fast Burst Timer reload or Stop Break event. 0=Disable. 3 Undefined. Must be written as a 0. 2 Keyboard/Mouse Global Reload Enable (GRLD_EN_KBC_MS)由/W. 1=Enable an assertion of IRQ1 or IRQ12/M to reload the Global Standby Timer. 0=Disable. 1 IRQ Clock Event Enable (BRLD_EN_IRQ)由/W. 1=Enable an unmasked IRQ[1,3:7,9:15], NMI, or INIT to generate a Burst event or Stop Break event. 0=Disable. 0 IRQ0 Clock Event Enable (BRLD_EN_IRQ0)由/W. 1=Enable an unmasked IRQ0 to generate a Burst event or Stop Break event. 0=Disable. In order for the hardware to behave in ACPI-compliant way, that is to generate "Stop Break" events on all interrupts, the following bits of this register must be set: 0 - for IRQ0, 5 - for IRQ8, 1 - for the rest of the maskable interrupts You can read a saga about my investigation of a C2 behavior of a FreeBSD 7.0-RC1 system installed on a hardware based on PIIX4E chipset: http://docs.FreeBSD.org/cgi/mid.cgi?479F0ED4.9030709 This is a long thread with a couple of side-branches that keeps you in suspense until the very end. For those without time to waste, the following link is a pointer to where the most interesting details appear: http://docs.FreeBSD.org/cgi/mid.cgi?47BB375C.5010208 In short: on this system bit 5 of the mentioned above register was reset (i.e. 0), so RTC/IRQ8 didn't cause exit from C2 state. Thus, with cx_lowest=C2, RTC interrupt was handled at the predictable times, usually back-to-back after IRQ0 handler. As a result statclock() gathered CPU usage information (user:nice:system:interrupt:idle) at quite deterministic moments, so the statics was very biased in favor of interrupt usage. This is what the register had after boot: $ pciconf -r pci0:0:7:3 0x58 03040c07 After doing the following CPU statics became reasonable: pciconf -w pci0:0:7:3 0x58 0x03040c27 >From pciconf -lv: intsmb0@pci0:0:7:3: class=0x068000 card=0x00000000 chip=0x71138086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M Power Management Controller' class = bridge In the end, my suggestion is that acpi_cpu code should check value of those 3 bits and set them if necessary. I am not actually sure why I have bit 5 reset to 0. Maybe because this is a fault of a vendor of my motherboard/BIOS. Maybe I unwittingly caused this by changing some BIOS setting, but if this is the case, then the setting must appear under a name and description that I would never relate to this issue. Another possible resolution is to check the bits, but instead of changing them just refuse to use anything lower than C1. -- Andriy Gapon