X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Received: from hdsmsx404.amr.corp.intel.com ([10.127.2.66]) by hdsmsx403.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 7 Aug 2004 13:59:17 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C47CA8.41974880" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by hdsmsx404.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 7 Aug 2004 13:59:17 -0400 Received: from orsmsx311.amr.corp.intel.com ([192.168.65.40]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 7 Aug 2004 10:59:16 -0700 Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 7 Aug 2004 10:59:16 -0700 Received: from orsmsxvs041.jf.intel.com ([192.168.65.54]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 7 Aug 2004 10:59:15 -0700 Received: from petasus.jf.intel.com ([10.7.209.6]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004080710591515311 for ; Sat, 07 Aug 2004 10:59:15 -0700 Received: from caduceus.jf.intel.com (caduceus.jf.intel.com [10.7.208.8]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with ESMTP id i77I1T5v002829 for ; Sat, 7 Aug 2004 18:01:29 GMT Received: from pecan.UGent.be (pecan.ugent.be [157.193.49.18]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i77HwHBq020518 for ; Sat, 7 Aug 2004 17:58:18 GMT Received: from localhost (localhost.localdomain [127.0.0.1]) by pecan.UGent.be (Postfix) with ESMTP id 2A58535268F for ; Sat, 7 Aug 2004 19:59:13 +0200 (CEST) Received: from pecan.UGent.be ([127.0.0.1]) by localhost (gorilla.UGent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00503-08 for ; Sat, 7 Aug 2004 19:59:11 +0200 (CEST) Received: from tarzan.ugent.be (tarzan.ugent.be [157.193.40.45]) by pecan.UGent.be (Postfix) with ESMTP id B33ED352686 for ; Sat, 7 Aug 2004 19:59:11 +0200 (CEST) Received: from vpna167.ugent.be (vpna167.ugent.be [157.193.1.167]) by tarzan.ugent.be (Postfix) with ESMTP id BDC2453D02B for ; Sat, 7 Aug 2004 19:59:10 +0200 (CEST) content-class: urn:content-classes:message Subject: Re: Linux ACPI processor driver patch: user-definable power state limit Date: Sat, 7 Aug 2004 13:59:10 -0400 Message-ID: <200408071959.10529.jos.delbar-Cru1EgDzd7c@public.gmane.org> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Linux ACPI processor driver patch: user-definable power state limit Thread-Index: AcR8qEIlmjjv4pwDTra/CgFdrw2PPA== X-Message-Flag: Follow up From: "Jos Delbar" To: "Brown, Len" ------_=_NextPart_001_01C47CA8.41974880 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Re: Linux ACPI processor driver patch: user-definable power state limit

On Monday 02 August 2004 02:54, you wrote:
> I think we need a patch like this for a number of reasons.
> Some systems experience data corruption with C3,
> so until it is fixed we need an easy way to disable C3.
>
> boot parameter names must begin with acpi though.
> maybe acpi_cstate_limit=3 or something?
>
> Please send me the exact model numbers of the Dells
> that you know have this problem.  I met a guy from
> Dell who I may be able to get to help us with
> those models.
>
> thanks,
> -Len

I browsed through the Dell community forums and I believe it is safe to
conclude that at least the following notebook models may have this problem:

- Inspiron 300m, 500m, 600m
- Inspiron 4000, 4100, 4150
- Inspiron 8100, 8200, 8500, 8600
- Latitude C840
- Latitude D500, D600, D800

As expected, all of these systems use a mobile processor chipset, with either
an Intel Celeron-M, Pentium III-M, Pentium 4-M or Pentium M processor. All of
the people who have posted about this buzzing noise are using an ACPI-enabled
operating system, the majority Windows 2000/XP. Windows 98 does not have this
problem, for example. On systems that support it, disabling the power
management of the USB Root Hub(s) apparently softens--but does not
eliminate--the buzzing.

I updated the patch with the new module parameter name "acpi_cstate_limit" and
cleaned up the results of /proc/acpi/processor/.../power a little. The output
using acpi_cstate_limit=2 will now resemble:

active state: C2
default state: C1
user limit: C2
bus master activity: ffffffff
states:
C1: promotion[C2] demotion[--] latency[000] usage[00300510]
*C2: promotion[--] demotion[C1] latency[050] usage[04964774]
C3: <disabled>

If acpi_cstate_limit is passed as a kernel boot parameter, the kernel ring
buffer will reflect this. For example, using "processor.acpi_cstate_limit=1",
the relevant output for my system is:

ACPI: Processor [CPU0] (supports C0 C1, 8 throttling states)

I chose to always display C0 so this message will still make sense when using
acpi_cstate_limit=0.

One of the changes that I made, is unrelated to the C state limit.

@@ -2417,7 +2446,7 @@
        pr = (struct acpi_processor *) acpi_driver_data(device);

        /* Unregister the idle handler when processor #0 is removed. */
