linux-stable.git/drivers/acpi, branch linux-2.6.19.y

[PATCH] ACPI: fix cpufreq regression

2007-02-05T16:31:42+00:00

recently cpufreq support on my laptop (Lenovo T60) broke completely:
when it's plugged into AC it would never go higher than 1 GHz - neither
1.3 GHz nor 1.83 GHz is possible - no matter which governor (userspace,
speed or ondemand) is used.

after some cpufreq debugging i tracked the regression back to the
following (totally correct) bug-fix commit:

   commit 0916bd3ebb7cefdd0f432e8491abe24f4b5a101e
   Author: Dave Jones 
   Date:   Wed Nov 22 20:42:01 2006 -0500

    [PATCH] Correct bound checking from the value returned from _PPC method.

this bugfix, which makes other laptops work, made a previously hidden
(BIOS) bug visible on my laptop.

The bug is the following: if the _PPC (Performance Present Capabilities)
optional ACPI object is queried /after/ bootup then the BIOS reports an
incorrect value of '2'.

My laptop (Lenovo T60) has the following performance states supported:

   0: 1833000
   1: 1333000
   2: 1000000

Per ACPI specification, a _PPC value of '0' means that all 3 performance
states are usable. A _PPC value of '1' means states 1 .. 2 are usable, a
value of '2' means only state '2' (slowest) is usable.

now, the _PPC object is optional, and it also comes with notification.
Furthermore, when a CPU object is initialized, the _PPC object is
initialized as well. So the following evaluation of the _PPC object is
superfluous:

 [] acpi_processor_get_platform_limit+0xa1/0xaf
 [] acpi_processor_register_performance+0x3b9/0x3ef
 [] acpi_cpufreq_cpu_init+0xb7/0x596
 [] cpufreq_add_dev+0x160/0x4a8
 [] sysdev_driver_register+0x5a/0xa0
 [] cpufreq_register_driver+0xb4/0x176
 [] acpi_cpufreq_init+0xe5/0xeb
 [] init+0x14f/0x3dd

and this is the point where my laptop's BIOS returns the incorrect value
of '2'. Note that it has not sent any notification event, so the value
is probably not really intentional (possibly spurious), and Windows
likely doesnt query it after bootup either. Maybe the value is kept at
'2' normally, and is only set to the real value when a true asynchronous
event (such as AC plug event, battery switch, etc.) occurs.

So i /think/ this is a grey area of the ACPI spec: per the letter of the
spec the _PPC value only changes when notified, so there's no reason to
query it after the system has booted up. So in my opinion the best (and
most compatible) strategy would be to do the change below, and to not
evaluate the _PPC object in the acpi_processor_get_performance_info()
call, but only evaluate it if _PPC is present during CPU object init, or
if it's notified during an asynchronous event. This change is more
permissive than the previous logic, so it definitely shouldnt break any
existing system.

This also happens to fix my laptop, which is merrily chugging along at
1.83 GHz now. Yay!

Signed-off-by: Ingo Molnar 
Cc: Dave Jones 
Acked-by: Len Brown 
Signed-off-by: Chris Wright

[PATCH] sched: fix bad missed wakeups in the i386, x86_64, ia64, ACPI and APM idle code

2007-01-10T19:05:19+00:00

Fernando Lopez-Lezcano reported frequent scheduling latencies and audio
xruns starting at the 2.6.18-rt kernel, and those problems persisted all
until current -rt kernels. The latencies were serious and unjustified by
system load, often in the milliseconds range.

