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