1. 07 1月, 2012 37 次提交
  2. 04 1月, 2012 3 次提交
    • L
      Revert "rtc: Expire alarms after the time is set." · f423fc62
      Linus Torvalds 提交于
      This reverts commit 93b2ec01.
      
      The call to "schedule_work()" in rtc_initialize_alarm() happens too
      early, and can cause oopses at bootup
      
      Neil Brown explains why we do it:
      
        "If you set an alarm in the future, then shutdown and boot again after
         that time, then you will end up with a timer_queue node which is in
         the past.
      
         When this happens the queue gets stuck.  That entry-in-the-past won't
         get removed until and interrupt happens and an interrupt won't happen
         because the RTC only triggers an interrupt when the alarm is "now".
      
         So you'll find that e.g.  "hwclock" will always tell you that
         'select' timed out.
      
         So we force the interrupt work to happen at the start just in case."
      
      and has a patch that convert it to do things in-process rather than with
      the worker thread, but right now it's too late to play around with this,
      so we just revert the patch that caused problems for now.
      Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
      Requested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Requested-by: NJohn Stultz <john.stultz@linaro.org>
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f423fc62
    • L
      Revert "rtc: Disable the alarm in the hardware" · 157e8bf8
      Linus Torvalds 提交于
      This reverts commit c0afabd3.
      
      It causes failures on Toshiba laptops - instead of disabling the alarm,
      it actually seems to enable it on the affected laptops, resulting in
      (for example) the laptop powering on automatically five minutes after
      shutdown.
      
      There's a patch for it that appears to work for at least some people,
      but it's too late to play around with this, so revert for now and try
      again in the next merge window.
      
      See for example
      
      	http://bugs.debian.org/652869
      
      Reported-and-bisected-by: Andreas Friedrich <afrie@gmx.net> (Toshiba Tecra)
      Reported-by: Antonio-M. Corbi Bellot <antonio.corbi@ua.es> (Toshiba Portege R500)
      Reported-by: Marco Santos <marco.santos@waynext.com> (Toshiba Portege Z830)
      Reported-by: Christophe Vu-Brugier <cvubrugier@yahoo.fr>  (Toshiba Portege R830)
      Cc: Jonathan Nieder <jrnieder@gmail.com>
      Requested-by: NJohn Stultz <john.stultz@linaro.org>
      Cc: stable@kernel.org  # for the versions that applied this
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      157e8bf8
    • M
      hung_task: fix false positive during vfork · f9fab10b
      Mandeep Singh Baines 提交于
      vfork parent uninterruptibly and unkillably waits for its child to
      exec/exit. This wait is of unbounded length. Ignore such waits
      in the hung_task detector.
      Signed-off-by: NMandeep Singh Baines <msb@chromium.org>
      Reported-by: NSasha Levin <levinsasha928@gmail.com>
      LKML-Reference: <1325344394.28904.43.camel@lappy>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: John Kacur <jkacur@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f9fab10b