1. 07 Feb, 2008 2 commits
  2. 06 Feb, 2008 2 commits
  3. 23 Jan, 2008 4 commits
    • Len Brown's avatar
      ACPI: make _OSI(Linux) console messages smarter · d4b7dc49
      Len Brown authored
      
      If BIOS invokes _OSI(Linux), the kernel response
      depends on what the ACPI DMI list knows about the system,
      and that is reflectd in dmesg:
      
      1) System unknown to DMI:
      
      ACPI: BIOS _OSI(Linux) query ignored
      ACPI: DMI System Vendor: LENOVO
      ACPI: DMI Product Name: 7661W1P
      ACPI: DMI Product Version: ThinkPad T61
      ACPI: DMI Board Name: 7661W1P
      ACPI: DMI BIOS Vendor: LENOVO
      ACPI: DMI BIOS Date: 10/18/2007
      ACPI: Please send DMI info above to linux-acpi@vger.kernel.org
      ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org
      
      2) System known to DMI, but effect of OSI(Linux) unknown:
      
      ACPI: DMI detected: Lenovo ThinkPad T61
      ...
      ACPI: BIOS _OSI(Linux) query ignored via DMI
      ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org
      
      3) System known to DMI, which disables _OSI(Linux):
      
      ACPI: DMI detected: Lenovo ThinkPad T61
      ...
      ACPI: BIOS _OSI(Linux) query ignored via DMI
      
      4) System known to DMI, which enable _OSI(Linux):
      
      ACPI: DMI detected: Lenovo ThinkPad T61
      ACPI: Added _OSI(Linux)
      ...
      ACPI: BIOS _OSI(Linux) query honored via DMI
      
      cmdline overrides take precidence over the built-in
      default and the DMI prescribed default.
      cmdline "acpi_osi=Linux" results in:
      
      ACPI: BIOS _OSI(Linux) query honored via cmdline
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      d4b7dc49
    • Len Brown's avatar
      ACPI: Delete Intel Customer Reference Board (CRB) from OSI(Linux) DMI list · 7ce95ce5
      Len Brown authored
      
      Linux does not want BIOS writers to invoke _OSI(Linux) -
      for in the field it causes more Windows incompatibility problems
      than it solves.
      
      So when it is seen in the BIOS for an Intel Customer Reference Board,
      Linux should ignore its effect by default, and should complain loudly.
      Otherwise, the reference BIOS will go unfixed, and the bad BIOS
      will spread to the field.
      
      Users of this board can get the old behavior with "acpi_osi=Linux"
      
      As this was the only entry, delete acpi_osl_dmi_table[].
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      7ce95ce5
    • Len Brown's avatar
    • Len Brown's avatar
      ACPI: create acpi_dmi_dump() · 5a4e1432
      Len Brown authored
      
      A utility routine to print common entries used
      for ACPI-related DMI blacklist entries.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      5a4e1432
  4. 16 Nov, 2007 1 commit
  5. 10 Oct, 2007 1 commit
    • Len Brown's avatar
      cpuidle: consolidate 2.6.22 cpuidle branch into one patch · 4f86d3a8
      Len Brown authored
      
      commit e5a16b1f9eec0af7cfa0830304b41c1c0833cf9f
      Author: Len Brown <len.brown@intel.com>
      Date:   Tue Oct 2 23:44:44 2007 -0400
      
          cpuidle: shrink diff
      
          processor_idle.c |  440 +++++++++++++++++++++++++++++++++++++++++--
          1 file changed, 429 insertions(+), 11 deletions(-)
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      
      commit dfbb9d5aedfb18848a3e0d6f6e3e4969febb209c
      Author: Len Brown <len.brown@intel.com>
      Date:   Wed Sep 26 02:17:55 2007 -0400
      
          cpuidle: reduce diff size
      
          Reduces the cpuidle processor_idle.c diff vs 2.6.22 from this
           processor_idle.c | 2006 ++++++++++++++++++++++++++-----------------
           1 file changed, 1219 insertions(+), 787 deletions(-)
      
          to this:
           processor_idle.c |  502 +++++++++++++++++++++++++++++++++++++++----
           1 file changed, 458 insertions(+), 44 deletions(-)
      
          ...for the purpose of making the cpuilde patch less invasive
          and easier to review.
      
          no functional changes.  build tes...
      4f86d3a8
  6. 09 Oct, 2007 1 commit
    • Jeff Garzik's avatar
      drivers/firmware: const-ify DMI API and internals · 1855256c
      Jeff Garzik authored
      
      Three main sets of changes:
      
      1) dmi_get_system_info() return value should have been marked const,
         since callers should not be changing that data.
      
      2) const-ify DMI internals, since DMI firmware tables should,
         whenever possible, be marked const to ensure we never ever write to
         that data area.
      
      3) const-ify DMI API, to enable marking tables const where possible
         in low-level drivers.
      
      And if we're really lucky, this might enable some additional
      optimizations on the part of the compiler.
      
      The bulk of the changes are #2 and #3, which are interrelated.  #1 could
      have been a separate patch, but it was so small compared to the others,
      it was easier to roll it into this changeset.
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      1855256c
  7. 19 Jul, 2007 1 commit
    • Paul Mundt's avatar
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt authored
      Slab destructors were no longer supported after Christoph's
      c59def9f
      
       change. They've been
      BUGs for both slab and slub, and slob never supported them
      either.
      
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      20c2df83
  8. 03 Jul, 2007 2 commits
  9. 09 Jun, 2007 1 commit
    • Len Brown's avatar
      ACPI: disable _OSI(Linux) by default · 072971d7
      Len Brown authored
      In Linux-2.6.22 we expanded the boot parameter osi=
      so that it can enable and !enable an OSI string.
      
      _OSI(Linux) is a special case because we know that there
      are both systems that require it set, and systems
      require that it _not_ to be set.  In the long term it can't
      be set, for the same reason _OS(Linux) can't be enabled --
      it tends to confuse BIOS that are not properly
      validated with Linux.  Further, the semantics and version
      information of _OSI(Linux) were never actually defined.
      
      The kernel prints out a message if it sees _OSI(Linux)
      requested, and there is a DMI workaround to invoke
      "osi=Linux" automatically for existing systems that need it.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=7787
      
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      072971d7
  10. 30 May, 2007 2 commits
    • Len Brown's avatar
      ACPI: add __init to acpi_initialize_subsystem() · dd272b57
      Len Brown authored
      
      Add __init to:
      acpi_initialize_subsystem() (and un-export it)
      acpi_os_initialize()
      
      Add __initdata to:
      acpi_osl_dmi_table[]
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      dd272b57
    • Len Brown's avatar
      ACPI: Make _OSI(Linux) a special case · f507654d
      Len Brown authored
      _OSI("Linux") is like _OS("Linux"), it is ill-defined and
      virtually no BIOS vendors test interaction with it.
      As a result, it can do more damage than good because
      it causes the BIOS to follow un-tested paths.
      
      Recently, several machines have turned up that erroneously
      test this string in a way which causes them to _not_ test other
      compatibility strings, including the ZI9 and Toshiba.
      So it appears that this bad code has made it into
      a BIOS vendor's reference BIOS.
      
      Linux has no choice but to stop advertising compatibility
      with _OSI string "Linux" - as there are an unbounded
      number of possible incompatibilities going forward.
      
      But some BIOSes have already shipped which do use it
      for things like conditionally re-enabling video on resume
      from S3.  (Too bad they didn't do that unconditionally)
      
      Add special case code for _OSI(Linux)
      Squawk to dmesg if _OSI(Linux) is requested
      Add DMI list both to enable and disable _OSI(Linux)
      But for now, keep the default enabled via
      #define OSI_LINUX_ENABLED.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=7787
      
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      f507654d
  11. 29 May, 2007 1 commit
    • Len Brown's avatar
      ACPI: extend "acpi_osi=" boot option · ae00d812
      Len Brown authored
      
      The boot option "acpi_osi=" has always disabled Linux _OSI support,
      thus disabling all OS Interface strings which are advertised
      by Linux to the BIOS.
      
      Now...
      acpi_osi="string" adds the interface string, and
      acpi_osi="!string" invalidates the pre-defined interface string
      
      eg. acpi_osi="!Windows 2006"
      would disable Linux's claim of Vista compatibility.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      ae00d812
  12. 09 May, 2007 1 commit
    • Alexey Starikovskiy's avatar
      ACPI: created a dedicated workqueue for notify() execution · 88db5e14
      Alexey Starikovskiy authored
      HP nx6125/nx6325/... machines have a _GPE handler with an infinite
      loop sending Notify() events to different ACPI subsystems.
      
      Notify handler in ACPI driver is a C-routine, which may call ACPI
      interpreter again to get access to some ACPI variables
      (acpi_evaluate_xxx).
      On these HP machines such an evaluation changes state of some variable
      and lets the loop above break.
      
      In the current ACPI implementation Notify requests are being deferred
      to the same kacpid workqueue on which the above GPE handler with
      infinite loop is executing. Thus we have a deadlock -- loop will
      continue to spin, sending notify events, and at the same time
      preventing these notify events from being run on a workqueue. All
      notify events are deferred, thus we see increase in memory consumption
      noticed by author of the thread. Also as GPE handling is bloked,
      machines overheat. Eventually by external poll of the same
      acpi_evaluate, kacpid is released and all the queued notify events are
      free to run, thus 100% cpu utilization by kacpid for several seconds
      or more.
      
      To prevent all these horrors it's needed to not put notify events to
      kacpid workqueue by either executing them immediately or putting them
      on some other thread. It's dangerous to execute notify events in
      place, as it will put several ACPI interpreter stacks on top of each
      other (at least 4 in case of nx6125), thus causing kernel  stack
      overflow.
      
      First attempt to create a new thread was done by Peter Wainwright
      He created a bunch of threads, which were stealing work from a kacpid
      workqueue.
      This patch appeared in 2.6.15 kernel shipped with Ubuntu 6.06 LTS.
      
      Second attempt was done by me, I created a new thread for each Notify
      event. This worked OK on HP nx machines, but broke Linus' Compaq
      n620c, by producing threads with a speed what they stopped the machine
      completely. Thus this patch was reverted from 18-rc2 as I remember.
      I re-made the patch to create second workqueue just for notify events,
      thus hopping it will not break Linus' machine. Patch was tested on the
      same HP nx machines in #5534 and #7122, but I did not received reply
      from Linus on a test patch sent to him.
      Patch went to 19-rc and was rejected with much fanfare again.
      There was 4th patch, which inserted schedule_timeout(1) into deferred
      execution of kacpid, if we had any notify requests pending, but Linus
      decided that it was too complex (involved either changes to workqueue
      to see if it's empty or atomic inc/dec).
      Now you see last variant which adds yield() to every GPE execution.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=5534
      http://bugzilla.kernel.org/show_bug.cgi?id=8385
      
      Signed-off-by: default avatarAlexey Starikovskiy <alexey.y.starikovskiy@intel.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      88db5e14
  13. 08 May, 2007 1 commit
  14. 16 Feb, 2007 1 commit
  15. 15 Feb, 2007 2 commits
  16. 12 Feb, 2007 1 commit
  17. 02 Feb, 2007 2 commits
  18. 26 Jan, 2007 1 commit
    • Bjorn Helgaas's avatar
      ACPI: move FADT resource reservations from motherboard driver to osl · 9a47cdb1
      Bjorn Helgaas authored
      
      Resources described by the FADT aren't really a good fit for the
      ACPI motherboard driver.
      
      The motherboard driver cares about PNP0C01 and PNP0C02 devices and
      their resources.
      
      The FADT describes some resources used by the ACPI core.  Often, they
      are also described by by the _CRS of a motherboard device, but I think
      it's better to reserve them specifically in the ACPI osl.c because
      (a) the motherboard driver is optional and ACPI uses the resources even
      if the driver is absent, and (b) I want to remove the ACPI motherboard
      driver because it's mostly redundant with the PNP system.c driver.
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      9a47cdb1
  19. 20 Dec, 2006 1 commit
  20. 22 Nov, 2006 1 commit
    • David Howells's avatar
      WorkStruct: Pass the work_struct pointer instead of context data · 65f27f38
      David Howells authored
      
      Pass the work_struct pointer to the work function rather than context data.
      The work function can use container_of() to work out the data.
      
      For the cases where the container of the work_struct may go away the moment the
      pending bit is cleared, it is made possible to defer the release of the
      structure by deferring the clearing of the pending bit.
      
      To make this work, an extra flag is introduced into the management side of the
      work_struct.  This governs auto-release of the structure upon execution.
      
      Ordinarily, the work queue executor would release the work_struct for further
      scheduling or deallocation by clearing the pending bit prior to jumping to the
      work function.  This means that, unless the driver makes some guarantee itself
      that the work_struct won't go away, the work function may not access anything
      else in the work_struct or its container lest they be deallocated..  This is a
      problem if the auxiliary data is taken away (as done by the last patch).
      
      However, if the pending bit is *not* cleared before jumping to the work
      function, then the work function *may* access the work_struct and its container
      with no problems.  But then the work function must itself release the
      work_struct by calling work_release().
      
      In most cases, automatic release is fine, so this is the default.  Special
      initiators exist for the non-auto-release case (ending in _NAR).
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      65f27f38
  21. 17 Nov, 2006 1 commit
    • Linus Torvalds's avatar
      Revert "ACPI: created a dedicated workqueue for notify() execution" · b976fe19
      Linus Torvalds authored
      This reverts commit 37605a69.
      
      Again.
      
      This same bug has now been introduced twice: it was done earlier by
      commit b8d35192, only to be reverted
      last time in commit 72945b2b
      
      .
      
      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 <david-b@pacbell.net>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b976fe19
  22. 14 Oct, 2006 2 commits
  23. 05 Oct, 2006 1 commit
    • David Howells's avatar
      IRQ: Maintain regs pointer globally rather than passing to IRQ handlers · 7d12e780
      David Howells authored
      
      Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
      of passing regs around manually through all ~1800 interrupt handlers in the
      Linux kernel.
      
      The regs pointer is used in few places, but it potentially costs both stack
      space and code to pass it around.  On the FRV arch, removing the regs parameter
      from all the genirq function results in a 20% speed up of the IRQ exit path
      (ie: from leaving timer_interrupt() to leaving do_IRQ()).
      
      Where appropriate, an arch may override the generic storage facility and do
      something different with the variable.  On FRV, for instance, the address is
      maintained in GR28 at all times inside the kernel as part of general exception
      handling.
      
      Having looked over the code, it appears that the parameter may be handed down
      through up to twenty or so layers of functions.  Consider a USB character
      device attached to a USB hub, attached to a USB controller that posts its
      interrupts through a cascaded auxiliary interrupt controller.  A character
      device driver may want to pass regs to the sysrq handler through the input
      layer which adds another few layers of parameter passing.
      
      I've build this code with allyesconfig for x86_64 and i386.  I've runtested the
      main part of the code on FRV and i386, though I can't test most of the drivers.
      I've also done partial conversion for powerpc and MIPS - these at least compile
      with minimal configurations.
      
      This will affect all archs.  Mostly the changes should be relatively easy.
      Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
      
      	struct pt_regs *old_regs = set_irq_regs(regs);
      
      And put the old one back at the end:
      
      	set_irq_regs(old_regs);
      
      Don't pass regs through to generic_handle_irq() or __do_IRQ().
      
      In timer_interrupt(), this sort of change will be necessary:
      
      	-	update_process_times(user_mode(regs));
      	-	profile_tick(CPU_PROFILING, regs);
      	+	update_process_times(user_mode(get_irq_regs()));
      	+	profile_tick(CPU_PROFILING);
      
      I'd like to move update_process_times()'s use of get_irq_regs() into itself,
      except that i386, alone of the archs, uses something other than user_mode().
      
      Some notes on the interrupt handling in the drivers:
      
       (*) input_dev() is now gone entirely.  The regs pointer is no longer stored in
           the input_dev struct.
      
       (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking.  It does
           something different depending on whether it's been supplied with a regs
           pointer or not.
      
       (*) Various IRQ handler function pointers have been moved to type
           irq_handler_t.
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
      7d12e780
  24. 27 Sep, 2006 1 commit
  25. 16 Aug, 2006 1 commit
  26. 13 Jul, 2006 1 commit
  27. 10 Jul, 2006 1 commit
  28. 02 Jul, 2006 1 commit
  29. 30 Jun, 2006 2 commits