1. 20 10月, 2007 2 次提交
  2. 19 10月, 2007 1 次提交
    • A
      serial: turn serial console suspend a boot rather than compile time option · 8f4ce8c3
      Andres Salomon 提交于
      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: NAndres Salomon <dilinger@debian.org>
      Acked-by: N"Rafael J. Wysocki" <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Cc: Nigel Cunningham <nigel@suspend2.net>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8f4ce8c3
  3. 18 10月, 2007 1 次提交
  4. 17 10月, 2007 4 次提交
  5. 13 10月, 2007 8 次提交
  6. 10 10月, 2007 1 次提交
  7. 18 9月, 2007 2 次提交
  8. 15 9月, 2007 1 次提交
  9. 21 8月, 2007 1 次提交
    • L
      ACPI: boot correctly with "nosmp" or "maxcpus=0" · 61ec7567
      Len Brown 提交于
      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.
      
      init/main.c:
      	Disable the IO_APIC if "nosmp" or "maxcpus=0"
      	undefine disable_ioapic_setup() when it doesn't apply.
      
      i386:
      	delete ioapic_setup(), it was a duplicate of parse_noapic()
      	delete undefinition of disable_ioapic_setup()
      
      x86_64:
      	rename disable_ioapic_setup() to parse_noapic() to match i386
      	define disable_ioapic_setup() in header to match i386
      
      http://bugzilla.kernel.org/show_bug.cgi?id=1641Acked-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      61ec7567
  10. 15 8月, 2007 1 次提交
  11. 12 8月, 2007 6 次提交
    • L
      ACPI: thermal: create "thermal.act=" to disable or override active trip point · f8707ec9
      Len Brown 提交于
      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: NLen Brown <len.brown@intel.com>
      f8707ec9
    • L
      ACPI: thermal: create "thermal.nocrt" to disable critical actions · f5487145
      Len Brown 提交于
      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: NLen Brown <len.brown@intel.com>
      f5487145
    • L
      ACPI: thermal: create "thermal.psv=" to override passive trip points · a70cdc52
      Len Brown 提交于
      "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: NLen Brown <len.brown@intel.com>
      a70cdc52
    • L
      ACPI: thermal: expose "thermal.tzp=" to set global polling frequency · 730ff34d
      Len Brown 提交于
      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: NLen Brown <len.brown@intel.com>
      730ff34d
    • L
      ACPI: thermal: create "thermal.off=1" to disable ACPI thermal support · 72b33ef8
      Len Brown 提交于
      "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: NLen Brown <len.brown@intel.com>
      72b33ef8
    • G
      kernel-parameters.txt : watchdog.txt should be wdt.txt · 8dfe9c21
      Gabriel C 提交于
      Documentation/watchdog/watchdog.txt does not exist, it is Documentation/watchdog/wdt.txt
      Signed-off-by: NGabriel Craciunescu <nix.or.die@googlemail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8dfe9c21
  12. 09 10月, 2007 1 次提交
  13. 01 8月, 2007 3 次提交
  14. 27 7月, 2007 1 次提交
  15. 26 7月, 2007 1 次提交
  16. 22 7月, 2007 1 次提交
    • A
      x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu · 2aae950b
      Andi Kleen 提交于
      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: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2aae950b
  17. 21 7月, 2007 1 次提交
  18. 18 7月, 2007 3 次提交
  19. 17 7月, 2007 1 次提交