-       if (pr->id == 0)
+       if ((pr->id == 0) && (pr->flags.power))
                pm_idle = pm_idle_save;

        status = acpi_remove_notify_handler(pr->handle, ACPI_DEVICE_NOTIFY,

Without the check for pr->flags.power, it's possible that the old idle handler
would be "restored" without ever being stored in the function
acpi_processor_add(). In practice this shouldn't cause a problem since the
pm_idle_save global variable is implicitly initialized to NULL, but it feels
safer to do the check anyway.

Regards,

- Jos Delbar
  jos.delbar-Cru1EgDzd7c@public.gmane.org

------_=_NextPart_001_01C47CA8.41974880 Content-Description: processor.c.diff Content-Disposition: attachment; filename="processor.c.diff" Content-Type: text/x-diff; name=processor.c.diff Content-Transfer-Encoding: 7bit --- /usr/src/linux/drivers/acpi/processor.c 2004-08-07 18:25:15.064497551 +0200 +++ processor.c 2004-08-07 18:31:24.013809421 +0200 @@ -30,6 +30,14 @@ * 4. Need C1 timing -- must modify kernel (IRQ handler) to get this. */ +/* + * 07/08/04; Jos Delbar : + * Recognize power state limit as a boot parameter. + * + * 31/07/04; Jos Delbar : + * Add user-definable processor power state limit. + */ + #include #include #include @@ -80,6 +88,16 @@ MODULE_DESCRIPTION(ACPI_PROCESSOR_DRIVER_NAME); MODULE_LICENSE("GPL"); +/* + * The acpi_cstate_limit module parameter represents the maximum processor power state or + * C state to promote to. Values of 1, 2 and 3 are equivalent to the C1, C2 and C3 sleep + * states, respectively. A value of 0 disables processor power management altogether. + */ + +static int acpi_cstate_limit = ACPI_C_STATES_MAX; + +module_param(acpi_cstate_limit, int, S_IRUSR | S_IRGRP | S_IROTH); +MODULE_PARM_DESC(acpi_cstate_limit, "Limit the processor power state (0 = disable power management)"); static int acpi_processor_add (struct acpi_device *device); static int acpi_processor_remove (struct acpi_device *device, int type); @@ -449,6 +467,7 @@ sleep_ticks = ticks_elapsed(t1, t2) - cx->latency_ticks - C3_OVERHEAD; break; + case ACPI_STATE_C0: default: local_irq_enable(); return; @@ -535,7 +554,7 @@ * C0/C1 * ----- */ - pr->power.state = ACPI_STATE_C1; + pr->power.state = (acpi_cstate_limit != ACPI_STATE_C0 ? ACPI_STATE_C1 : ACPI_STATE_C0); pr->power.default_state = ACPI_STATE_C1; /* @@ -554,7 +573,7 @@ * TBD: Demote to default C-State after long periods of activity. * TBD: Investigate policy's use of CPU utilization -vs- sleep duration. */ - if (pr->power.states[ACPI_STATE_C2].valid) { + if (pr->power.states[ACPI_STATE_C2].valid && (acpi_cstate_limit >= ACPI_STATE_C2)) { pr->power.states[ACPI_STATE_C1].promotion.threshold.count = 10; pr->power.states[ACPI_STATE_C1].promotion.threshold.ticks = pr->power.states[ACPI_STATE_C2].latency_ticks; @@ -575,7 +594,7 @@ * short or whenever bus mastering activity occurs. */ if ((pr->power.states[ACPI_STATE_C2].valid) && - (pr->power.states[ACPI_STATE_C3].valid)) { + (pr->power.states[ACPI_STATE_C3].valid) && (acpi_cstate_limit >= ACPI_STATE_C3)) { pr->power.states[ACPI_STATE_C2].promotion.threshold.count = 4; pr->power.states[ACPI_STATE_C2].promotion.threshold.ticks = pr->power.states[ACPI_STATE_C3].latency_ticks; @@ -1859,10 +1878,15 @@ goto end; seq_printf(seq, "active state: C%d\n" - "default state: C%d\n" - "bus master activity: %08x\n", + "default state: C%d\n", pr->power.state, - pr->power.default_state, + pr->power.default_state); + + if (acpi_cstate_limit < ACPI_C_STATES_MAX) seq_printf(seq, + "user limit: C%d\n", + acpi_cstate_limit); + + seq_printf(seq, "bus master activity: %08x\n", pr->power.bm_activity); seq_puts(seq, "states:\n"); @@ -1876,6 +1900,11 @@ continue; } + if (i > acpi_cstate_limit) { + seq_puts(seq, "\n"); + continue; + } + if (pr->power.states[i].promotion.state) seq_printf(seq, "promotion[C%d] ", pr->power.states[i].promotion.state); @@ -2384,7 +2413,7 @@ printk(KERN_INFO PREFIX "%s [%s] (supports", acpi_device_name(device), acpi_device_bid(device)); - for (i=1; ipower.states[i].valid) printk(" C%d", i); if (pr->flags.throttling) @@ -2417,7 +2446,7 @@ pr = (struct acpi_processor *) acpi_driver_data(device); /* Unregister the idle handler when processor #0 is removed. */ - if (pr->id == 0) + if ((pr->id == 0) && (pr->flags.power)) pm_idle = pm_idle_save; status = acpi_remove_notify_handler(pr->handle, ACPI_DEVICE_NOTIFY, @@ -2447,6 +2476,10 @@ memset(&processors, 0, sizeof(processors)); memset(&errata, 0, sizeof(errata)); + /* Check for illegal user limits. */ + if(acpi_cstate_limit < ACPI_STATE_C0 || acpi_cstate_limit > ACPI_C_STATES_MAX) + return_VALUE(-EINVAL); + acpi_processor_dir = proc_mkdir(ACPI_PROCESSOR_CLASS, acpi_root_dir); if (!acpi_processor_dir) return_VALUE(-ENODEV); ------_=_NextPart_001_01C47CA8.41974880--