1. 08 1月, 2013 6 次提交
    • H
      s390/irq: remove split irq fields from /proc/stat · 420f42ec
      Heiko Carstens 提交于
      Now that irq sum accounting for /proc/stat's "intr" line works again we
      have the oddity that the sum field (first field) contains only the sum
      of the second (external irqs) and third field (I/O interrupts).
      The reason for that is that these two fields are already sums of all other
      fields. So if we would sum up everything we would count every interrupt
      twice.
      This is broken since the split interrupt accounting was merged two years
      ago: 052ff461 "[S390] irq: have detailed
      statistics for interrupt types".
      To fix this remove the split interrupt fields from /proc/stat's "intr"
      line again and only have them in /proc/interrupts.
      
      This restores the old behaviour, seems to be the only sane fix and mimics
      a behaviour from other architectures where /proc/interrupts also contains
      more than /proc/stat's "intr" line does.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      420f42ec
    • H
      s390/irq: enable irq sum accounting for /proc/stat again · add9bde2
      Heiko Carstens 提交于
      For more than two years, since f2c66cd8
      "/proc/stat: scalability of irq num per cpu" the output of /proc/stat is
      broken.
      The first field in the "intr" line should contain the sum of all interrupts,
      however since the above mentioned change it is always zero.
      
      The reason for that is that a per cpu irq sum variable had been introduced
      which got incremented when calling kstat_incr_irqs_this_cpu(). However
      on s390 we directly incremented only the per cpu per irq counter by accessing
      the array element via kstat_cpu(smp_processor_id()).irqs[...].
      So fix this and use the kstat_incr_irqs_this_cpu() wrapper which increments
      both: the per cpu per irq counter and the per cpu irq sum counter.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      add9bde2
    • H
      1427add0
    • H
      s390/pci: remove dead code · b2034e19
      Heiko Carstens 提交于
      Get rid of these:
      
      arch/s390/pci/pci_dma.c:16:29: warning: ‘zpci_ioat_dt’ defined but not used [-Wunused-variable]
      arch/s390/pci/pci.c:164:12: warning: ‘zpci_store_fib’ defined but not used [-Wunused-function]
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      b2034e19
    • H
      s390/smp: fix section mismatch for smp_add_present_cpu() · eba61970
      Heiko Carstens 提交于
      Fixes this section mismatch:
      
      WARNING: vmlinux.o(.text+0x145e4): Section mismatch in reference from the function
         smp_add_present_cpu() to the function .cpuinit.text:register_cpu()
      The function smp_add_present_cpu() references
      the function __cpuinit register_cpu().
      This is often because smp_add_present_cpu lacks a __cpuinit
      annotation or the annotation of register_cpu is wrong.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      eba61970
    • M
      s390/debug: Fix s390dbf lockdep problem in debug_(un)register_view() · 5a334c08
      Michael Holzheu 提交于
      The debug_register/unregister_view() functions call debugfs_remove()
      while holding the debug_info spinlock. Because debugfs_remove() takes
      a mutex and therefore can sleep this is not allowed. To fix the problem
      we give up the debug_info lock before calling debugfs_remove().
      
      The following shows the lockdep message:
      
      [ INFO: possible circular locking dependency detected ]
      -------------------------------------------------------
      rmmod/4379 is trying to acquire lock:
      (&sb->s_type->i_mutex_key#2){+.+.+.}, at: [<00000000003acae2>] debugfs_remove+0x5e/0xa
      
      but task is already holding lock:
      (&(&rc->lock)->rlock){-.-...}, at: [<000000000010a5ae>] debug_unregister_view+0x3a/0xd
      
      which lock already depends on the new lock.
      
      -> #0 (&sb->s_type->i_mutex_key#2){+.+.+.}:
      [<00000000001b1644>] validate_chain+0x880/0x1154
      [<00000000001b4d6c>] __lock_acquire+0x414/0xc44
      [<00000000001b5c16>] lock_acquire+0xbe/0x178
      [<0000000000614016>] mutex_lock_nested+0x66/0x36c
      [<00000000003acae2>] debugfs_remove+0x5e/0xac
      [<000000000010a620>] debug_unregister_view+0xac/0xd0
      [<000003ff8002f140>] qeth_core_exit+0x48/0xf08 [qeth]
      [<00000000001c35a4>] SyS_delete_module+0x1a4/0x260
      [<0000000000618134>] sysc_noemu+0x22/0x28
      [<000003fffd4704da>] 0x3fffd4704da
      Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      5a334c08
  2. 04 1月, 2013 1 次提交
    • G
      ARCH: drivers remove __dev* attributes. · b881bc46
      Greg Kroah-Hartman 提交于
      This fixes up all of the smaller arches that had __dev* markings for
      their platform-specific drivers.
      
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      __devinitconst, and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chen Liqin <liqin.chen@sunplusct.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Bob Liu <lliubbo@gmail.com>
      Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Myron Stowe <myron.stowe@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Thierry Reding <thierry.reding@avionic-design.de>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Yong Zhang <yong.zhang0@gmail.com>
      Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Cc: Jan Glauber <jang@linux.vnet.ibm.com>
      Cc: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
      Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b881bc46
  3. 20 12月, 2012 3 次提交
  4. 17 12月, 2012 1 次提交
  5. 14 12月, 2012 1 次提交
  6. 13 12月, 2012 1 次提交
  7. 12 12月, 2012 1 次提交
  8. 11 12月, 2012 2 次提交
  9. 06 12月, 2012 1 次提交
  10. 05 12月, 2012 1 次提交
  11. 03 12月, 2012 5 次提交
  12. 01 12月, 2012 7 次提交
  13. 30 11月, 2012 3 次提交
  14. 29 11月, 2012 4 次提交
  15. 28 11月, 2012 1 次提交
  16. 23 11月, 2012 2 次提交
    • S
      s390/ccwgroup: allow drivers to call set_{on,off}line · 683c3dce
      Sebastian Ott 提交于
      Allow drivers to enable/disable ccwgroup devices.
      Acked-by: NPeter Oberparleiter <peter.oberparleiter@de.ibm.com>
      Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      683c3dce
    • C
      s390/kvm: Fix address space mixup · ce6a04ac
      Christian Borntraeger 提交于
      I was chasing down a bug of random validity intercepts on s390.
      (guest prefix page not mapped in the host virtual aspace). Turns out
      that the problem was a wrong address space control element. The
      cause was quite complex:
      
      During paging activity a DAT protection during SIE caused a program
      interrupt. Normally, the sie retry loop tries to catch all
      interrupts during and shortly before sie to rerun the setup. The
      problem is now that protection causes a suppressing program interrupt,
      causing the PSW to point to the instruction AFTER SIE in case of DAT
      protection. This confused the logic of the retry loop to not trigger,
      instead we jumped directly back to SIE after return from
      the program  interrupt. (the protection fault handler itself did
      a rewind of the psw). This usually works quite well, but:
      
      If now the protection fault handler has to wait, another program
      might be scheduled in. Later on the sie process will be schedules
      in again. In that case the content of CR1 (primary address space)
      will be wrong because switch_to will put the user space ASCE into CR1
      and not the guest ASCE.
      
      In addition the program parameter is also wrong for every protection
      fault of a guest, since we dont issue the SPP instruction.
      
      So lets also check for PSW == instruction after SIE in the program
      check handler. Instead of expensively checking all program
      interruption codes that might be suppressing we assume that a program
      interrupt pointing after SIE was always a program interrupt in SIE.
      (Otherwise we have a kernel bug anyway).
      
      We also have to compensate the rewinding, since the C-level handlers
      will do that. Therefore we need to add a nop with the same length
      as SIE before the sie_loop.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      CC: stable@vger.kernel.org
      CC: Heiko Carstens <heiko.carstens@de.ibm.com>
      ce6a04ac