1. 25 1月, 2008 7 次提交
  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 4 次提交
    • 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
    • M
      Fix Blackfin HARDWARE_PM support · 7d2284b0
      Mathieu Desnoyers 提交于
      This patch restores the blackfin Hardware Performance Monitor Profiling
      support that was killed by the combining of instrumentation menus in
      commit 09cadedb.
      
      Since there seems to be no good reason to behave differently from other
      architectures, it now automatically selects the hardware performance
      counters whenever the profiling is activated.
      
      mach-common/irqpanic.c: pm_overflow calls pm_overflow_handler which is
      in oprofile/op_model_bf533.c.  I doubt that setting HARDWARE_PM as "m"
      will work at all, since the pm_overflow_handler should be in the core
      kernel image because it is called by irqpanic.c.
      
      Therefore, I change HARDWARE_PM from a tristate to a bool.
      
      The whole arch/$(ARCH)/oprofile/ is built depending on CONFIG_OPROFILE. Since
      part of the HARDWARE_PM support files sits in this directory, it makes sense to
      also depend on OPROFILE, not only PROFILING. Since OPROFILE already depends on
      PROFILING, it is correct to only depend on OPROFILE only.
      
      Thanks to Adrian Bunk for finding this bug and providing an initial
      patch.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      CC: Adrian Bunk <adrian.bunk@movial.fi>
      CC: Randy Dunlap <randy.dunlap@oracle.com>
      CC: bryan.wu@analog.com
      Acked-by: NRobin Getz <rgetz@blackfin.uclinux.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7d2284b0
    • L
      Fix ARM profiling/instrumentation configuration · 38ad9aeb
      Linus Torvalds 提交于
      Commit 09cadedb ("Combine
      instrumentation menus in kernel/Kconfig.instrumentation") broke ARM
      profiling support, since ARM has some extra Kconfig options and doesn't
      just use the common OPROFILE/KPROBES config options.
      
      Rather than just revert the thing outright, or add ARM-specific
      knowledge to the generic Kconfig.instrumentation file (where the only
      and whole point was to be generic, not too architecture-specific), this
      just makes ARM not use the generic version, since it doesn't suit it.
      
      So create an arm-specific version of Kconfig.instrumentation instead,
      and use that.
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NRussell King <rmk+lkml@arm.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      38ad9aeb
  10. 15 1月, 2008 10 次提交