1. 14 12月, 2010 2 次提交
  2. 13 12月, 2010 1 次提交
    • T
      x86: HPET: Chose a paranoid safe value for the ETIME check · f1c18071
      Thomas Gleixner 提交于
      commit 995bd3bb (x86: Hpet: Avoid the comparator readback penalty)
      chose 8 HPET cycles as a safe value for the ETIME check, as we had the
      confirmation that the posted write to the comparator register is
      delayed by two HPET clock cycles on Intel chipsets which showed
      readback problems.
      
      After that patch hit mainline we got reports from machines with newer
      AMD chipsets which seem to have an even longer delay. See
      http://thread.gmane.org/gmane.linux.kernel/1054283 and
      http://thread.gmane.org/gmane.linux.kernel/1069458 for further
      information.
      
      Boris tried to come up with an ACPI based selection of the minimum
      HPET cycles, but this failed on a couple of test machines. And of
      course we did not get any useful information from the hardware folks.
      
      For now our only option is to chose a paranoid high and safe value for
      the minimum HPET cycles used by the ETIME check. Adjust the minimum ns
      value for the HPET clockevent accordingly.
      Reported-Bistected-and-Tested-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <alpine.LFD.2.00.1012131222420.2653@localhost6.localdomain6>
      Cc: Simon Kirby <sim@hostway.ca>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Andreas Herrmann <Andreas.Herrmann3@amd.com>
      Cc: John Stultz <johnstul@us.ibm.com>
      f1c18071
  3. 10 12月, 2010 1 次提交
  4. 28 11月, 2010 1 次提交
  5. 26 11月, 2010 1 次提交
  6. 18 11月, 2010 7 次提交
  7. 12 11月, 2010 1 次提交
    • F
      x86: Ignore trap bits on single step exceptions · 6c0aca28
      Frederic Weisbecker 提交于
      When a single step exception fires, the trap bits, used to
      signal hardware breakpoints, are in a random state.
      
      These trap bits might be set if another exception will follow,
      like a breakpoint in the next instruction, or a watchpoint in the
      previous one. Or there can be any junk there.
      
      So if we handle these trap bits during the single step exception,
      we are going to handle an exception twice, or we are going to
      handle junk.
      
      Just ignore them in this case.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=21332Reported-by: NMichael Stefaniuc <mstefani@redhat.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
      Cc: Alexandre Julliard <julliard@winehq.org>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: All since 2.6.33.x <stable@kernel.org>
      6c0aca28
  8. 11 11月, 2010 1 次提交
  9. 10 11月, 2010 5 次提交
  10. 30 10月, 2010 4 次提交
  11. 29 10月, 2010 2 次提交
  12. 28 10月, 2010 2 次提交
  13. 27 10月, 2010 12 次提交