- 14 Sep, 2016 1 commit
-
-
Bryant G. Ly authored
BugLink: http://bugs.launchpad.net/bugs/1615665 The driver currently doesn't properly deregisters target sessions completely, so this will address that. Signed-off-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Signed-off-by:
Michael Cyr <mikecyr@linux.vnet.ibm.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com>
-
- 08 Sep, 2016 1 commit
-
-
Mauricio Faria de Oliveira authored
BugLink: http://bugs.launchpad.net/bugs/1618151 This patch leverages 'struct pci_host_bridge' from the PCI subsystem in order to free the pci_controller only after the last reference to its devices is dropped (avoiding an oops in pcibios_release_device() if the last reference is dropped after pcibios_free_controller()). The patch relies on pci_host_bridge.release_fn() (and .release_data), which is called automatically by the PCI subsystem when the root bus is released (i.e., the last reference is dropped). Those fields are set via pci_set_host_bridge_release() (e.g. in the platform-specific implementation of pcibios_root_bridge_prepare()). It introduces the 'pcibios_free_controller_deferred()' .release_fn() and it expects .release_data to hold a pointer to the pci_controller. The function implictly calls 'pcibios_free_controller()', so an user must *NOT* explicitly call it if using the new _deferred() callback. The functionality is enabled for pseries (although it isn't platform specific, and may be used by cxl). Details on not-so-elegant design choices: - Use 'pci_host_bridge.release_data' field as pointer to associated 'struct pci_controller' so *not* to 'pci_bus_to_host(bridge->bus)' in pcibios_free_controller_deferred(). That's because pci_remove_root_bus() sets 'host_bridge->bus = NULL' (so, if the last reference is released after pci_remove_root_bus() runs, which eventually reaches pcibios_free_controller_deferred(), that would hit a null pointer dereference). The cxl/vphb.c code calls pci_remove_root_bus(), and the cxl folks are interested in this fix. Test-case #1 (hold references) # ls -ld /sys/block/sd* | grep -m1 0021:01:00.0 <...> /sys/block/sdaa -> ../devices/pci0021:01/0021:01:00.0/<...> # ls -ld /sys/block/sd* | grep -m1 0021:01:00.1 <...> /sys/block/sdab -> ../devices/pci0021:01/0021:01:00.1/<...> # cat >/dev/sdaa & pid1=$! # cat >/dev/sdab & pid2=$! # drmgr -w 5 -d 1 -c phb -s 'PHB 33' -r Validating PHB DLPAR capability...yes. [ 594.306719] pci_hp_remove_devices: PCI: Removing devices on bus 0021:01 [ 594.306738] pci_hp_remove_devices: Removing 0021:01:00.0... ... [ 598.236381] pci_hp_remove_devices: Removing 0021:01:00.1... ... [ 611.972077] pci_bus 0021:01: busn_res: [bus 01-ff] is released [ 611.972140] rpadlpar_io: slot PHB 33 removed # kill -9 $pid1 # kill -9 $pid2 [ 632.918088] pcibios_free_controller_deferred: domain 33, dynamic 1 Test-case #2 (don't hold references) # drmgr -w 5 -d 1 -c phb -s 'PHB 33' -r Validating PHB DLPAR capability...yes. [ 916.357363] pci_hp_remove_devices: PCI: Removing devices on bus 0021:01 [ 916.357386] pci_hp_remove_devices: Removing 0021:01:00.0... ... [ 920.566527] pci_hp_remove_devices: Removing 0021:01:00.1... ... [ 933.955873] pci_bus 0021:01: busn_res: [bus 01-ff] is released [ 933.955977] pcibios_free_controller_deferred: domain 33, dynamic 1 [ 933.955999] rpadlpar_io: slot PHB 33 removed Suggested-By:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Reviewed-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> # cxl Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> (cherry picked from commit 2dd9c11b) Signed-off-by:
Chris J Arges <chris.j.arges@canonical.com>
-
- 06 Sep, 2016 8 commits
-
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1617550 Building fuse as a module fails because this symbol is not exported. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1572630 queue_for_each_ctx() iterates over per_cpu variables under the assumption that the possible cpu mask cannot have holes. That's wrong as all cpumasks can have holes. In case there are holes the iteration ends up accessing uninitialized memory and crashing as a result. Replace the macro by a proper for_each_possible_cpu() loop and drop the unused macro blk_ctx_sum() which references queue_for_each_ctx(). Reported-by:
Xiong Zhou <jencce.kernel@gmail.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Jens Axboe <axboe@fb.com> (back ported from commit 897bb0c7) Signed-off-by:
-
Raghavendra K T authored
BugLink: http://bugs.launchpad.net/bugs/1572630 hctx->cpumask is already populated and let the tag cpumask follow that instead of going through a new for loop. Signed-off-by:
Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> Reviewed-by:
Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
Eric Desrochers <eric.desrochers@canonical.com> Acked-by:
-
Tim Gardner authored
Ignore: yes Signed-off-by: -
Tim Gardner authored
Signed-off-by: -
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1612135 Seth Forshee reported a mount regression in nfs autmounts with "fs: Add user namespace member to struct super_block". It turns out that the assumption that current->cred is something reasonable during mount while necessary to improve support of unprivileged mounts is wrong in the automount path. To fix the existing filesystems override current->cred with the init_cred before calling d_automount and restore current->cred after d_automount completes. To support unprivileged mounts would require a more nuanced cred selection, so fail on unprivileged mounts for the time being. As none of the filesystems that currently set FS_USERNS_MOUNT implement d_automount this check is only good for preventing future problems. Fixes: 6e4eab57 ("fs: Add user namespace member to struct super_block") Tested-by:
"Eric W. Biederman" <ebiederm@xmission.com> (backported from commit aeaa4a79) Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Colin King <colin.king@canonical.com> Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1612135 This reverts commit d15123a5 in order to replace it with the more generic upstream fix. Signed-off-by:
-
Andy Whitcroft authored
The Ubuntu backport of the below commit necessarily had to follow the changes to is_ovl_whiteout. In the process the wrong dentry was passed preventing correct detection of legacy whitouts in a rename over a whitout on some upper filesystem types (at least ramfs): commit 11f37104 Author: Miklos Szeredi <mszeredi@redhat.com> Date: Mon Mar 21 17:31:44 2016 +0100 ovl: verify upper dentry before unlink and rename Pass the correct dentry to allow detection of the appropriate whiteout types. Fixes: 11f37104 ("ovl: verify upper dentry before unlink and rename") in Ubuntu BugLink: http://bugs.launchpad.net/bugs/1618572Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
-
- 30 Aug, 2016 1 commit
-
-
Tim Gardner authored
Ignore: yes Signed-off-by:
-
- 29 Aug, 2016 29 commits
-
-
Tim Gardner authored
Signed-off-by: -
Adrian Hunter authored
BugLink: http://bugs.launchpad.net/bugs/1591655 Previous patches added support for Intel's AVX-512 instructions to the kernel and perf tools instruction decoders. AVX-512 instructions are documented in Intel Architecture Instruction Set Extensions Programming Reference (February 2016). Add a representative set of instructions to perf's "new instructions" test. e.g. perf test "new instructions" Or to view a particular instruction: perf test -v "new instructions" 2>&1 | grep vbroadcasti64x4 Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Acked-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
Masami Hiramatsu <mhiramat@kernel.org> Tested-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dan Williams <dan.j.williams@intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: X86 ML <x86@kernel.org> Link: http://lkml.kernel.org/r/1469003437-32706-5-git-send-email-adrian.hunter@intel.comSigned-off-by:
-
Adrian Hunter authored
BugLink: http://bugs.launchpad.net/bugs/1591655 Add support for Intel's AVX-512 instructions to perf tools instruction decoder used by Intel PT. The kernel's instruction decoder was updated in a previous patch. AVX-512 instructions are documented in Intel Architecture Instruction Set Extensions Programming Reference (February 2016). AVX-512 instructions are identified by a EVEX prefix which, for the purpose of instruction decoding, can be treated as though it were a 4-byte VEX prefix. Existing instructions which can now accept an EVEX prefix need not be further annotated in the op code map (x86-opcode-map.txt). In the case of new instructions, the op code map is updated accordingly. Also add associated Mask Instructions that are used to manipulate mask registers used in AVX-512 instructions. A representative set of instructions is added to the perf tools new instructions test in a subsequent patch. Signed-off-by:
-
Adrian Hunter authored
BugLink: http://bugs.launchpad.net/bugs/1591655 Add support for Intel's AVX-512 instructions to the instruction decoder. AVX-512 instructions are documented in Intel Architecture Instruction Set Extensions Programming Reference (February 2016). AVX-512 instructions are identified by a EVEX prefix which, for the purpose of instruction decoding, can be treated as though it were a 4-byte VEX prefix. Existing instructions which can now accept an EVEX prefix need not be further annotated in the op code map (x86-opcode-map.txt). In the case of new instructions, the op code map is updated accordingly. Also add associated Mask Instructions that are used to manipulate mask registers used in AVX-512 instructions. The 'perf tools' instruction decoder is updated in a subsequent patch. And a representative set of instructions is added to the perf tools new instructions test in a subsequent patch. Signed-off-by:
-
Adrian Hunter authored
BugLink: http://bugs.launchpad.net/bugs/1591655 vcvtph2ps does not have an immediate operand, so remove the erroneous 'Ib' from its opcode map entry. Add vcvtph2ps to the perf tools new instructions test to verify it. Signed-off-by:
-
James Smart authored
BugLink: http://bugs.launchpad.net/bugs/1608652 Correct issue with ioremap() call on 32bit kernel Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <james.smart@broadcom.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit 115a4124) Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 SKX has a lot in common with HSX Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit ec53e594) Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 Hard-code BXT ART to 19200MHz, so turbostat --debug can fully enumerate TSC: CPUID(0x15): eax_crystal: 3 ebx_tsc: 186 ecx_crystal_hz: 0 TSC: 1190 MHz (19200000 Hz * 186 / 3 / 1000000) Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 Broxton has a lot in common with SKL Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 Some processors use the Interrupt Response Time Limit (IRTL) MSR value to describe the maximum IRQ response time latency for deep package C-states. (Though others have the register, but do not use it) Lets print it out to give insight into the cases where it is used. IRTL begain in SNB, with PC3/PC6/PC7, and HSW added PC8/PC9/PC10. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 The CPUID.SGX bit was printed, even if --debug was used Signed-off-by:
-
Chen Yu authored
BugLink: http://bugs.launchpad.net/bugs/1591802 MSR_CONFIG_TDP_NOMINAL: should print all 8 bits of base_ratio (bit 0:7) 0xFF MSR_CONFIG_TDP_LEVEL_1: should print all 15 bits of PKG_MIN_PWR_LVL1 (bit 48:62) 0x7FFF should print all 15 bits of PKG_MAX_PWR_LVL1 (bit 32:46) 0x7FFF should print all 8 bits of LVL1_RATIO (bit 16:23) 0xFF should print all 15 bits of PKG_TDP_LVL1 (bit 0:14) 0x7FFF And the same modification to MSR_CONFIG_TDP_LEVEL_2. MSR_TURBO_ACTIVATION_RATIO: should print all 8 bits of MAX_NON_TURBO_RATIO (bit 0:7) 0xFF Signed-off-by:
Chen Yu <yu.c.chen@intel.com> Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x1e008008 (...pkg-cstate-limit=0: unlimited) should print as MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x1e008008 (...pkg-cstate-limit=8: unlimited) Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 turbostat already checks whether calling each cpuid leavf is legal, and it doesn't look at the function return value, so call the simpler gcc intrinsic __cpuid() instead of __get_cpuid(). syntax only, no functional change Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 SGX presence is related to a SKL power workaround, so lets show when that is enabled. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 The accuracy of Bzy_Mhz and Busy% depend on reading the TSC, APERF, and MPERF close together in time. When there is a very short measurement interval, or a large system is profoundly idle, the changes in APERF and MPERF may be very small. They can be small enough that an expensive interrupt between reading APERF and MPERF can cause the APERF/MPERF ratio to become inaccurate, resulting in invalid calculation and display of Bzy_MHz. A dummy APERF read of APERF makes this problem much more rare. Apparently this 1st systemn call after exiting a long stretch of idle is when we typically see expensive timer interrupts that cause large jitter. For the cases that dummy APERF read fails to prevent, we compare the latency of the APERF and MPERF reads. If they differ by more than 2x, we re-issue them. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 The column "GFX%c6" show the percentage of time the GPU is in the "render C6" state, rc6. Deep package C-states on several systems depend on the GPU being in RC6. This information comes from the counter /sys/class/drm/card0/power/rc6_residency_ms, as read before and after the measurement interval. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 Under the column "GFXMHz", show a snapshot of this attribute: /sys/class/graphics/fb0/device/drm/card0/gt_cur_freq_mhz This is an instantaneous snapshot of what sysfs presents at the end of the measurement interval. turbostat does not average or otherwise perform any math on this value. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 The new IRQ column shows how many interrupts have occurred on each CPU during the measurement inteval. This information comes from the difference between /proc/interrupts shapshots made before and after the measurement interval. The first row, the system summary, shows the sum of the IRQS for all CPUs during that interval. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 skip the open(2)/close(2) on each msr read by keeping the /dev/cpu/*/msr files open. The remaining read(2) is generally far fewer cycles than the removed open(2) system call. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 By default... Turbostat --debug gconfiguration info goes to stderr. In FORK mode, turbostat statistics go to stderr. In PERIODIC mode, turbostat statistics go to stdout. These defaults do not change, but an option "--out file" will send all output above only to the specified file. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 some tools processing turbostat output have difficulty with items that begin with %... Reported-by:
Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by:
-
Hubert Chrzaniuk authored
BugLink: http://bugs.launchpad.net/bugs/1591802 Following changes have been made: - changed MSR_NHM_TURBO_RATIO_LIMIT to MSR_TURBO_RATIO_LIMIT in debug print for consistency with Developer Manual - updated definition of bitfields in MSR_TURBO_RATIO_LIMIT and appropriate parsing code - added x200 to list of architectures that do not support Nahlem compatible definition of MSR_TURBO_RATIO_LIMIT register (x200 has the register but bits definition is custom) - fixed typo in code that parses MSR_TURBO_RATIO_LIMIT (logical instead of bitwise operator) - changed MSR_TURBO_RATIO_LIMIT parsing algorithm so the print out had the same order as implementations for other platforms Signed-off-by:
Hubert Chrzaniuk <hubert.chrzaniuk@intel.com> Signed-off-by:
-
Chrzaniuk, Hubert authored
BugLink: http://bugs.launchpad.net/bugs/1591802 x200 does not enable any way to programmatically obtain bus clock speed. Bclk for the architecture has a fixed value of 100 MHz. At the same time x200 cannot be included in has_snb_msrs since it does not support C7 idle state. prior to this patch, MHz values reported on this chip were erroneously calculated using bclk of 133MHz, causing MHz values to be reported 33% higher than actual. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 turbostat -i interval_sec will sample and display statistics every interval_sec. interval_sec used to be a whole number of seconds, but now we accept a decimal, as small as 0.001 sec (1 ms). Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 This MSR is helpful to show if P-state HW coordination is enabled or disabled. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 # turbostat --debug ... CPUID(6): ... HWP, HWPnotify, HWPwindow, HWPepp, HWPpkg ... ... cpu0: MSR_PM_ENABLE: 0x00000001 (HWP) cpu0: MSR_HWP_CAPABILITIES: 0x01050916 (high 0x16 guar 0x9 eff 0x5 low 0x1) cpu0: MSR_HWP_REQUEST: 0x80001604 (min 0x4 max 0x16 des 0x0 epp 0x80 window 0x0 pkg 0x0) cpu0: MSR_HWP_INTERRUPT: 0x00000001 (EN_Guaranteed_Perf_Change, Dis_Excursion_Min) cpu0: MSR_HWP_STATUS: 0x00000000 (No-Guaranteed_Perf_Change, No-Excursion_Min) Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 This CPUID leaf is available on Skylake: CPUID(0x16): base_mhz: 1500 max_mhz: 2200 bus_mhz: 100 Signed-off-by:
-
