1. 26 12月, 2008 1 次提交
    • H
      x86: unify the implementation of FPU traps · a73ad333
      H. Peter Anvin 提交于
      On 32 bits, we may suffer IRQ 13, or supposedly we might have a buggy
      implementation which gives spurious trap 16.  We did not check for
      this on 64 bits, but there is no reason we can't make the code the
      same in both cases.  Furthermore, this is presumably rare, so do the
      spurious check last, instead of first.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      a73ad333
  2. 25 12月, 2008 1 次提交
  3. 23 12月, 2008 1 次提交
    • H
      x86: prioritize the FPU traps for the error code · adf77bac
      H. Peter Anvin 提交于
      In the case of multiple FPU errors, prioritize the error codes,
      instead of returning __SI_FAULT, which ends up pushing a 0 as the
      error code to userspace, a POSIX violation.
      
      For i386, we will simply return if there are no errors at all; for
      x86-64 this is probably a "can't happen" (and the code should be
      unified), but for this patch, return __SI_FAULT|SI_KERNEL if this ever
      happens.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      adf77bac
  4. 22 10月, 2008 1 次提交
  5. 13 10月, 2008 33 次提交
  6. 23 9月, 2008 1 次提交
    • S
      signals: demultiplexing SIGTRAP signal · da654b74
      Srinivasa Ds 提交于
      Currently a SIGTRAP can denote any one of below reasons.
      	- Breakpoint hit
      	- H/W debug register hit
      	- Single step
      	- Signal sent through kill() or rasie()
      
      Architectures like powerpc/parisc provides infrastructure to demultiplex
      SIGTRAP signal by passing down the information for receiving SIGTRAP through
      si_code of siginfot_t structure. Here is an attempt is generalise this
      infrastructure by extending it to x86 and x86_64 archs.
      Signed-off-by: NSrinivasa DS <srinivasa@in.ibm.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: akpm@linux-foundation.org
      Cc: paulus@samba.org
      Cc: linuxppc-dev@ozlabs.org
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      da654b74
  7. 31 7月, 2008 1 次提交
  8. 19 7月, 2008 1 次提交