1. 25 1月, 2008 19 次提交
  2. 24 1月, 2008 2 次提交
  3. 23 1月, 2008 3 次提交
  4. 22 1月, 2008 5 次提交
  5. 20 1月, 2008 3 次提交
  6. 19 1月, 2008 3 次提交
  7. 18 1月, 2008 2 次提交
  8. 17 1月, 2008 1 次提交
  9. 16 1月, 2008 2 次提交
    • P
      lockdep: more hardirq annotations for notify_die() · fb1dac90
      Peter Zijlstra 提交于
      On Sat, 2007-12-29 at 18:06 +0100, Marcin Slusarz wrote:
      > Hi
      > Today I've got this (while i was upgrading my gentoo box):
      >
      > WARNING: at kernel/lockdep.c:2658 check_flags()
      > Pid: 21680, comm: conftest Not tainted 2.6.24-rc6 #63
      >
      > Call Trace:
      >  [<ffffffff80253457>] check_flags+0x1c7/0x1d0
      >  [<ffffffff80257217>] lock_acquire+0x57/0xc0
      >  [<ffffffff8024d5c0>] __atomic_notifier_call_chain+0x60/0xd0
      >  [<ffffffff8024d641>] atomic_notifier_call_chain+0x11/0x20
      >  [<ffffffff8024d67e>] notify_die+0x2e/0x30
      >  [<ffffffff8020da0a>] do_divide_error+0x5a/0xa0
      >  [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
      >  [<ffffffff80255b89>] trace_hardirqs_on+0xd9/0x180
      >  [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
      >  [<ffffffff80523c2d>] error_exit+0x0/0xa9
      >
      > possible reason: unannotated irqs-off.
      > irq event stamp: 4693
      > hardirqs last  enabled at (4693): [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
      > hardirqs last disabled at (4692): [<ffffffff80522c17>] trace_hardirqs_off_thunk+0x35/0x37
      > softirqs last  enabled at (3546): [<ffffffff80238343>] __do_softirq+0xb3/0xd0
      > softirqs last disabled at (3521): [<ffffffff8020c97c>] call_softirq+0x1c/0x30
      
      more early fixups for notify_die()..
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fb1dac90
    • L
      [IA64] Fix unaligned handler for floating point instructions with base update · 1a499150
      Luck, Tony 提交于
      The compiler team did the hard work for this distilling a problem in
      large fortran application which showed up when applied to a 290MB input
      data set down to this instruction:
      
      	ldfd f34=[r17],-8
      
      Which they noticed incremented r17 by 0x10 rather than decrementing it
      by 8 when the value in r17 caused an unaligned data fault.  I tracked
      it down to some bad instruction decoding in unaligned.c. The code
      assumes that the 'x' bit can determine whether the instruction is
      an "ldf" or "ldfp" ... which it is for opcode=6 (see table 4-29 on
      page 3:302 of the SDM).  But for opcode=7 the 'x' bit is irrelevent,
      all variants are "ldf" instructions (see table 4-36 on page 3:306).
      
      Note also that interpreting the instruction as "ldfp" means that the
      "paired" floating point register (f35 in the example here) will also
      be corrupted.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      1a499150