1. 28 Aug, 2009 1 commit
  2. 26 Aug, 2009 3 commits
    • Frans Pop's avatar
      acpi processor: remove superfluous warning message · bdf57de4
      Frans Pop authored
      This failure is very common on many platforms.  Handling it in the ACPI
      processor driver is enough, and we don't need a warning message unless
      CONFIG_ACPI_DEBUG is set.
      
      Based on a patch from Zhang Rui.
      
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389
      
      Signed-off-by: default avatarFrans Pop <elendil@planet.nl>
      Acked-by: default avatarZhang Rui <rui.zhang@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bdf57de4
    • Frans Pop's avatar
      ACPI processor: force throttling state when BIOS returns incorrect value · 2a908002
      Frans Pop authored
      If the BIOS reports an invalid throttling state (which seems to be
      fairly common after system boot), a reset is done to state T0.
      Because of a check in acpi_processor_get_throttling_ptc(), the reset
      never actually gets executed, which results in the error reoccurring
      on every access of for example /proc/acpi/processor/CPU0/throttling.
      
      Add a 'force' option to acpi_processor_set_throttling() to ensure
      the reset really takes effect.
      
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389
      
      This patch, together with the next one, fixes a regression introduced in
      2.6.30, listed on the regression list. They have been available for 2.5
      months now in bugzilla, but have not been picked up, despite various
      reminders and without any reason given.
      
      Google shows that numerous people are hitting this issue. The issue is in
      itself relatively minor, but the bug in the code is clear.
      
      The patches have been in all my kernels and today testing has shown that
      throttling works correctly with the patches applied when the system
      overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14
      
      ).
      Signed-off-by: default avatarFrans Pop <elendil@planet.nl>
      Acked-by: default avatarZhang Rui <rui.zhang@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2a908002
    • Yinghai Lu's avatar
      acpi: don't call acpi_processor_init if acpi is disabled · ce8442b5
      Yinghai Lu authored
      
      
      Jens reported early_ioremap messages with old ASUS board...
      
      > [    1.507461] pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling
      > [    1.532778] early_ioremap(3fffd080, 0000005c) [0] => Pid: 1, comm: swapper Not tainted 2.6.31-rc4 #36
      > [    1.561007] Call Trace:
      > [    1.568638]  [<c136e48b>] ? printk+0x18/0x1d
      > [    1.581734]  [<c15513ff>] __early_ioremap+0x74/0x1e9
      > [    1.596898]  [<c15515aa>] early_ioremap+0x1a/0x1c
      > [    1.611270]  [<c154a187>] __acpi_map_table+0x18/0x1a
      > [    1.626451]  [<c135a7f8>] acpi_os_map_memory+0x1d/0x25
      > [    1.642129]  [<c119459c>] acpi_tb_verify_table+0x20/0x49
      > [    1.658321]  [<c1193e50>] acpi_get_table_with_size+0x53/0xa1
      > [    1.675553]  [<c1193eae>] acpi_get_table+0x10/0x15
      > [    1.690192]  [<c155cc19>] acpi_processor_init+0x23/0xab
      > [    1.706126]  [<c1001043>] do_one_initcall+0x33/0x180
      > [    1.721279]  [<c155cbf6>] ? acpi_processor_init+0x0/0xab
      > [    1.737479]  [<c106893a>] ? register_irq_proc+0xaa/0xc0
      > [    1.753411]  [<c10689b7>] ? init_irq_proc+0x67/0x80
      > [    1.768316]  [<c15405e7>] kernel_init+0x120/0x176
      > [    1.782678]  [<c15404c7>] ? kernel_init+0x0/0x176
      > [    1.797062]  [<c10038b7>] kernel_thread_helper+0x7/0x10
      > [    1.812984] 00000080 + ffe00000
      
      that is rather later.
      acpi_gbl_permanent_mmap should be set in acpi_early_init()
      if acpi is not disabled
      
      and we have
      > [    0.000000] ASUS P2B-DS detected: force use of acpi=ht
      
      just don't load acpi_processor_init...
      Reported-and-tested-by: default avatarJens Rosenboom <jens@leia.mcbone.net>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ce8442b5
  3. 19 Aug, 2009 1 commit
    • Suresh Siddha's avatar
      clockevent: Prevent dead lock on clockevents_lock · f833bab8
      Suresh Siddha authored
      
      
      Currently clockevents_notify() is called with interrupts enabled at
      some places and interrupts disabled at some other places.
      
      This results in a deadlock in this scenario.
      
      cpu A holds clockevents_lock in clockevents_notify() with irqs enabled
      cpu B waits for clockevents_lock in clockevents_notify() with irqs disabled
      cpu C doing set_mtrr() which will try to rendezvous of all the cpus.
      
      This will result in C and A come to the rendezvous point and waiting
      for B. B is stuck forever waiting for the spinlock and thus not
      reaching the rendezvous point.
      
      Fix the clockevents code so that clockevents_lock is taken with
      interrupts disabled and thus avoid the above deadlock.
      
      Also call lapic_timer_propagate_broadcast() on the destination cpu so
      that we avoid calling smp_call_function() in the clockevents notifier
      chain.
      
      This issue left us wondering if we need to change the MTRR rendezvous
      logic to use stop machine logic (instead of smp_call_function) or add
      a check in spinlock debug code to see if there are other spinlocks
      which gets taken under both interrupts enabled/disabled conditions.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: "Pallipadi Venkatesh" <venkatesh.pallipadi@intel.com>
      Cc: "Brown Len" <len.brown@intel.com>
      LKML-Reference: <1250544899.2709.210.camel@sbs-t61.sc.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      f833bab8
  4. 02 Aug, 2009 4 commits
  5. 29 Jul, 2009 1 commit
  6. 27 Jul, 2009 1 commit
  7. 25 Jun, 2009 1 commit
  8. 23 Jun, 2009 7 commits
  9. 19 Jun, 2009 6 commits
  10. 18 Jun, 2009 1 commit
  11. 17 Jun, 2009 14 commits