After a patient and heroic multi-month effort of Fernando, where he
tested dozens of kernels, tried various configs, boot options,
test-patches of mine and provided latency traces of those incidents, the
following 'smoking gun' trace was captured by him:

                 _------=> CPU#
                / _-----=> irqs-off
               | / _----=> need-resched
               || / _---=> hardirq/softirq
               ||| / _--=> preempt-depth
               |||| /
               |||||     delay
   cmd     pid ||||| time  |   caller
      \   /    |||||   \   |   /
  IRQ_19-1479  1D..1    0us : __trace_start_sched_wakeup (try_to_wake_up)
  IRQ_19-1479  1D..1    0us : __trace_start_sched_wakeup <<...>-5856> (37 0)
  IRQ_19-1479  1D..1    0us : __trace_start_sched_wakeup (c01262ba 0 0)
  IRQ_19-1479  1D..1    0us : resched_task (try_to_wake_up)
  IRQ_19-1479  1D..1    0us : __spin_unlock_irqrestore (try_to_wake_up)
  ...
  -0     1...1   11us!: default_idle (cpu_idle)
  ...
  -0     0Dn.1  602us : smp_apic_timer_interrupt (c0103baf 1 0)
  ...
   <...>-5856  0D..2  618us : __switch_to (__schedule)
   <...>-5856  0D..2  618us : __schedule <-0> (20 162)
   <...>-5856  0D..2  619us : __spin_unlock_irq (__schedule)
   <...>-5856  0...1  619us : trace_stop_sched_switched (__schedule)
   <...>-5856  0D..1  619us : trace_stop_sched_switched <<...>-5856> (37 0)

what is visible in this trace is that CPU#1 ran try_to_wake_up() for
PID:5856, it placed PID:5856 on CPU#0's runqueue and ran resched_task()
for CPU#0. But it decided to not send an IPI that no CPU - due to
TS_POLLING. But CPU#0 never woke up after its NEED_RESCHED bit was set,
and only rescheduled to PID:5856 upon the next lapic timer IRQ. The
result was a 600+ usecs latency and a missed wakeup!

the bug turned out to be an idle-wakeup bug introduced into the mainline
kernel this summer via an optimization in the x86_64 tree:

    commit 495ab9c045e1b0e5c82951b762257fe1c9d81564
    Author: Andi Kleen 
    Date:   Mon Jun 26 13:59:11 2006 +0200

    [PATCH] i386/x86-64/ia64: Move polling flag into thread_info_status

    During some profiling I noticed that default_idle causes a lot of
    memory traffic. I think that is caused by the atomic operations
    to clear/set the polling flag in thread_info. There is actually
    no reason to make this atomic - only the idle thread does it
    to itself, other CPUs only read it. So I moved it into ti->status.

