1. Jan 19, 2008
  2. Jan 18, 2008
  3. Jan 17, 2008
  4. Jan 16, 2008
    • Peter Zijlstra's avatar
      lockdep: more hardirq annotations for notify_die() · fb1dac90
      Peter Zijlstra authored
      
      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: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      fb1dac90
    • Johannes Berg's avatar
      lockdep: fix workqueue creation API lockdep interaction · eb13ba87
      Johannes Berg authored
      
      Dave Young reported warnings from lockdep that the workqueue API
      can sometimes try to register lockdep classes with the same key
      but different names. This is not permitted in lockdep.
      
      Unfortunately, I was unaware of that restriction when I wrote
      the code to debug workqueue problems with lockdep and used the
      workqueue name as the lockdep class name. This can obviously
      lead to the problem if the workqueue name is dynamic.
      
      This patch solves the problem by always using a constant name
      for the workqueue's lockdep class, namely either the constant
      name that was passed in or a string consisting of the variable
      name.
      
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      eb13ba87
    • Nick Piggin's avatar
      lockdep: fix internal double unlock during self-test · 5a26db5b
      Nick Piggin authored
      
      Lockdep, during self-test (when it was simulating double unlocks) was
      sometimes unconditionally unlocking a spinlock when it had not been
      locked. This won't work for ticket locks.
      
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      5a26db5b
    • Linus Torvalds's avatar
      Linux 2.6.24-rc8 · cbd9c883
      Linus Torvalds authored
      cbd9c883
    • Luck, Tony's avatar
      [IA64] Fix unaligned handler for floating point instructions with base update · 1a499150
      Luck, Tony authored
      
      
      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: default avatarTony Luck <tony.luck@intel.com>
      1a499150
    • Linus Torvalds's avatar
      Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev · 0938e758
      Linus Torvalds authored
      * 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
        libata: correct handling of TSS DVD
        [libata] core checkpatch fix
        [libata] pata_bf54x: checkpatch fixes
        libata fixes for sparse-found problems
      0938e758
    • Alan Cox's avatar
      libata: correct handling of TSS DVD · 121a09e5
      Alan Cox authored
      
      
      Devices that misreport the validity bit for word 93 look like SATA.  If
      they are on the blacklist then we must not test for SATA but assume 40 wire
      in the 40 wire case (The TSSCorp reports 80 wire on SATA it seems!)
      
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      Cc: Tejun Heo <htejun@gmail.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      121a09e5
    • Andrew Morton's avatar
      [libata] core checkpatch fix · 0f757743
      Andrew Morton authored
      
      
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: Tejun Heo <htejun@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      0f757743
    • Andrew Morton's avatar
      [libata] pata_bf54x: checkpatch fixes · ed722d3d
      Andrew Morton authored
      
      
      WARNING: line over 80 characters
      #36: FILE: drivers/ata/pata_bf54x.c:1512:
      +	while (bfin_port_info[board_idx].udma_mask>0 && udma_fsclk[udma_mode] > fsclk) {
      
      ERROR: need spaces around that '>' (ctx:VxV)
      #36: FILE: drivers/ata/pata_bf54x.c:1512:
      +	while (bfin_port_info[board_idx].udma_mask>0 && udma_fsclk[udma_mode] > fsclk) {
       	                                          ^
      
      total: 1 errors, 1 warnings, 19 lines checked
      
      Your patch has style problems, please review.  If any of these errors
      are false positives report them to the maintainer, see
      CHECKPATCH in MAINTAINERS.
      
      Please run checkpatch prior to sending patches
      
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: Sonic Zhang <sonic.zhang@analog.com>
      Cc: Tejun Heo <htejun@gmail.com>
      Cc: sonic zhang <sonic.adi@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      ed722d3d
    • Al Viro's avatar
      libata fixes for sparse-found problems · b50e56d8
      Al Viro authored
      
      
      In pata_legacy and pata_winbond we've got bugs - cpu_to_le16() instead
      of cpu_to_le32().  Fortunately, both affected suckers are VLB, thus
      l-e-only, so we might get away with that unless we hit it with slop == 3
      (hadn't checked if playing with badly aligned sg could trigger that).
      Still buggy...  Moreover, pata_legacy, pata_winbond and pata_qdi forgot to
      initialize pad on the write side of 32bit case in their ->data_xfer().
      Hopefully the hardware does't care, but still, sending uninitialized
      data to it...
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      b50e56d8
    • Mathieu Desnoyers's avatar
      Fix Blackfin HARDWARE_PM support · 7d2284b0
      Mathieu Desnoyers authored
      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: default avatarMathieu 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: default avatarRobin Getz <rgetz@blackfin.uclinux.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7d2284b0