1. 02 Mar, 2017 1 commit
  2. 07 Mar, 2016 1 commit
  3. 18 Dec, 2015 2 commits
  4. 27 Nov, 2015 2 commits
  5. 11 Nov, 2015 1 commit
  6. 03 Nov, 2015 1 commit
  7. 27 Oct, 2015 1 commit
    • Heiko Carstens's avatar
      s390/nmi: remove casts · dc6e1555
      Heiko Carstens authored
      Remove all the casts to and from the machine check interruption code.
      This patch changes struct mci to a union, which contains an anonymous
      structure with the already known bits and in addition an unsigned
      long field, which contains the raw machine check interruption code.
      
      This allows to simply assign and decoce the interruption code value
      without the need for all those casts we had all the time.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      dc6e1555
  8. 25 Mar, 2015 1 commit
    • Heiko Carstens's avatar
      s390: remove 31 bit support · 5a79859a
      Heiko Carstens authored
      Remove the 31 bit support in order to reduce maintenance cost and
      effectively remove dead code. Since a couple of years there is no
      distribution left that comes with a 31 bit kernel.
      
      The 31 bit kernel also has been broken since more than a year before
      anybody noticed. In addition I added a removal warning to the kernel
      shown at ipl for 5 minutes: a960062e ("s390: add 31 bit warning
      message") which let everybody know about the plan to remove 31 bit
      code. We didn't get any response.
      
      Given that the last 31 bit only machine was introduced in 1999 let's
      remove the code.
      Anybody with 31 bit user space code can still use the compat mode.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      5a79859a
  9. 22 Jan, 2015 1 commit
    • Martin Schwidefsky's avatar
      s390: add SMT support · 10ad34bc
      Martin Schwidefsky authored
      The multi-threading facility is introduced with the z13 processor family.
      This patch adds code to detect the multi-threading facility. With the
      facility enabled each core will surface multiple hardware threads to the
      system. Each hardware threads looks like a normal CPU to the operating
      system with all its registers and properties.
      
      The SCLP interface reports the SMT topology indirectly via the maximum
      thread id. Each reported CPU in the result of a read-scp-information
      is a core representing a number of hardware threads.
      
      To reflect the reduced CPU capacity if two hardware threads run on a
      single core the MT utilization counter set is used to normalize the
      raw cputime obtained by the CPU timer deltas. This scaled cputime is
      reported via the taskstats interface. The normal /proc/stat numbers
      are based on the raw cputime and are not affected by the normalization.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      10ad34bc
  10. 09 Oct, 2014 1 commit
  11. 26 Aug, 2014 1 commit
  12. 10 Jun, 2014 1 commit
    • Sebastian Ott's avatar
      s390/cio: silence lockdep warning · dbe33fc9
      Sebastian Ott authored
      On systems where a ccw based console device is used a lockdep false alarm
      could be triggered when a device driver calls printk while holding a
      subchannels lock (e.g. in it's irq handler). Since this is valid behavior
      fix this by introducing a separate lock class for the console subchannels
      lock.
      
      The lockdep warning was revealed by "printk: enable interrupts before calling
      console_trylock_for_printk()" which changed console_unlock() to be called with
      lockdep enabled.
      
      [ INFO: possible recursive locking detected ]
      3.15.0-rc5-next-20140520 #1 Not tainted
      ---------------------------------------------
      ccwgroup/2239 is trying to acquire lock:
      (&(sch->lock)->rlock){-.-...}, at: [<0000000000642a52>] raw3215_write+0x52/0x200
      
      but task is already holding lock:
      (&(sch->lock)->rlock){-.-...}, at: [<00000000005fd160>] do_cio_interrupt+0x60/0x108
      
      other info that might help us debug this:
      Possible unsafe locking scenario:
      
      CPU0
      ----
      lock(&(sch->lock)->rlock);
      lock(&(sch->lock)->rlock);
      
      *** DEADLOCK ***
      
      May be due to missing lock nesting notation
      
      8 locks held by ccwgroup/2239:
      
      stack backtrace:
      CPU: 3 PID: 2239 Comm: ccwgroup Not tainted 3.15.0-rc5-next-20140520 #1
      0000000036fab518 0000000036fab528 0000000000000002 0000000000000000
      0000000036fab5b8 0000000036fab530 0000000036fab530 00000000001116e8
      0000000000000000 0000000000986ec4 00000000009701b6 000000000000000b
      0000000036fab578 0000000036fab518 0000000000000000 0000000000000000
      0000000000000000 00000000001116e8 0000000036fab518 0000000036fab578
      Call Trace:
      ([<0000000000111626>] show_trace+0x14e/0x158)
      [<000000000011169a>] show_stack+0x6a/0xe8
      [<00000000007c6e72>] dump_stack+0x82/0xb0
      [<00000000001a95f2>] validate_chain.isra.37+0xa4a/0xbb0
      [<00000000001acaca>] __lock_acquire+0x4da/0xcd0
      [<00000000001ada1a>] lock_acquire+0xba/0x218
      [<00000000007cd634>] _raw_spin_lock_irqsave+0x6c/0xb8
      [<0000000000642a52>] raw3215_write+0x52/0x200
      [<0000000000643d16>] con3215_write+0x76/0xf8
      [<00000000001bd87a>] call_console_drivers.constprop.25+0xfa/0x210
      [<00000000001be0b0>] console_unlock+0x3e0/0x4e8
      [<00000000001be450>] vprintk_emit+0x298/0x6e0
      [<00000000005aa210>] dev_vprintk_emit+0xe0/0x1a8
      [<00000000005aa320>] dev_printk_emit+0x48/0x50
      [<00000000005aa390>] __dev_printk+0x68/0xb0
      [<00000000005aa7c2>] _dev_info+0x62/0x70
      [<0000000000657bf0>] qeth_l2_send_setmac_cb+0xd0/0x190
      [<0000000000651a1e>] qeth_send_control_data_cb+0x3a6/0x6a8
      [<0000000000655546>] qeth_irq+0x1a6/0xac0
      [<000000000060a0ac>] ccw_device_call_handler+0xa4/0xc0
      [<0000000000608b62>] ccw_device_irq+0x5a/0x190
      [<00000000005fd1ca>] do_cio_interrupt+0xca/0x108
      [<00000000001c0a2e>] handle_irq_event_percpu+0x5e/0x378
      [<00000000001c46fc>] handle_percpu_irq+0x6c/0x98
      [<00000000001c0066>] generic_handle_irq+0x46/0x68
      [<000000000010b5b6>] do_IRQ+0x5e/0x88
      [<00000000007cf304>] io_call+0x6/0x20
      [<000000000064c63a>] qeth_send_control_data+0x322/0x570
      ([<000000000064c50e>] qeth_send_control_data+0x1f6/0x570)
      [<0000000000651db2>] qeth_send_ipa_cmd+0x92/0x120
      [<000000000065b310>] __qeth_l2_set_online+0x170/0xaa8
      [<000000000060ebb6>] ccwgroup_set_online+0x56/0x90
      [<000000000060ef96>] ccwgroup_online_store+0xd6/0xe0
      [<000000000033d11a>] kernfs_fop_write+0x10a/0x188
      [<00000000002bbd00>] vfs_write+0x98/0x1c0
      [<00000000002bc8a0>] SyS_write+0x60/0xd0
      [<00000000007cee3a>] sysc_nr_ok+0x22/0x28
      [<000003fffd0c3f28>] 0x3fffd0c3f28
      Reported-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      dbe33fc9
  13. 28 May, 2014 1 commit
  14. 13 Mar, 2014 1 commit
    • Frederic Weisbecker's avatar
      cputime: Default implementation of nsecs -> cputime conversion · bfc3f028
      Frederic Weisbecker authored
      The architectures that override cputime_t (s390, ppc) don't provide
      any version of nsecs_to_cputime(). Indeed this cputime_t implementation
      by backend only happens when CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y under
      which the core code doesn't make any use of nsecs_to_cputime().
      
      At least for now.
      
      We are going to make a broader use of it so lets provide a default
      version with a per usecs granularity. It should be good enough for most
      usecases.
      
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      bfc3f028
  15. 04 Mar, 2014 2 commits
    • Thomas Gleixner's avatar
      s390: Do not rely on magic indirect includes · 257ceab7
      Thomas Gleixner authored
      commit: 8f945a33 (genirq: Move kstat_incr_irqs_this_cpu() to core)
      unearthed the following:
      
         arch/s390/kernel/irq.c: In function 'init_IRQ':
      >> arch/s390/kernel/irq.c:93:2: error: implicit declaration of function 'irq_reserve_irqs'
      [-Werror=implicit-function-declaration]
      ....
         cc1: some warnings being treated as errors
      --
         drivers/s390/cio/cio.c: In function 'init_cio_interrupts':
      >> drivers/s390/cio/cio.c:594:2: error: implicit declaration of function
      'irq_set_chip_and_handler' [-Werror=implicit-function-declaration]
      [-Werror=implicit-function-declaration]
      ....
         cc1: some warnings being treated as errors
      
      The reason is that those files require linux/irq.h and magically
      pulled that in via linux/kernel_stat.h
      
      The commit above got rid of the pointless include of linux/irq.h in
      linux/kernel_stat.h and therefor broke the build.
      
      Include linux/irq.h
      
      Reported-by: fengguang.wu@intel.com
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: s390 <linux-s390@vger.kernel.org>
      257ceab7
    • Thomas Gleixner's avatar
      s390: Cio: Use the core irq stats function · bc5dfcff
      Thomas Gleixner authored
      Let the core do the irq_desc resolution.
      
      No functional change.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: s390 <linux-s390@vger.kernel.org>
      Link: http://lkml.kernel.org/r/20140223212737.983433636@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      bc5dfcff
  16. 21 Feb, 2014 1 commit
    • Sebastian Ott's avatar
      s390: improve debug feature usage · f7e1e65d
      Sebastian Ott authored
      The maximum usable buffer size of the s390 debug feature (when using
      the sprintf_view) is 11 * sizeof(long) (1 pointer for the format
      string + 10 arguments). When a larger buffer size is specified the
      additional memory is unused and wasted per debug entry. So reducing
      the buffer size to its maximum (or to the actual buffer size used)
      will make more precious debug feature space usable.
      
      For pci_msg, chsc_msg, and cio_crw we use the additional usable dbf
      space to reduce the number of allocated pages.
      Signed-off-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      f7e1e65d
  17. 06 Feb, 2014 1 commit
  18. 22 Oct, 2013 1 commit
    • Martin Schwidefsky's avatar
      s390/time: correct use of store clock fast · 8c071b0f
      Martin Schwidefsky authored
      The result of the store-clock-fast (STCKF) instruction is a bit fuzzy.
      It can happen that the value stored on one CPU is smaller than the value
      stored on another CPU, although the order of the stores is the other
      way around. This can cause deltas of get_tod_clock() values to become
      negative when they should not be.
      
      We need to be more careful with store-clock-fast, this patch partially
      reverts git commit e4b7b4238e666682555461fa52eecd74652f36bb "time:
      always use stckf instead of stck if available". The get_tod_clock()
      function now uses the store-clock-extended (STCKE) instruction.
      get_tod_clock_fast() can be used if the fuzziness of store-clock-fast
      is acceptable e.g. for wait loops local to a CPU.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      8c071b0f
  19. 22 Aug, 2013 1 commit
    • Martin Schwidefsky's avatar
      s390: convert interrupt handling to use generic hardirq · 1f44a225
      Martin Schwidefsky authored
      With the introduction of PCI it became apparent that s390 should
      convert to generic hardirqs as too many drivers do not have the
      correct dependency for GENERIC_HARDIRQS. On the architecture
      level s390 does not have irq lines. It has external interrupts,
      I/O interrupts and adapter interrupts. This patch hard-codes all
      external interrupts as irq #1, all I/O interrupts as irq #2 and
      all adapter interrupts as irq #3. The additional information from
      the lowcore associated with the interrupt is stored in the
      pt_regs of the interrupt frame, where the interrupt handler can
      pick it up. For PCI/MSI interrupts the adapter interrupt handler
      scans the relevant bit fields and calls generic_handle_irq with
      the virtual irq number for the MSI interrupt.
      Reviewed-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      1f44a225
  20. 26 Jun, 2013 1 commit
  21. 26 Apr, 2013 1 commit
  22. 17 Apr, 2013 4 commits
  23. 14 Feb, 2013 1 commit
  24. 08 Jan, 2013 2 commits
    • Heiko Carstens's avatar
      s390/irq: remove split irq fields from /proc/stat · 420f42ec
      Heiko Carstens authored
      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: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      420f42ec
    • Heiko Carstens's avatar
      s390/irq: enable irq sum accounting for /proc/stat again · add9bde2
      Heiko Carstens authored
      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: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      add9bde2
  25. 26 Sep, 2012 1 commit
  26. 20 Jul, 2012 1 commit
    • Heiko Carstens's avatar
      s390/comments: unify copyright messages and remove file names · a53c8fab
      Heiko Carstens authored
      Remove the file name from the comment at top of many files. In most
      cases the file name was wrong anyway, so it's rather pointless.
      
      Also unify the IBM copyright statement. We did have a lot of sightly
      different statements and wanted to change them one after another
      whenever a file gets touched. However that never happened. Instead
      people start to take the old/"wrong" statements to use as a template
      for new files.
      So unify all of them in one go.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      a53c8fab
  27. 16 May, 2012 1 commit
  28. 11 Mar, 2012 1 commit
    • Martin Schwidefsky's avatar
      [S390] rework idle code · 4c1051e3
      Martin Schwidefsky authored
      Whenever the cpu loads an enabled wait PSW it will appear as idle to the
      underlying host system. The code in default_idle calls vtime_stop_cpu
      which does the necessary voodoo to get the cpu time accounting right.
      The udelay code just loads an enabled wait PSW. To correct this rework
      the vtime_stop_cpu/vtime_start_cpu logic and move the difficult parts
      to entry[64].S, vtime_stop_cpu can now be called from anywhere and
      vtime_start_cpu is gone. The correction of the cpu time during wakeup
      from an enabled wait PSW is done with a critical section in entry[64].S.
      As vtime_start_cpu is gone, s390_idle_check can be removed as well.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      4c1051e3
  29. 30 Oct, 2011 2 commits
  30. 26 Sep, 2011 1 commit
  31. 15 Mar, 2011 2 commits