1. 13 Jun, 2016 1 commit
    • Heiko Carstens's avatar
      s390/cpuinfo: show dynamic and static cpu mhz · 097a116c
      Heiko Carstens authored
      Show the dynamic and static cpu mhz of each cpu. Since these values
      are per cpu this requires a fundamental extension of the format of
      Historically we had only a single line per cpu and a summary at the
      top of the file. This format is hardly extendible if we want to add
      more per cpu information.
      Therefore this patch adds per cpu blocks at the end of /proc/cpuinfo:
      cpu             : 0
      cpu Mhz dynamic : 5504
      cpu Mhz static  : 5504
      cpu             : 1
      cpu Mhz dynamic : 5504
      cpu Mhz static  : 5504
      cpu             : 2
      cpu Mhz dynamic : 5504
      cpu Mhz static  : 5504
      cpu             : 3
      cpu Mhz dynamic : 5504
      cpu Mhz static  : 5504
      Right now each block contains only the dynamic and static cpu mhz,
      but it can be easily extended like on every other architecture.
      This extension is supposed to be compatible with the old format.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Acked-by: default avatarSascha Silbe <silbe@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
  2. 10 May, 2016 1 commit
  3. 28 Jul, 2015 1 commit
    • Heiko Carstens's avatar
      s390/cachinfo: add missing facility check to init_cache_level() · 0b991f5c
      Heiko Carstens authored
      Stephen Powell reported the following crash on a z890 machine:
      Kernel BUG at 00000000001219d0 [verbose debug info unavailable]
      illegal operation: 0001 ilc:3 [#1] SMP
      Krnl PSW : 0704e00180000000 00000000001219d0 (init_cache_level+0x38/0xe0)
      	   R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 EA:3
      Krnl Code: 00000000001219c2: a7840056		brc	8,121a6e
      	   00000000001219c6: a7190000		lghi	%r1,0
      	  #00000000001219ca: eb101000004c	ecag	%r1,%r0,0(%r1)
      	  >00000000001219d0: a7390000		lghi	%r3,0
      	   00000000001219d4: e310f0a00024	stg	%r1,160(%r15)
      	   00000000001219da: a7080000		lhi	%r0,0
      	   00000000001219de: a7b9f000		lghi	%r11,-4096
      	   00000000001219e2: c0a0002899d9	larl	%r10,634d94
      Call Trace:
       [<0000000000478ee2>] detect_cache_attributes+0x2a/0x2b8
       [<000000000097c9b0>] cacheinfo_sysfs_init+0x60/0xc8
       [<00000000001001c0>] do_one_initcall+0x98/0x1c8
       [<000000000094fdc2>] kernel_init_freeable+0x212/0x2d8
       [<000000000062352e>] kernel_init+0x26/0x118
       [<000000000062fd2e>] kernel_thread_starter+0x6/0xc
      The illegal operation was executed because of a missing facility check,
      which should have made sure that the ECAG execution would only be executed
      on machines which have the general-instructions-extension facility
      Reported-and-tested-by: default avatarStephen Powell <zlinuxman@wowway.com>
      Cc: stable@vger.kernel.org # v4.0+
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
  4. 13 Apr, 2015 1 commit
  5. 12 Feb, 2015 2 commits
  6. 10 Feb, 2015 1 commit
  7. 08 Jan, 2015 1 commit
  8. 20 Mar, 2014 1 commit
    • Srivatsa S. Bhat's avatar
      s390, cacheinfo: Fix CPU hotplug callback registration · 6575080e
      Srivatsa S. Bhat authored
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      Instead, the correct and race-free way of performing the callback
      registration is:
      	/* Note the use of the double underscored version of the API */
      Fix the cacheinfo code in s390 by using this latter form of callback
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  9. 24 Oct, 2013 1 commit
  10. 14 Jul, 2013 1 commit
    • Paul Gortmaker's avatar
      s390: delete __cpuinit usage from all s390 files · e2741f17
      Paul Gortmaker authored
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      are flagged as __cpuinit  -- so if we remove the __cpuinit from
      arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      content into no-ops as early as possible, since that will get rid
      of these warnings.  In any case, they are temporary and harmless.
      This removes all the arch/s390 uses of the __cpuinit macros from
      all C files.  Currently s390 does not have any __CPUINIT used in
      assembly files.
      [1] https://lkml.org/lkml/2013/5/20/589
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: linux390@de.ibm.com
      Cc: linux-s390@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
  11. 18 Oct, 2012 1 commit
  12. 26 Sep, 2012 2 commits
    • Heiko Carstens's avatar
      s390/cache: add cpu cache information to /proc/cpuinfo · 6668022c
      Heiko Carstens authored
      Add a line for each cpu cache to /proc/cpuinfo.
      Since we only have information of private cpu caches in sysfs we
      add a line for each cpu cache in /proc/cpuinfo which will also
      contain information about shared caches.
      For a z196 machine /proc/cpuinfo now looks like:
      vendor_id       : IBM/S390
      bogomips per cpu: 14367.00
      features        : esan3 zarch stfle msa ldisp eimm dfp etf3eh highgprs
      cache0          : level=1 type=Data scope=Private size=64K line_size=256 associativity=4
      cache1          : level=1 type=Instruction scope=Private size=128K line_size=256 associativity=8
      cache2          : level=2 type=Unified scope=Private size=1536K line_size=256 associativity=12
      cache3          : level=3 type=Unified scope=Shared size=24576K line_size=256 associativity=12
      cache4          : level=4 type=Unified scope=Shared size=196608K line_size=256 associativity=24
      processor 0: version = FF,  identification = 000123,  machine = 2817
      processor 1: version = FF,  identification = 100123,  machine = 2817
      processor 2: version = FF,  identification = 200123,  machine = 2817
      processor 3: version = FF,  identification = 200123,  machine = 2817
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
    • Heiko Carstens's avatar
      s390/cache: expose cpu cache topology via sysfs · 881730ad
      Heiko Carstens authored
      Expose cpu cache topology via sysfs.
      The created sysfs directory structure is compatible to what x86, ia64
      and powerpc have.
      On s390 we expose only information about cpu caches which are private
      to a cpu via sysfs . Caches which are shared between cpus do not have
      a sysfs representation.
      The reason for that is that the file "shared_cpu_map" is mandatory
      and only if running under LPAR it is possible to tell which cpus
      share which cache. Second level hypervisors however do not and cannot
      expose that information to guests.
      In order to have a consistent view we made the choice to always only
      expose information about private cpu caches via sysfs.
      Example for a z196 cpu (cpu1 in /sys/devices/cpu):
      cpu1/cache/index0/size -- 64K
      cpu1/cache/index0/type -- Data
      cpu1/cache/index0/level -- 1
      cpu1/cache/index0/number_of_sets -- 64
      cpu1/cache/index0/shared_cpu_map -- 00000000,00000002
      cpu1/cache/index0/shared_cpu_list -- 1
      cpu1/cache/index0/coherency_line_size -- 256
      cpu1/cache/index0/ways_of_associativity -- 4
      cpu1/cache/index1/size -- 128K
      cpu1/cache/index1/type -- Instruction
      cpu1/cache/index1/level -- 1
      cpu1/cache/index1/number_of_sets -- 64
      cpu1/cache/index1/shared_cpu_map -- 00000000,00000002
      cpu1/cache/index1/shared_cpu_list -- 1
      cpu1/cache/index1/coherency_line_size -- 256
      cpu1/cache/index1/ways_of_associativity -- 8
      cpu1/cache/index2/size -- 1536K
      cpu1/cache/index2/type -- Unified
      cpu1/cache/index2/level -- 2
      cpu1/cache/index2/number_of_sets -- 512
      cpu1/cache/index2/shared_cpu_map -- 00000000,00000002
      cpu1/cache/index2/shared_cpu_list -- 1
      cpu1/cache/index2/coherency_line_size -- 256
      cpu1/cache/index2/ways_of_associativity -- 12
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>