- 13 Sep, 2014 15 commits
-
-
Bjorn Helgaas authored
There's not really a good way to determine whether firmware has already configured a device with _HPP/_HPX settings. On legacy systems, the BIOS has probably configured everything, but on UEFI systems it is not required to do so. Per the PCI Firmware Specification, rev 3.1, sec 3.5, if PCI_COMMAND_IO or PCI_COMMAND_MEMORY is set, we can assume firmware has set the corresponding BARs and maybe we can assume it has configured the rest of the device. And if a bridge has PCI_COMMAND_PARITY or PCI_COMMAND_SERR set, we can assume firmware has configured the bridge. But we can't tell much about devices without BARs. I think it should be safe to apply _HPP and _HPX settings anyway, even if firmware has already configured the device, so configure everything we find. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Bjorn Helgaas authored
Linux manages MPS and MRRS settings to keep them consistent across the PCIe fabric. BIOS doesn't participate in this Linux management, so ignore that part of any _HPX settings it supplies. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Bjorn Helgaas authored
We currently apply _HPP settings only to: - non-bridge devices, and - PCI-to-PCI bridges i.e., we do not apply them to PCI-to-ISA bridges and the like. It has been that way since _HPP support was added by 40abb96c ("pciehp: Fix programming hotplug parameters"), but I don't think there's any reason to exclude these other bridges. Apply _HPP settings to hot-added PCI devices of any type. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Bjorn Helgaas authored
Do not clear PCI_COMMAND_SERR or PCI_COMMAND_PARITY based on _HPP. The spec (ACPI rev 5.0, sec 6.2.7) says that when "Enable SERR" is set to 1, we should enable SERR in the command register. It says nothing about *disabling* SERR or PERR; in fact, the example in 6.2.7.1 says we should leave PERR alone unless "Enable PERR" is 1. For hot-added devices, this probably doesn't matter because they power up with these bits cleared. But in addition to hot-plugged devices, the spec allows the platform to use _HPP for "configuration of PCI devices not configured by the BIOS at system boot," and it may make a difference for devices present at boot. This change means that if BIOS enables SERR or PERR on a device, and it supplies _HPP or _HPX with the SERR or PERR bits *cleared*, we will now leave SERR or PERR reporting enabled on that device instead of disabling it as we previously did. See also 40abb96c ("pciehp: Fix programming hotplug parameters"), where this code was first added. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Bjorn Helgaas authored
The ACPI _HPP method was defined before PCIe existed, so its documentation only mentions PCI. The _HPX Type 0 setting record is essentially identical to _HPP, but the spec (ACPI rev 5.0, sec 6.2.8.1) says it should be applied to PCI, PCI-X, and PCIe devices, with settings being ignored if they are not applicable. Some platforms with both conventional PCI and PCIe devices provide only _HPP (not _HPX), so treat _HPP the same way as an _HPX Type 0 record and apply it to PCIe devices as well as PCI and PCI-X. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Bjorn Helgaas authored
All pci_configure_slot() uses have been removed, so remove the definition as well. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Bjorn Helgaas authored
We now configure each PCI device as it is enumerated, in pci_device_add(), so remove the configuration done in acpiphp. That configuration, in pci_configure_device(), does not include the MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep that here. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Bjorn Helgaas authored
We now configure each PCI device as it is enumerated, in pci_device_add(), so remove the configuration done in shpchp. That configuration, in pci_configure_device(), does not include the MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep that here. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Bjorn Helgaas authored
We now configure each PCI device as it is enumerated, in pci_device_add(), so remove the configuration done in pciehp. That configuration, in pci_configure_device(), does not include the MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep that here. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Bjorn Helgaas authored
Some platforms can tell the OS how to configure PCI devices, e.g., how to set cache line size, error reporting enables, etc. ACPI defines _HPP and _HPX methods for this purpose. This configuration was previously done by some of the hotplug drivers using pci_configure_slot(). But not all hotplug drivers did this, and per the spec (ACPI rev 5.0, sec 6.2.7), we can also do it for "devices not configured by the BIOS at system boot." Move this configuration into the PCI core by adding pci_configure_device() and calling it from pci_device_add(), so we do this for all devices as we enumerate them. This is based on pci_configure_slot(), which is used by hotplug drivers. I omitted: - pcie_bus_configure_settings() because it configures MPS and MRRS, which requires global knowledge of the fabric and must be done later, and - configuration of subordinate devices; that will happen when we call pci_device_add() for those devices. Because pci_configure_slot() was only done by hotplug drivers, this initial version of pci_configure_device() only configures hot-added devices, ignoring anything added during boot. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
Bjorn Helgaas authored
Move pci_configure_slot() and related functions from drivers/pci/hotplug/pcihp_slot to drivers/pci/probe.c. This is to prepare for doing device configuration during the normal enumeration process instead of just after hot-add. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Bjorn Helgaas authored
Move code around to put all the ACPI power management stuff together and all the pieces related to ACPI methods (_CBA, _HPP, _HPX) together. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Bjorn Helgaas authored
Whitespace fixes only; no functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Bjorn Helgaas authored
Move pci_get_hp_params() and related functions from drivers/pci/hotplug/acpi_pcihp.c to drivers/pci/pci-acpi.c. Previously, pci_get_hp_params() was used only by hotplug drivers. But future changes will move this into the normal device enumeration process, so it will be used even when CONFIG_HOTPLUG_PCI is not set. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Bjorn Helgaas authored
We configure cache line size and other settings of hot-added devices, e.g., based on ACPI _HPP or _HPX methods. Previously we skipped this for display devices, but ACPI rev 5.0, sec 6.2.7 and 6.2.8 have no requirement to skip them. Remove the check so we configure display devices the same way we configure other devices. See also ac81860e ("PCI: hotplug: pciehp: Removed check for hotplug of display devices"). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
- 12 Sep, 2014 1 commit
-
-
Bjorn Helgaas authored
We print way too many messages like this: pci 0000:00:00.0: no hotplug settings from platform pci 0000:00:00.0: using default PCI settings This usually happens when the platform doesn't supply an ACPI _HPP method, but the method is optional, so there's no point in warning about it. Not only are the messages useless, but we call pci_configure_slot() far too many times, so they're repeated many times. I'll fix the overuse of pci_configure_slot() too, but that will wait until the next merge window. For now, just remove both log messages. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84391Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
-
- 25 Aug, 2014 5 commits
-
-
Linus Torvalds authored
-
git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds authored
Pull NFS client fixes from Trond Myklebust: "Highlights: - more fixes for read/write codepath regressions * sleeping while holding the inode lock * stricter enforcement of page contiguity when coalescing requests * fix up error handling in the page coalescing code - don't busy wait on SIGKILL in the file locking code" * tag 'nfs-for-3.17-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: nfs: Don't busy-wait on SIGKILL in __nfs_iocounter_wait nfs: can_coalesce_requests must enforce contiguity nfs: disallow duplicate pages in pgio page vectors nfs: don't sleep with inode lock in lock_and_join_requests nfs: fix error handling in lock_and_join_requests nfs: use blocking page_group_lock in add_request nfs: fix nonblocking calls to nfs_page_group_lock nfs: change nfs_page_group_lock argument
-
Linus Torvalds authored
Merge tag 'renesas-sh-drivers-for-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas Pull SH driver fix from Simon Horman: "Confine SH_INTC to platforms that need it" * tag 'renesas-sh-drivers-for-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: sh: intc: Confine SH_INTC to platforms that need it
-
git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds authored
Pull MIPS fixes from Ralf Baechle: "Pretty much all across the field so with this we should be in reasonable shape for the upcoming -rc2" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: OCTEON: make get_system_type() thread-safe MIPS: CPS: Initialize EVA before bringing up VPEs from secondary cores MIPS: Malta: EVA: Rename 'eva_entry' to 'platform_eva_init' MIPS: EVA: Add new EVA header MIPS: scall64-o32: Fix indirect syscall detection MIPS: syscall: Fix AUDIT value for O32 processes on MIPS64 MIPS: Loongson: Fix COP2 usage for preemptible kernel MIPS: NL: Fix nlm_xlp_defconfig build error MIPS: Remove race window in page fault handling MIPS: Malta: Improve system memory detection for '{e, }memsize' >= 2G MIPS: Alchemy: Fix db1200 PSC clock enablement MIPS: BCM47XX: Fix reboot problem on BCM4705/BCM4785 MIPS: Remove duplicated include from numa.c MIPS: Add common plat_irq_dispatch declaration MIPS: MSP71xx: remove unused plat_irq_dispatch() argument MIPS: GIC: Remove useless parens from GICBIS(). MIPS: perf: Mark pmu interupt IRQF_NO_THREAD
-
Linus Torvalds authored
Merge tag 'trace-fixes-v3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull fix for ftrace function tracer/profiler conflict from Steven Rostedt: "The rewrite of the ftrace code that makes it possible to allow for separate trampolines had a design flaw with the interaction between the function and function_graph tracers. The main flaw was the simplification of the use of multiple tracers having the same filter (like function and function_graph, that use the set_ftrace_filter file to filter their code). The design assumed that the two tracers could never run simultaneously as only one tracer can be used at a time. The problem with this assumption was that the function profiler could be implemented on top of the function graph tracer, and the function profiler could run at the same time as the function tracer. This caused the assumption to be broken and when ftrace detected this failed assumpiton it would spit out a nasty warning and shut itself down. Instead of using a single ftrace_ops that switches between the function and function_graph callbacks, the two tracers can again use their own ftrace_ops. But instead of having a complex hierarchy of ftrace_ops, the filter fields are placed in its own structure and the ftrace_ops can carefully use the same filter. This change took a bit to be able to allow for this and currently only the global_ops can share the same filter, but this new design can easily be modified to allow for any ftrace_ops to share its filter with another ftrace_ops. The first four patches deal with the change of allowing the ftrace_ops to share the filter (and this needs to go to 3.16 as well). The fifth patch fixes a bug that was also caused by the new changes but only for archs other than x86, and only if those archs implement a direct call to the function_graph tracer which they do not do yet but will in the future. It does not need to go to stable, but needs to be fixed before the other archs update their code to allow direct calls to the function_graph trampoline" * tag 'trace-fixes-v3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: ftrace: Use current addr when converting to nop in __ftrace_replace_code() ftrace: Fix function_profiler and function tracer together ftrace: Fix up trampoline accounting with looping on hash ops ftrace: Update all ftrace_ops for a ftrace_hash_ops update ftrace: Allow ftrace_ops to use the hashes from other ops
-
- 24 Aug, 2014 12 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Ingo Molnar: "A couple of EFI fixes, plus misc fixes all around the map" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/arm64: Store Runtime Services revision firmware: Do not use WARN_ON(!spin_is_locked()) x86_32, entry: Clean up sysenter_badsys declaration x86/doc: Fix the 'tlb_single_page_flush_ceiling' sysconfig path x86/mm: Fix sparse 'tlb_single_page_flush_ceiling' warning and make the variable read-mostly x86/mm: Fix RCU splat from new TLB tracepoints
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Ingo Molnar: "A kprobes and a perf compat ioctl fix" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Handle compat ioctl kprobes: Skip kretprobe hit in NMI context to avoid deadlock
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
Pull ARM SoC fixes from Olof Johansson: "A collection of fixes from this week, it's been pretty quiet and nothing really stands out as particularly noteworthy here -- mostly minor fixes across the field: - ODROID booting was fixed due to PMIC interrupts missing in DT - a collection of i.MX fixes - minor Tegra fix for regulators - Rockchip fix and addition of SoC-specific mailing list to make it easier to find posted patches" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: bus: arm-ccn: Fix warning message ARM: shmobile: koelsch: Remove non-existent i2c6 pinmux ARM: tegra: apalis/colibri t30: fix on-module 5v0 supplies MAINTAINERS: add new Rockchip SoC list ARM: dts: rockchip: readd missing mmc0 pinctrl settings ARM: dts: ODROID i2c improvements ARM: dts: Enable PMIC interrupts on ODROID ARM: dts: imx6sx: fix the pad setting for uart CTS_B ARM: dts: i.MX53: fix apparent bug in VPU clks ARM: imx: correct gpu2d_axi and gpu3d_axi clock setting ARM: dts: imx6: edmqmx6: change enet reset pin ARM: dts: vf610-twr: Fix pinctrl_esdhc1 pin definitions. ARM: imx: remove unnecessary ARCH_HAS_OPP select ARM: imx: fix TLB missing of IOMUXC base address during suspend ARM: imx6: fix SMP compilation again ARM: dt: sun6i: Add #address-cells and #size-cells to i2c controller nodes
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioLinus Torvalds authored
Pull gpio fixes from Linus Walleij: - a largeish fix for the IRQ handling in the new Zynq driver. The quite verbose commit message gives the exact details. - move some defines for gpiod flags outside an ifdef to make stub functions work again. - various minor fixes that we can accept for -rc1. * tag 'gpio-v3.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio-lynxpoint: enable input sensing in resume gpio: move GPIOD flags outside #ifdef gpio: delete unneeded test before of_node_put gpio: zynq: Fix IRQ handlers gpiolib: devres: use correct structure type name in sizeof MAINTAINERS: Change maintainer for gpio-bcm-kona.c
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Intel and radeon fixes. Post KS/LC git requests from i915 and radeon stacked up. They are all fixes along with some new pci ids for radeon, and one maintainers file entry. - i915: display fixes and irq fixes - radeon: pci ids, and misc gpuvm, dpm and hdp cache" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (29 commits) MAINTAINERS: Add entry for Renesas DRM drivers drm/radeon: add additional SI pci ids drm/radeon: add new bonaire pci ids drm/radeon: add new KV pci id Revert "drm/radeon: Use write-combined CPU mappings of ring buffers with PCIe" drm/radeon: fix active_cu mask on SI and CIK after re-init (v3) drm/radeon: fix active cu count for SI and CIK drm/radeon: re-enable selective GPUVM flushing drm/radeon: Sync ME and PFP after CP semaphore waits v4 drm/radeon: fix display handling in radeon_gpu_reset drm/radeon: fix pm handling in radeon_gpu_reset drm/radeon: Only flush HDP cache for indirect buffers from userspace drm/radeon: properly document reloc priority mask drm/i915: don't try to retrain a DP link on an inactive CRTC drm/i915: make sure VDD is turned off during system suspend drm/i915: cancel hotplug and dig_port work during suspend and unload drm/i915: fix HPD IRQ reenable work cancelation drm/i915: take display port power domain in DP HPD handler drm/i915: Don't try to enable cursor from setplane when crtc is disabled drm/i915: Skip load detect when intel_crtc->new_enable==true ...
-
Benjamin LaHaise authored
As reported by Dan Aloni, commit f8567a38 ("aio: fix aio request leak when events are reaped by userspace") introduces a regression when user code attempts to perform io_submit() with more events than are available in the ring buffer. Reverting that commit would reintroduce a regression when user space event reaping is used. Fixing this bug is a bit more involved than the previous attempts to fix this regression. Since we do not have a single point at which we can count events as being reaped by user space and io_getevents(), we have to track event completion by looking at the number of events left in the event ring. So long as there are as many events in the ring buffer as there have been completion events generate, we cannot call put_reqs_available(). The code to check for this is now placed in refill_reqs_available(). A test program from Dan and modified by me for verifying this bug is available at http://www.kvack.org/~bcrl/20140824-aio_bug.c . Reported-by: Dan Aloni <dan@kernelim.com> Signed-off-by: Benjamin LaHaise <bcrl@kvack.org> Acked-by: Dan Aloni <dan@kernelim.com> Cc: Kent Overstreet <kmo@daterainc.com> Cc: Mateusz Guzik <mguzik@redhat.com> Cc: Petr Matousek <pmatouse@redhat.com> Cc: stable@vger.kernel.org # v3.16 and anything that f8567a38 was backported to Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Pawel Moll authored
A message warning a user about wrong vc value was printing out port instead. Reported-by: Drew Richardson <drew.richardson@arm.com> Signed-off-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net>
-
Geert Uytterhoeven authored
On r8a7791, i2c6 (aka iic3) doesn't need pinmux, but the koelsch dts refers to non-existent pinmux configuration data: pinmux core: sh-pfc does not support function i2c6 sh-pfc e6060000.pfc: invalid function i2c6 in map table Remove it to fix this. Fixes: commit 1d41f36a ("ARM: shmobile: koelsch dts: Add VDD MPU regulator for DVFS") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Olof Johansson <olof@lixom.net>
-
Marcel Ziswiler authored
Working on Gigabit/PCIe support in U-Boot for Apalis T30 I realised that the current device tree source includes for our modules only happen to work due to referencing the on-carrier 5v0 supply from USB which is not at all available on-module. The modules actually contain TPS60150 charge pumps to generate the PMIC required 5 volts from the one and only 3.3 volt module supply. This patch fixes this. (Note: When back-porting this to v3.16 stable releases, simply drop the change to tegra30-apalis.dtsi; that file was added in v3.17) Cc: <stable@vger.kernel.org> #v3.16+ Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
-
Olof Johansson authored
Merge tag 'v3.17-rockchip-fixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into fixes Merge "ARM: rockchip: fix for 3.17" from Heiko Stubner: Pinctrl that got accidentially dropped when reorganizing the dts files and addition of the new Rockchip list to MAINTAINERS. * tag 'v3.17-rockchip-fixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: MAINTAINERS: add new Rockchip SoC list ARM: dts: rockchip: readd missing mmc0 pinctrl settings Signed-off-by: Olof Johansson <olof@lixom.net>
-
Laurent Pinchart authored
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@gmail.com>
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
This pull just contains some new pci ids. * 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: add additional SI pci ids drm/radeon: add new bonaire pci ids drm/radeon: add new KV pci id
-
- 23 Aug, 2014 5 commits
-
-
Heiko Stuebner authored
Add the new list that Rockchip-specific patches should also be directed to. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Heiko Stuebner authored
During the restructuring of the Rockchip Cortex-A9 dtsi files it seems like the pinctrl settings vanished at some point from the mmc0 support. This of course renders them unusable, so readd the necessary pinctrl properties. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Olof Johansson authored
Merge tag 'sunxi-dt-for-3.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into fixes Merge "Allwinner DT changes, take 2" from Maxime Ripard: Only a single patch in here that fixes a DTC warning. * tag 'sunxi-dt-for-3.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux: ARM: dt: sun6i: Add #address-cells and #size-cells to i2c controller nodes Signed-off-by: Olof Johansson <olof@lixom.net>
-
Steven Rostedt (Red Hat) authored
In __ftrace_replace_code(), when converting the call to a nop in a function it needs to compare against the "curr" (current) value of the ftrace ops, and not the "new" one. It currently does not affect x86 which is the only arch to do the trampolines with function graph tracer, but when other archs that do depend on this code implement the function graph trampoline, it can crash. Here's an example when ARM uses the trampolines (in the future): ------------[ cut here ]------------ WARNING: CPU: 0 PID: 9 at kernel/trace/ftrace.c:1716 ftrace_bug+0x17c/0x1f4() Modules linked in: omap_rng rng_core ipv6 CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.16.0-test-10959-gf0094b28-dirty #52 [<c02188f4>] (unwind_backtrace) from [<c021343c>] (show_stack+0x20/0x24) [<c021343c>] (show_stack) from [<c095a674>] (dump_stack+0x78/0x94) [<c095a674>] (dump_stack) from [<c02532a0>] (warn_slowpath_common+0x7c/0x9c) [<c02532a0>] (warn_slowpath_common) from [<c02532ec>] (warn_slowpath_null+0x2c/0x34) [<c02532ec>] (warn_slowpath_null) from [<c02cbac4>] (ftrace_bug+0x17c/0x1f4) [<c02cbac4>] (ftrace_bug) from [<c02cc44c>] (ftrace_replace_code+0x80/0x9c) [<c02cc44c>] (ftrace_replace_code) from [<c02cc658>] (ftrace_modify_all_code+0xb8/0x164) [<c02cc658>] (ftrace_modify_all_code) from [<c02cc718>] (__ftrace_modify_code+0x14/0x1c) [<c02cc718>] (__ftrace_modify_code) from [<c02c7244>] (multi_cpu_stop+0xf4/0x134) [<c02c7244>] (multi_cpu_stop) from [<c02c6e90>] (cpu_stopper_thread+0x54/0x130) [<c02c6e90>] (cpu_stopper_thread) from [<c0271cd4>] (smpboot_thread_fn+0x1ac/0x1bc) [<c0271cd4>] (smpboot_thread_fn) from [<c026ddf0>] (kthread+0xe0/0xfc) [<c026ddf0>] (kthread) from [<c020f318>] (ret_from_fork+0x14/0x20) ---[ end trace dc9ce72c5b617d8f ]--- [ 65.047264] ftrace failed to modify [<c0208580>] asm_do_IRQ+0x10/0x1c [ 65.054070] actual: 85:1b:00:eb Fixes: 7413af1f "ftrace: Make get_ftrace_addr() and get_ftrace_addr_old() global" Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
-
Steven Rostedt (Red Hat) authored
The latest rewrite of ftrace removed the separate ftrace_ops of the function tracer and the function graph tracer and had them share the same ftrace_ops. This simplified the accounting by removing the multiple layers of functions called, where the global_ops func would call a special list that would iterate over the other ops that were registered within it (like function and function graph), which itself was registered to the ftrace ops list of all functions currently active. If that sounds confusing, the code that implemented it was also confusing and its removal is a good thing. The problem with this change was that it assumed that the function and function graph tracer can never be used at the same time. This is mostly true, but there is an exception. That is when the function profiler uses the function graph tracer to profile. The function profiler can be activated the same time as the function tracer, and this breaks the assumption and the result is that ftrace will crash (it detects the error and shuts itself down, it does not cause a kernel oops). To solve this issue, a previous change allowed the hash tables for the functions traced by a ftrace_ops to be a pointer and let multiple ftrace_ops share the same hash. This allows the function and function_graph tracer to have separate ftrace_ops, but still share the hash, which is what is done. Now the function and function graph tracers have separate ftrace_ops again, and the function tracer can be run while the function_profile is active. Cc: stable@vger.kernel.org # 3.16 (apply after 3.17-rc4 is out) Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
-
- 22 Aug, 2014 2 commits
-
-
David Jeffery authored
If a SIGKILL is sent to a task waiting in __nfs_iocounter_wait, it will busy-wait or soft lockup in its while loop. nfs_wait_bit_killable won't sleep, and the loop won't exit on the error return. Stop the busy-wait by breaking out of the loop when nfs_wait_bit_killable returns an error. Signed-off-by: David Jeffery <djeffery@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
-
Weston Andros Adamson authored
Commit 6094f838 "nfs: allow coalescing of subpage requests" got rid of the requirement that requests cover whole pages, but it made some incorrect assumptions. It turns out that callers of this interface can map adjacent requests (by file position as seen by req_offset + req->wb_bytes) to different pages, even when they could share a page. An example is the direct I/O interface - iov_iter_get_pages_alloc may return one segment with a partial page filled and the next segment (which is adjacent in the file position) starts with a new page. Reported-by: Toralf Förster <toralf.foerster@gmx.de> Signed-off-by: Weston Andros Adamson <dros@primarydata.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
-