the problem is this type of change:

        if (!hlt_counter && boot_cpu_data.hlt_works_ok) {
-               clear_thread_flag(TIF_POLLING_NRFLAG);
+               current_thread_info()->status &= ~TS_POLLING;
                smp_mb__after_clear_bit();
                while (!need_resched()) {
                        local_irq_disable();

this changes clear_thread_flag() to an explicit clearing of TS_POLLING.
clear_thread_flag() is defined as:

        clear_bit(flag, &ti->flags);

and clear_bit() is a LOCK-ed atomic instruction on all x86 platforms:

  static inline void clear_bit(int nr, volatile unsigned long * addr)
  {
          __asm__ __volatile__( LOCK_PREFIX
                  "btrl %1,%0"

hence smp_mb__after_clear_bit() is defined as a simple compile barrier:

  #define smp_mb__after_clear_bit()       barrier()

but the explicit TS_POLLING clearing introduced by the patch:

+               current_thread_info()->status &= ~TS_POLLING;

is not an atomic op! So the clearing of the TS_POLLING bit is freely
reorderable with the reading of the NEED_RESCHED bit - and both now
reside in different memory addresses.

CPU idle wakeup very much depends on ordered memory ops, the clearing of
the TS_POLLING flag must always be done before we test need_resched()
and hit the idle instruction(s). [Symmetrically, the wakeup code needs
to set NEED_RESCHED before it tests the TS_POLLING flag, so memory
ordering is paramount.]

Fernando's dual-core Athlon64 system has a sufficiently advanced memory
ordering model so that it triggered this scenario very often.

( And it also turned out that the reason why these latencies never
  triggered on my testsystems is that i routinely use idle=poll, which
  was the only idle variant not affected by this bug. )

The fix is to change the smp_mb__after_clear_bit() to an smp_mb(), to
act as an absolute barrier between the TS_POLLING write and the
NEED_RESCHED read. This affects almost all idling methods (default,
ACPI, APM), on all 3 x86 architectures: i386, x86_64, ia64.

Signed-off-by: Ingo Molnar 
Tested-by: Fernando Lopez-Lezcano 
[chrisw: backport to 2.6.19.1]
Signed-off-by: Chris Wright

[PATCH] Correct bound checking from the value returned from _PPC method.

2006-11-23T17:18:55+00:00

processor_perflib.c::acpi_processor_ppc_notifier() check if the value
returned by the processor's _PPC method is 0 and return failed if so.
This is wrong since 0 indicate that the bios think the processor can go
to the highest frequency.  This patch for example fix the HP NX 6125 to
allow its highest frequency to be available.

Signed-off-by: Bruno Ducrot 
Cc: "Pallipadi, Venkatesh" 
Signed-off-by: Dave Jones 
Signed-off-by: Linus Torvalds

Revert "ACPI: created a dedicated workqueue for notify() execution"

2006-11-18T03:31:09+00:00

This reverts commit 37605a6900f6b4d886d995751fcfeef88c4e462c.

Again.

This same bug has now been introduced twice: it was done earlier by
commit b8d35192c55fb055792ff0641408eaaec7c88988, only to be reverted
last time in commit 72945b2b90a5554975b8f72673ab7139d232a121.

We must NOT try to queue up notify handlers to another thread than the
normal ACPI execution thread, because the notifications on some systems
seem to just keep on accumulating until we run out of memory and/or
threads.

Keeping events within the one deferred execution thread automatically
throttles the events properly.

At least the Compaq N620c will lock up completely on the first thermal
event without this patch reverted.

Cc: David Brownell 
Cc: Len Brown 
Cc: Alexey Starikovskiy 
Signed-off-by: Linus Torvalds

[PATCH] acpi memory hotplug: remove strange add_memory fail message

2006-10-20T17:26:38+00:00

I wrote a patch to avoid redundant memory hot-add call at boot time.  This
was cause of strange fail message of memory hotplug like "ACPI: add_memory
failed".  Memory is recognized by early boot code with EFI/E820.

But, if DSDT describes memory devices for them, then hot-add code is called
for already recognized memory, and it shows fail messages with -EEXIST.
So, sys admin will misunderstand this message as something wrong by it.

This patch avoids them by preventing redundant hot-add call until
completion of driver initialization.

[akpm@osdl.org: cleanups]
Signed-off-by: Yasunori Goto 
Cc: "Brown, Len" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] Change log level of a message of acpi_memhotplug to KERN_DEBUG

2006-10-20T17:26:37+00:00

I suppose this message seems quite useless except debugging.  It just shows
"Hotplug Mem Device".  System admin can't know anything by this message.
So, I would like to change it to KERN_DEBUG.

Signed-off-by: Yasunori Goto 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] fix "ACPI: Processor native C-states using MWAIT"

2006-10-20T17:26:37+00:00

This patch breaks C-state discovery on my IBM IntelliStation Z30 because
the return value of acpi_processor_get_power_info_fadt is not assigned to
"result" in the case that acpi_processor_get_power_info_cst returns
-ENODEV.  Thus, if ACPI provides C-state data via the FADT and not _CST (as
is the case on this machine), we incorrectly exit the function with -ENODEV
after reading the FADT.  The attached patch sets the value of result so
that we don't exit early.

Signed-off-by: Darrick J. Wong 
Acked-by: "Pallipadi, Venkatesh" 
Acked-by: "Brown, Len" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] acpi_processor_latency_notifier(): UP warning fix

2006-10-17T15:18:44+00:00

drivers/acpi/processor_idle.c:1112: warning: 'smp_callback' defined but not used

Cc: Len Brown 
Cc: Arjan van de Ven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Pull trivial into test branch

2006-10-14T06:28:07+00:00

Pull bugzilla-5534 into test branch

2006-10-14T06:26:42+00:00