1. 19 Oct, 2007 4 commits
  2. 18 Oct, 2007 1 commit
    • Andres Salomon's avatar
      serial: turn serial console suspend a boot rather than compile time option · 8f4ce8c3
      Andres Salomon authored
      Currently, there's a CONFIG_DISABLE_CONSOLE_SUSPEND that allows one to stop
      the serial console from being suspended when the rest of the machine goes
      to sleep.  This is incredibly useful for debugging power management-related
      things; however, having it as a compile-time option has proved to be
      incredibly inconvenient for us (OLPC).  There are plenty of times that we
      want serial console to not suspend, but for the most part we'd like serial
      console to be suspended.
      This drops CONFIG_DISABLE_CONSOLE_SUSPEND, and replaces it with a kernel
      boot parameter (no_console_suspend).  By default, the serial console will
      be suspended along with the rest of the system; by passing
      'no_console_suspend' to the kernel during boot, serial console will remain
      alive during suspend.
      For now, this is pretty serial console specific; further fixes could be
      applied to make this work for things like netconsole.
      Signed-off-by: default avatarAndres Salomon <dilinger@debian.org>
      Acked-by: default avatar"Rafael J. Wysocki" <rjw@sisk.pl>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Cc: Nigel Cunningham <nigel@suspend2.net>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  3. 17 Oct, 2007 3 commits
  4. 16 Oct, 2007 2 commits
  5. 12 Oct, 2007 8 commits
  6. 09 Oct, 2007 1 commit
  7. 17 Sep, 2007 2 commits
  8. 14 Sep, 2007 1 commit
  9. 20 Aug, 2007 1 commit
    • Len Brown's avatar
      ACPI: boot correctly with "nosmp" or "maxcpus=0" · 61ec7567
      Len Brown authored
      In MPS mode, "nosmp" and "maxcpus=0" boot a UP kernel with IOAPIC disabled.
      However, in ACPI mode, these parameters didn't completely disable
      the IO APIC initialization code and boot failed.
      	Disable the IO_APIC if "nosmp" or "maxcpus=0"
      	undefine disable_ioapic_setup() when it doesn't apply.
      	delete ioapic_setup(), it was a duplicate of parse_noapic()
      	delete undefinition of disable_ioapic_setup()
      	rename disable_ioapic_setup() to parse_noapic() to match i386
      	define disable_ioapic_setup() in header to match i386
      Acked-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
  10. 14 Aug, 2007 1 commit
  11. 11 Aug, 2007 6 commits
    • Len Brown's avatar
      ACPI: thermal: create "thermal.act=" to disable or override active trip point · f8707ec9
      Len Brown authored
      thermal.act=-1 disables all active trip points
      in all ACPI thermal zones.
      thermal.act=C, where C > 0, overrides all lowest temperature
      active trip points in all thermal zones to C degrees Celsius.
      Raising this trip-point may allow you to keep your system silent
      up to a higher temperature.  However, it will not allow you to
      raise the lowest temperature trip point above the next higher
      trip point (if there is one).  Lowering this trip point may
      kick in the fan sooner.
      Note that overriding this trip-point will disable any BIOS attempts
      to implement hysteresis around the lowest temperature trip point.
      This may result in the fan starting and stopping frequently
      if temperature frequently crosses C.
      WARNING: raising trip points above the manufacturer's defaults
      may cause the system to run at higher temperature and shorten
      its life.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
    • Len Brown's avatar
      ACPI: thermal: create "thermal.nocrt" to disable critical actions · f5487145
      Len Brown authored
      thermal.nocrt=1 disables actions on _CRT and _HOT
      ACPI thermal zone trip-points.  They will be marked
      as <disabled> in /proc/acpi/thermal_zone/*/trip_points.
      There are two cases where this option is used:
      1. Debugging a hot system crossing valid trip point.
         If your system fan is spinning at full speed,
         be sure that the vent is not clogged with dust.
         Many laptops have very fine thermal fins that are easily blocked.
         Check that the processor fan-sink is properly seated,
         has the proper thermal grease, and is really spinning.
         Check for fan related options in BIOS SETUP.
         Sometimes there is a performance vs quiet option.
         Defaults are generally the most conservative.
         If your fan is not spinning, yet /proc/acpi/fan/
         has files in it, please file a Linux/ACPI bug.
         WARNING: you risk shortening the lifetime of your
         hardware if you use this parameter on a hot system.
         Note that this refers to all system components,
         including the disk drive.
      2. Working around a cool system crossing critical
         trip point due to erroneous temperature reading.
         Try again with CONFIG_HWMON=n
         There is known potential for conflict between the
         the hwmon sub-system and the ACPI BIOS.
         If this fixes it, notify lm-sensors@lm-sensors.org
         and linux-acpi@vger.kernel.org
         Otherwise, file a Linux/ACPI bug, or notify
         just linux-acpi@vger.kernel.org.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
    • Len Brown's avatar
      ACPI: thermal: create "thermal.psv=" to override passive trip points · a70cdc52
      Len Brown authored
      "thermal.psv=-1" disables passive trip points
      for all ACPI thermal zones.
      "thermal.psv=C", where 'C' is degrees Celsius,
      overrides all existing passive trip points
      for all ACPI thermal zones.
      thermal.psv is checked at module load time,
      and in response to trip-point change events.
      Note that if the system does not deliver thermal zone
      temperature change events near the new trip-point,
      then it will not be noticed.  To force your custom
      trip point to be noticed, you may need to enable polling:
      eg. thermal.tzp=3000 invokes polling every 5 minutes.
      Note that once passive thermal throttling is invoked,
      it has its own internal Thermal Sampling Period (_TSP),
      that is unrelated to _TZP.
      WARNING: disabling or raising a thermal trip point
      may result in increased running temperature and
      shorter hardware lifetime on some systems.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
    • Len Brown's avatar
      ACPI: thermal: expose "thermal.tzp=" to set global polling frequency · 730ff34d
      Len Brown authored
      Thermal Zone Polling frequency (_TZP) is an optional ACPI object
      recommending the rate that the OS should poll the associated thermal zone.
      If _TZP is 0, no polling should be used.
      If _TZP is non-zero, then the platform recommends that
      the OS poll the thermal zone at the specified rate.
      The minimum period is 30 seconds.
      The maximum period is 5 minutes.
      (note _TZP and thermal.tzp units are in deci-seconds,
       so _TZP = 300 corresponds to 30 seconds)
      If _TZP is not present, ACPI 3.0b recommends that the
      thermal zone be polled at an "OS provided default frequency".
      However, common industry practice is:
      1. The BIOS never specifies any _TZP
      2. High volume OS's from this century never poll any thermal zones
      Ie. The OS depends on the platform's ability to
      provoke thermal events when necessary, and
      the "OS provided default frequency" is "never":-)
      There is a proposal that ACPI 4.0 be updated to reflect
      common industry practice -- ie. no _TZP, no polling.
      The Linux kernel already follows this practice --
      thermal zones are not polled unless _TZP is present and non-zero.
      But thermal zone polling is useful as a workaround for systems
      which have ACPI thermal control, but have an issue preventing
      thermal events.  Indeed, some Linux distributions still
      set a non-zero thermal polling frequency for this reason.
      But rather than ask the user to write a polling frequency
      into all the /proc/acpi/thermal_zone/*/polling_frequency
      files, here we simply document and expose the already
      existing module parameter to do the same at system level,
      to simplify debugging those broken platforms.
      Note that thermal.tzp is a module-load time parameter only.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
    • Len Brown's avatar
      ACPI: thermal: create "thermal.off=1" to disable ACPI thermal support · 72b33ef8
      Len Brown authored
      "thermal.off=1" disables all ACPI thermal support at boot time.
      CONFIG_ACPI_THERMAL=n can do this at build time.
      "# rmmod thermal" can do this at run time,
      as long as thermal is built as a module.
      WARNING: On some systems, disabling ACPI thermal support
      will cause the system to run hotter and reduce the
      lifetime of the hardware.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
    • Gabriel C's avatar
      kernel-parameters.txt : watchdog.txt should be wdt.txt · 8dfe9c21
      Gabriel C authored
      Documentation/watchdog/watchdog.txt does not exist, it is Documentation/watchdog/wdt.txt
      Signed-off-by: default avatarGabriel Craciunescu <nix.or.die@googlemail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  12. 09 Oct, 2007 1 commit
  13. 31 Jul, 2007 3 commits
  14. 26 Jul, 2007 1 commit
  15. 25 Jul, 2007 1 commit
  16. 21 Jul, 2007 1 commit
    • Andi Kleen's avatar
      x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu · 2aae950b
      Andi Kleen authored
      This implements new vDSO for x86-64.  The concept is similar
      to the existing vDSOs on i386 and PPC.  x86-64 has had static
      vsyscalls before,  but these are not flexible enough anymore.
      A vDSO is a ELF shared library supplied by the kernel that is mapped into
      user address space.  The vDSO mapping is randomized for each process
      for security reasons.
      Doing this was needed for clock_gettime, because clock_gettime
      always needs a syscall fallback and having one at a fixed
      address would have made buffer overflow exploits too easy to write.
      The vdso can be disabled with vdso=0
      It currently includes a new gettimeofday implemention and optimized
      clock_gettime(). The gettimeofday implementation is slightly faster
      than the one in the old vsyscall.  clock_gettime is significantly faster
      than the syscall for CLOCK_MONOTONIC and CLOCK_REALTIME.
      The new calls are generally faster than the old vsyscall.
      Advantages over the old x86-64 vsyscalls:
      - Extensible
      - Randomized
      - Cleaner
      - Easier to virtualize (the old static address range previously causes
      overhead e.g. for Xen because it has to create special page tables for it)
      Weak points:
      - glibc support still to be written
      The VM interface is partly based on Ingo Molnar's i386 version.
      Includes compile fix from Joachim Deguara
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  17. 20 Jul, 2007 1 commit
  18. 17 Jul, 2007 2 commits
    • Mel Gorman's avatar
      Add a movablecore= parameter for sizing ZONE_MOVABLE · 7e63efef
      Mel Gorman authored
      This patch adds a new parameter for sizing ZONE_MOVABLE called
      movablecore=.  While kernelcore= is used to specify the minimum amount of
      memory that must be available for all allocation types, movablecore= is
      used to specify the minimum amount of memory that is used for migratable
      allocations.  The amount of memory used for migratable allocations
      determines how large the huge page pool could be dynamically resized to at
      runtime for example.
      How movablecore is actually handled is that the total number of pages in
      the system is calculated and a value is set for kernelcore that is
      kernelcore == totalpages - movablecore
      Both kernelcore= and movablecore= can be safely specified at the same time.
      Signed-off-by: default avatarMel Gorman <mel@csn.ul.ie>
      Acked-by: default avatarAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Mel Gorman's avatar
      handle kernelcore=: generic · ed7ed365
      Mel Gorman authored
      This patch adds the kernelcore= parameter for x86.
      Once all patches are applied, a new command-line parameter exist and a new
      sysctl.  This patch adds the necessary documentation.
      From: Yasunori Goto <y-goto@jp.fujitsu.com>
        When "kernelcore" boot option is specified, kernel can't boot up on ia64
        because of an infinite loop.  In addition, the parsing code can be handled
        in an architecture-independent manner.
        This patch uses common code to handle the kernelcore= parameter.  It is
        only available to architectures that support arch-independent zone-sizing
        (i.e.  define CONFIG_ARCH_POPULATES_NODE_MAP).  Other architectures will
        ignore the boot parameter.
      [bunk@stusta.de: make cmdline_parse_kernelcore() static]
      Signed-off-by: default avatarMel Gorman <mel@csn.ul.ie>
      Signed-off-by: default avatarYasunori Goto <y-goto@jp.fujitsu.com>
      Acked-by: default avatarAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>