1. 17 6月, 2011 1 次提交
    • T
      clocksource: Make watchdog robust vs. interruption · b5199515
      Thomas Gleixner 提交于
      The clocksource watchdog code is interruptible and it has been
      observed that this can trigger false positives which disable the TSC.
      
      The reason is that an interrupt storm or a long running interrupt
      handler between the read of the watchdog source and the read of the
      TSC brings the two far enough apart that the delta is larger than the
      unstable treshold. Move both reads into a short interrupt disabled
      region to avoid that.
      Reported-and-tested-by: NVernon Mauery <vernux@us.ibm.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable@kernel.org
      b5199515
  2. 03 6月, 2011 1 次提交
    • T
      clockevents: Handle empty cpumask gracefully · 1b054b67
      Thomas Gleixner 提交于
      For UP it's stupid to request an initialized cpumask for the clock
      event devices. Though we need the mask set even on UP to avoid a
      horrible ifdeffery especially in the broadcast code.
      
      For SMP we can at least try to survive with a warning and set the
      cpumask of the cpu we're running on. That gives a decent chance to
      bring the machine up and retrieve the debug info.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Linus Walleij <linus.walleij@linaro.org
      Cc: Lee Jones <lee.jones@linaro.org>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      1b054b67
  3. 23 5月, 2011 1 次提交
  4. 20 5月, 2011 1 次提交
  5. 19 5月, 2011 3 次提交
  6. 17 5月, 2011 1 次提交
    • T
      tick: Clear broadcast active bit when switching to oneshot · 07f4beb0
      Thomas Gleixner 提交于
      The first cpu which switches from periodic to oneshot mode switches
      also the broadcast device into oneshot mode. The broadcast device
      serves as a backup for per cpu timers which stop in deeper
      C-states. To avoid starvation of the cpus which might be in idle and
      depend on broadcast mode it marks the other cpus as broadcast active
      and sets the brodcast expiry value of those cpus to the next tick.
      
      The oneshot mode broadcast bit for the other cpus is sticky and gets
      only cleared when those cpus exit idle. If a cpu was not idle while
      the bit got set in consequence the bit prevents that the broadcast
      device is armed on behalf of that cpu when it enters idle for the
      first time after it switched to oneshot mode.
      
      In most cases that goes unnoticed as one of the other cpus has usually
      a timer pending which keeps the broadcast device armed with a short
      timeout. Now if the only cpu which has a short timer active has the
      bit set then the broadcast device will not be armed on behalf of that
      cpu and will fire way after the expected timer expiry. In the case of
      Christians bug report it took ~145 seconds which is about half of the
      wrap around time of HPET (the limit for that device) due to the fact
      that all other cpus had no timers armed which expired before the 145
      seconds timeframe.
      
      The solution is simply to clear the broadcast active bit
      unconditionally when a cpu switches to oneshot mode after the first
      cpu switched the broadcast device over. It's not idle at that point
      otherwise it would not be executing that code.
      
      [ I fundamentally hate that broadcast crap. Why the heck thought some
        folks that when going into deep idle it's a brilliant concept to
        switch off the last device which brings the cpu back from that
        state? ]
      
      Thanks to Christian for providing all the valuable debug information!
      Reported-and-tested-by: NChristian Hoffmann <email@christianhoffmann.info>
      Cc: John Stultz <johnstul@us.ibm.com>
      Link: http://lkml.kernel.org/r/%3Calpine.LFD.2.02.1105161105170.3078%40ionos%3E
      Cc: stable@kernel.org
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      07f4beb0
  7. 05 5月, 2011 2 次提交
  8. 04 5月, 2011 2 次提交
    • T
      alarmtimer: Drop device refcount after rtc_open() · 179eb032
      Thomas Gleixner 提交于
      class_find_device() takes a refcount on the rtc device. rtc_open()
      takes another one, so we can drop it after the rtc_open() call.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: John Stultz <john.stultz@linaro.org>
      179eb032
    • T
      alarmtimer: Check return value of class_find_device() · ce788f93
      Thomas Gleixner 提交于
      alarmtimer_late_init() uses class_find_device() to find a alarm
      capable rtc device. The match callback stores a pointer to the name in
      the char pointer handed in from the call site. alarmtimer_late_init()
      checks the char pointer for NULL, but the pointer is on the stack and
      not initialized to NULL before the call. So it can have random content
      when the match function did not identify a device, which leads to
      random access in the following rtc_open() call where the pointer is
      dereferenced
      
      Instead of relying on the char pointer, check the return value of
      class_find_device. If a device is found then the name pointer is valid
      as well.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Cc: John Stultz <john.stultz@linaro.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      ce788f93
  9. 03 5月, 2011 3 次提交
  10. 29 4月, 2011 2 次提交
    • J
      timers: Remove delayed irqwork from alarmtimers implementation · 7068b7a1
      John Stultz 提交于
      Thomas asked about the delayed irq work in the alarmtimers code,
      and I realized that it was a legacy from when the alarmtimer base
      lock was a mutex (due to concerns that we'd be interacting with
      the RTC device, which is protected by mutexes).
      
      Since the alarmtimer base is now protected by a spinlock, we can
      simply execute alarmtimer functions directly from the hrtimer
      callback. Should any future alarmtimer functions sleep, they can
      simply manage scheduling any delayed work themselves.
      
      CC: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      7068b7a1
    • J
      timers: Improve alarmtimer comments and minor fixes · 180bf812
      John Stultz 提交于
      This patch addresses a number of minor comment improvements and
      other minor issues from Thomas' review of the alarmtimers code.
      
      CC: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      180bf812
  11. 27 4月, 2011 3 次提交
    • J
      timers: Posix interface for alarm-timers · 9a7adcf5
      John Stultz 提交于
      This patch exposes alarm-timers to userland via the posix clock
      and timers interface, using two new clockids: CLOCK_REALTIME_ALARM
      and CLOCK_BOOTTIME_ALARM. Both clockids behave identically to
      CLOCK_REALTIME and CLOCK_BOOTTIME, respectively, but timers
      set against the _ALARM suffixed clockids will wake the system if
      it is suspended.
      
      Some background can be found here:
      	https://lwn.net/Articles/429925/
      
      The concept for Alarm-timers was inspired by the Android Alarm
      driver (by Arve Hjønnevåg) found in the Android kernel tree.
      
      See: http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=drivers/rtc/alarm.c;h=1250edfbdf3302f5e4ea6194847c6ef4bb7beb1c;hb=android-2.6.36
      
      While the in-kernel interface is pretty similar between
      alarm-timers and Android alarm driver, the user-space interface
      for the Android alarm driver is via ioctls to a new char device.
      As mentioned above, I've instead chosen to export this functionality
      via the posix interface, as it seemed a little simpler and avoids
      creating duplicate interfaces to things like CLOCK_REALTIME and
      CLOCK_MONOTONIC under alternate names (ie:ANDROID_ALARM_RTC and
      ANDROID_ALARM_SYSTEMTIME).
      
      The semantics of the Android alarm driver are different from what
      this posix interface provides. For instance, threads other then
      the thread waiting on the Android alarm driver are able to modify
      the alarm being waited on. Also this interface does not allow
      the same wakelock semantics that the Android driver provides
      (ie: kernel takes a wakelock on RTC alarm-interupt, and holds it
      through process wakeup, and while the process runs, until the
      process either closes the char device or calls back in to wait
      on a new alarm).
      
      One potential way to implement similar semantics may be via
      the timerfd infrastructure, but this needs more research.
      
      There may also need to be some sort of sysfs system level policy
      hooks that allow alarm timers to be disabled to keep them
      from firing at inappropriate times (ie: laptop in a well insulated
      bag, mid-flight).
      
      CC: Arve Hjønnevåg <arve@android.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Alessandro Zummo <a.zummo@towertech.it>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      9a7adcf5
    • J
      timers: Introduce in-kernel alarm-timer interface · ff3ead96
      John Stultz 提交于
      This provides the in kernel interface and infrastructure for
      alarm-timers.
      
      Alarm-timers are a hybrid style timer, similar to hrtimers,
      but when the system is suspended, the RTC device is set to
      fire and wake the system for when the soonest alarm-timer
      expires.
      
      The concept for Alarm-timers was inspired by the Android Alarm
      driver (by Arve Hjønnevåg) found in the Android kernel tree.
      
      See: http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=drivers/rtc/alarm.c;h=1250edfbdf3302f5e4ea6194847c6ef4bb7beb1c;hb=android-2.6.36
      
      This in-kernel interface should be fairly compatible with the
      Android alarm driver in-kernel interface, but has the advantage
      of utilizing the new RTC timerqueue code instead of doing direct
      RTC manipulation.
      
      CC: Arve Hjønnevåg <arve@android.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Alessandro Zummo <a.zummo@towertech.it>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      ff3ead96
    • J
      time: Add timekeeping_inject_sleeptime · 304529b1
      John Stultz 提交于
      Some platforms cannot implement read_persistent_clock, as
      their RTC devices are only accessible when interrupts are enabled.
      This keeps them from being used by the timekeeping code on resume
      to measure the time in suspend.
      
      The RTC layer tries to work around this, by calling do_settimeofday
      on resume after irqs are reenabled to set the time properly. However,
      this only corrects CLOCK_REALTIME, and does not properly adjust
      the sleep time value. This causes btime in /proc/stat to be incorrect
      as well as making the new CLOCK_BOTTTIME inaccurate.
      
      This patch resolves the issue by introducing a new timekeeping hook
      to allow the RTC layer to inject the sleep time on resume.
      
      The code also checks to make sure that read_persistent_clock is
      nonfunctional before setting the sleep time, so that should the RTC's
      HCTOSYS option be configured in on a system that does support
      read_persistent_clock we will not increase the total_sleep_time twice.
      
      CC: Arve Hjønnevåg <arve@android.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      304529b1
  12. 18 4月, 2011 1 次提交
  13. 04 4月, 2011 1 次提交
  14. 31 3月, 2011 1 次提交
  15. 24 3月, 2011 1 次提交
  16. 13 3月, 2011 1 次提交
    • T
      posix-clocks: Check write permissions in posix syscalls · 6e6823d1
      Torben Hohn 提交于
      pc_clock_settime() and pc_clock_adjtime() do not check whether the fd
      was opened in write mode, so a clock can be set with a read only fd.
      
      [ tglx: We deliberately do not return -EPERM as we want this to be
        	distingushable from the capability based permission check ]
      Signed-off-by: NTorben Hohn <torbenh@gmx.de>
      LKML-Reference: <1299173174-348-4-git-send-email-torbenh@gmx.de>
      Cc: Richard Cochran <richard.cochran@omicron.at>
      Cc: John Stultz <johnstul@us.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      6e6823d1
  17. 26 2月, 2011 1 次提交
    • T
      clockevents: Prevent oneshot mode when broadcast device is periodic · 3a142a06
      Thomas Gleixner 提交于
      When the per cpu timer is marked CLOCK_EVT_FEAT_C3STOP, then we only
      can switch into oneshot mode, when the backup broadcast device
      supports oneshot mode as well. Otherwise we would try to switch the
      broadcast device into an unsupported mode unconditionally. This went
      unnoticed so far as the current available broadcast devices support
      oneshot mode. Seth unearthed this problem while debugging and working
      around an hpet related BIOS wreckage.
      
      Add the necessary check to tick_is_oneshot_available().
      Reported-and-tested-by: NSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <alpine.LFD.2.00.1102252231200.2701@localhost6.localdomain6>
      Cc: stable@kernel.org # .21 ->
      3a142a06
  18. 22 2月, 2011 2 次提交
  19. 19 2月, 2011 1 次提交
  20. 12 2月, 2011 1 次提交
  21. 02 2月, 2011 4 次提交
  22. 01 2月, 2011 2 次提交
  23. 31 1月, 2011 4 次提交