- 06 Aug, 2014 40 commits
-
-
Takashi Iwai authored
commit 4320f6b1 upstream. The commit [247bc037: PM / Sleep: Mitigate race between the freezer and request_firmware()] introduced the finer state control, but it also leads to a new bug; for example, a bug report regarding the firmware loading of intel BT device at suspend/resume: https://bugzilla.novell.com/show_bug.cgi?id=873790 The root cause seems to be a small window between the process resume and the clear of usermodehelper lock. The request_firmware() function checks the UMH lock and gives up when it's in UMH_DISABLE state. This is for avoiding the invalid f/w loading during suspend/resume phase. The problem is, however, that usermodehelper_enable() is called at the end of thaw_processes(). Thus, a thawed process in between can kick off the f/w loader code path (in this case, via btusb_setup_intel()) even before the call of usermodehelper_enable(). Then usermodehelper_read_trylock() returns an error and request_firmware() spews WARN_ON() in the end. This oneliner patch fixes the issue just by setting to UMH_FREEZING state again before restarting tasks, so that the call of request_firmware() will be blocked until the end of this function instead of returning an error. Fixes: 247bc037 (PM / Sleep: Mitigate race between the freezer and request_firmware()) Link: https://bugzilla.novell.com/show_bug.cgi?id=873790Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Sasha Levin authored
commit 3cf521f7 upstream. The l2tp [get|set]sockopt() code has fallen back to the UDP functions for socket option levels != SOL_PPPOL2TP since day one, but that has never actually worked, since the l2tp socket isn't an inet socket. As David Miller points out: "If we wanted this to work, it'd have to look up the tunnel and then use tunnel->sk, but I wonder how useful that would be" Since this can never have worked so nobody could possibly have depended on that functionality, just remove the broken code and return -EINVAL. Reported-by:
Sasha Levin <sasha.levin@oracle.com> Acked-by:
James Chapman <jchapman@katalix.com> Acked-by:
David Miller <davem@davemloft.net> Cc: Phil Turnbull <phil.turnbull@oracle.com> Cc: Vegard Nossum <vegard.nossum@oracle.com> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Axel Lin authored
commit 6b00f440 upstream. Dashes are not allowed in hwmon name attributes. Use "da9055" instead of "da9055-hwmon". Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Axel Lin authored
commit ee14b644 upstream. Dashes are not allowed in hwmon name attributes. Use "da9052" instead of "da9052-hwmon". Signed-off-by:
-
Benjamin LaHaise authored
commit 263782c1 upstream. As of commit f8567a38 it is now possible to have put_reqs_available() called from irq context. While put_reqs_available() is per cpu, it did not protect itself from interrupts on the same CPU. This lead to aio_complete() corrupting the available io requests count when run under a heavy O_DIRECT workloads as reported by Robert Elliott. Fix this by disabling irq updates around the per cpu batch updates of reqs_available. Many thanks to Robert and folks for testing and tracking this down. Reported-by:
Robert Elliot <Elliott@hp.com> Tested-by:
Benjamin LaHaise <bcrl@kvack.org> Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Guenter Roeck authored
commit aff008ad upstream. Commits 9ec36caf (of/irq: do irq resolution in platform_get_irq) and ad69674e (of/irq: do irq resolution in platform_get_irq_byname) change the semantics of platform_get_irq and platform_get_irq_byname to always rely on devicetree information if devicetree is enabled and if a devicetree node is attached to the device. The functions now return an error if the devicetree data does not include interrupt information, even if the information is available as platform resource data. This causes mfd client drivers to fail if the interrupt number is passed via platform resources. Therefore, if of_irq_get fails, try platform_get_resource as method of last resort. This restores the original functionality for drivers depending on platform resources to get irq information. Cc: Russell King <linux@arm.linux.org.uk> Cc: Tony Lindgren <tony@atomide.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Grygorii Strashko authored
commit ad69674e upstream. The commit 9ec36caf "of/irq: do irq resolution in platform_get_irq" from Rob Herring - moves resolving of the interrupt resources in platform_get_irq(). But this solution isn't complete because platform_get_irq_byname() need to be modified the same way. Hence, fix it by adding interrupt resolution code at the platform_get_irq_byname() function too. Cc: Russell King <linux@arm.linux.org.uk> Cc: Rob Herring <robh@kernel.org> Cc: Tony Lindgren <tony@atomide.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Grant Likely <grant.likely@linaro.org> Signed-off-by:
-
Srinivas Pandruvada authored
commit 78b33216 upstream. When event spec is shared by multiple channels, which has definition for mask_shared_by_type, iio_device_register_eventset fails. For example: static const struct iio_event_spec iio_dummy_events[] = { { .type = IIO_EV_TYPE_THRESH, .dir = IIO_EV_DIR_RISING, .mask_separate = BIT(IIO_EV_INFO_ENABLE), .mask_shared_by_type = BIT(IIO_EV_INFO_VALUE), }, { .type = IIO_EV_TYPE_THRESH, .dir = IIO_EV_DIR_FALLING, .mask_separate = BIT(IIO_EV_INFO_ENABLE),a .mask_shared_by_type = BIT(IIO_EV_INFO_VALUE), } }; If two channels use this event spec, this will result in error. This change handles EBUSY error similar to iio_device_add_info_mask_type(). Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Stefan Assmann authored
commit 76252723 upstream. To properly re-initialize SR-IOV it is necessary to reset the device even if it is already down. Not doing this may result in Tx unit hangs. Signed-off-by:
Stefan Assmann <sassmann@kpanic.de> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Michael Brown authored
commit c7fb93ec upstream. The PE/COFF headers currently describe only the initialised-data portions of the image, and result in no space being allocated for the uninitialised-data portions. Consequently, the EFI boot stub will end up overwriting unexpected areas of memory, with unpredictable results. Fix by including a .bss section in the PE/COFF headers (functionally equivalent to the init_size field in the bzImage header). Signed-off-by:
Michael Brown <mbrown@fensystems.co.uk> Cc: Thomas Bächler <thomas@archlinux.org> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> [ luis: backported to 3.11: used Michael's backport ] Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
-
Todd Fujinaka authored
commit 94826487 upstream. On some devices, the internal PLL circuit occasionally provides the wrong clock frequency after power up. The probability of failure is less than one failure per 1000 power cycles. When the failure occurs, the internal clock frequency is around 1/20 of the correct frequency. Signed-off-by:
Todd Fujinaka <todd.fujinaka@intel.com> Tested-by:
-
Thomas Fitzsimmons authored
commit 0a198587 upstream. This commit fixes the command value generated for CSUM calculation when running in big endian mode. The Ethernet protocol ID for IP was being unconditionally byte-swapped in the layer 3 protocol check (with swab16), which caused the mvneta driver to not function correctly in big endian mode. This patch byte-swaps the ID conditionally with htons. Signed-off-by:
Thomas Fitzsimmons <fitzsim@fitzsim.org> Signed-off-by:
-
Thomas Petazzoni authored
commit 4d12bc63 upstream. As reported by Maggie Mae Roxas, the mvneta driver doesn't behave properly in 10 Mbit/s mode. This is due to a misconfiguration of the MVNETA_GMAC_AUTONEG_CONFIG register: bit MVNETA_GMAC_CONFIG_MII_SPEED must be set for a 100 Mbit/s speed, but cleared for a 10 Mbit/s speed, which the driver was not properly doing. This commit adjusts that by setting the MVNETA_GMAC_CONFIG_MII_SPEED bit only in 100 Mbit/s mode, and relying on the fact that all the speed related bits of this register are cleared at the beginning of the mvneta_adjust_link() function. This problem exists since c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP network unit") which is the commit that introduced the mvneta driver in the kernel. Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP network unit") Reported-by:
Maggie Mae Roxas <maggie.mae.roxas@gmail.com> Cc: Maggie Mae Roxas <maggie.mae.roxas@gmail.com> Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
-
Matthias Brugger authored
commit a97e8027 upstream. Patch 0a68214b "ARM: DT: Add binding for GIC virtualization extentions (VGIC)" added the "arm,cortex-a7-gic" compatible string, but the corresponding IRQCHIP_DECLARE was never added to the gic driver. To let real Cortex-A7 SoCs use it, add the necessary declaration to the device driver. Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Link: https://lkml.kernel.org/r/1404388732-28890-1-git-send-email-matthias.bgg@gmail.com Fixes: 0a68214b ("ARM: DT: Add binding for GIC virtualization extentions (VGIC)") Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
John Stultz authored
commit 16927776 upstream. Sharvil noticed with the posix timer_settime interface, using the CLOCK_REALTIME_ALARM or CLOCK_BOOTTIME_ALARM clockid, if the users tried to specify a relative time timer, it would incorrectly be treated as absolute regardless of the state of the flags argument. This patch corrects this, properly checking the absolute/relative flag, as well as adds further error checking that no invalid flag bits are set. Reported-by:
Sharvil Nanavati <sharvil@google.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Sharvil Nanavati <sharvil@google.com> Link: http://lkml.kernel.org/r/1404767171-6902-1-git-send-email-john.stultz@linaro.orgSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Miklos Szeredi authored
commit 233a01fa upstream. If the number in "user_id=N" or "group_id=N" mount options was larger than INT_MAX then fuse returned EINVAL. Fix this to handle all valid uid/gid values. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
Anand Avati authored
commit 154210cc upstream. The following test case demonstrates the bug: sh# mount -t glusterfs localhost:meta-test /mnt/one sh# mount -t glusterfs localhost:meta-test /mnt/two sh# echo stuff > /mnt/one/file; rm -f /mnt/two/file; echo stuff > /mnt/one/file bash: /mnt/one/file: Stale file handle sh# echo stuff > /mnt/one/file; rm -f /mnt/two/file; sleep 1; echo stuff > /mnt/one/file On the second open() on /mnt/one, FUSE would have used the old nodeid (file handle) trying to re-open it. Gluster is returning -ESTALE. The ESTALE propagates back to namei.c:filename_lookup() where lookup is re-attempted with LOOKUP_REVAL. The right behavior now, would be for FUSE to ignore the entry-timeout and and do the up-call revalidation. Instead FUSE is ignoring LOOKUP_REVAL, succeeding the revalidation (because entry-timeout has not passed), and open() is again retried on the old file handle and finally the ESTALE is going back to the application. Fix: if revalidation is happening with LOOKUP_REVAL, then ignore entry-timeout and always do the up-call. Signed-off-by:
Anand Avati <avati@redhat.com> Reviewed-by:
Niels de Vos <ndevos@redhat.com> Signed-off-by:
-
Miklos Szeredi authored
commit 126b9d43 upstream. As suggested by checkpatch.pl, use time_before64() instead of direct comparison of jiffies64 values. Signed-off-by:
-
Ted Juan authored
commit 6938ad40 upstream. These two function's switch case lack the 'break' that make them always return error. Signed-off-by:
Ted Juan <ted.juan@gmail.com> Acked-by:
Pekon Gupta <pekon@ti.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
David Vrabel authored
commit fb9a0c44 upstream. Since cd9151e2 (xen/balloon: set a mapping for ballooned out pages), a ballooned out page had its entry in the p2m set to the MFN of one of the scratch pages. This means that the p2m will contain many entries pointing to the same MFN. During a domain save, these many-to-one entries are not identified as such and the scratch page is saved multiple times. On restore the ballooned pages are populated with new frames and the domain may use up its allocation before all pages can be restored. Since the original fix only needed to keep a mapping for the ballooned page it is safe to set ballooned out pages as INVALID_P2M_ENTRY in the p2m (as they were before). Thus preventing them from being saved and re-populated on restore. Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Reported-by:
Marek Marczykowski <marmarek@invisiblethingslab.com> Tested-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit dc271ee0 upstream. Firmware folks seem say that this flag can make trouble. Drop it. The advantage of CTS to self is that it slightly reduces the cost of the protection, but make the protection less reliable. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> [ kamal: backport to 3.13-stable (context) ] Signed-off-by:
-
Emmanuel Grumbach authored
commit 43d826ca upstream. We should always prefer to use full RTS protection. Using CTS to self gives a meaningless improvement, but this flow is much harder for the firmware which is likely to have issues with it. Signed-off-by:
-
David Vrabel authored
commit 1b647823 upstream. Calling xen_console_resume() in xen_suspend() causes a warning because it locks irq_mapping_update_lock (a mutex) and this may sleep. If a userspace process is using the evtchn device then this mutex may be locked at the point of the stop_machine() call and xen_console_resume() would then deadlock. Resuming the console after stop_machine() returns avoids this deadlock. Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
Jiri Olsa authored
commit 1f9a7268 upstream. The context check in perf_event_context_sched_out allows non-cloned context to be part of the optimized schedule out switch. This could move non-cloned context into another workload child. Once this child exits, the context is closed and leaves all original (parent) events in closed state. Any other new cloned event will have closed state and not measure anything. And probably causing other odd bugs. Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1403598026-2310-2-git-send-email-jolsa@kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
HATAYAMA Daisuke authored
commit b292d7a1 upstream. Currently, any NMI is falsely handled by a NMI handler of NMI watchdog if CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR is set. For example, we use external NMI to make system panic to get crash dump, but in this case, the external NMI is falsely handled do to the issue. This commit deals with the issue simply by ignoring CondChgd bit. Here is explanation in detail. On x86 NMI watchdog uses performance monitoring feature to periodically signal NMI each time performance counter gets overflowed. intel_pmu_handle_irq() is called as a NMI_LOCAL handler from a NMI handler of NMI watchdog, perf_event_nmi_handler(). It identifies an owner of a given NMI by looking at overflow status bits in MSR_CORE_PERF_GLOBAL_STATUS MSR. If some of the bits are set, then it handles the given NMI as its own NMI. The problem is that the intel_pmu_handle_irq() doesn't distinguish CondChgd bit from other bits. Unlike the other status bits, CondChgd bit doesn't represent overflow status for performance counters. Thus, CondChgd bit cannot be thought of as a mark indicating a given NMI is NMI watchdog's. As a result, if CondChgd bit is set, any NMI is falsely handled by the NMI handler of NMI watchdog. Also, if type of the falsely handled NMI is either NMI_UNKNOWN, NMI_SERR or NMI_IO_CHECK, the corresponding action is never performed until CondChgd bit is cleared. I noticed this behavior on systems with Ivy Bridge processors: Intel Xeon CPU E5-2630 v2 and Intel Xeon CPU E7-8890 v2. On both systems, CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR has already been set in the beginning at boot. Then the CondChgd bit is immediately cleared by next wrmsr to MSR_CORE_PERF_GLOBAL_CTRL MSR and appears to remain 0. On the other hand, on older processors such as Nehalem, Xeon E7540, CondChgd bit is not set in the beginning at boot. I'm not sure about exact behavior of CondChgd bit, in particular when this bit is set. Although I read Intel System Programmer's Manual to figure out that, the descriptions I found are: In 18.9.1: "The MSR_PERF_GLOBAL_STATUS MSR also provides a ¡sticky bit¢ to indicate changes to the state of performancmonitoring hardware" In Table 35-2 IA-32 Architectural MSRs 63 CondChg: status bits of this register has changed. These are different from the bahviour I see on the actual system as I explained above. At least, I think ignoring CondChgd bit should be enough for NMI watchdog perspective. Signed-off-by:
HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> Acked-by:
Don Zickus <dzickus@redhat.com> Signed-off-by:
-
Peter Zijlstra authored
commit 3896c329 upstream. Mauro reported that his AMD X2 using the powernow-k8 cpufreq driver locked up when doing cpu hotplug. Because we called set_cyc2ns_scale() from the time_cpufreq_notifier() unconditionally, it gets called multiple times for each freq change, instead of only the once, when the tsc_khz value actually changes. Because it gets called more than once, we run out of cyc2ns data slots and stall, waiting for a free one, but because we're half way offline, there's no consumers to free slots. By placing the call inside the condition that actually changes tsc_khz we avoid superfluous calls and avoid the problem. Reported-by:
Mauro <registosites@hotmail.com> Tested-by:
-
Amitkumar Karwar authored
commit d76744a9 upstream. https://bugzilla.kernel.org/show_bug.cgi?id=70191 https://bugzilla.kernel.org/show_bug.cgi?id=77581 It is observed that sometimes Tx packet is downloaded without adding driver's txpd header. This results in firmware parsing garbage data as packet length. Sometimes firmware is unable to read the packet if length comes out as invalid. This stops further traffic and timeout occurs. The root cause is uninitialized fields in tx_info(skb->cb) of packet used to get garbage values. In this case if MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd header was skipped. This patch makes sure that tx_info is correctly initialized to fix the problem. Reported-by:
Andrew Wiley <wiley.andrew.j@gmail.com> Reported-by:
Linus Gasser <list@markas-al-nour.org> Reported-by:
Michael Hirsch <hirsch@teufel.de> Tested-by:
Xinming Hu <huxm@marvell.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Maithili Hinge <maithili@marvell.com> Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Oren Givon authored
commit b3c063ae upstream. Add one more 7265 series HW ID. Edit one existing 7265 series HW ID. Signed-off-by:
Oren Givon <oren.givon@intel.com> Signed-off-by:
-
Loic Poulain authored
commit 48439d50 upstream. When detecting a non-link packet, h5_reset_rx() frees the Rx skb. Not returning after that will cause the upcoming h5_rx_payload() call to dereference a now NULL Rx skb and trigger a kernel oops. Signed-off-by:
Loic Poulain <loic.poulain@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Thomas Gleixner authored
commit 15ebb052 upstream. The control register is at offset 0x10, not 0x0. This is wreckaged since commit 5df33a62 (SPEAr: Switch to common clock framework). Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Mike Turquette <mturquette@linaro.org> Signed-off-by:
-
Helge Deller authored
commit fe22ddcb upstream. Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Helge Deller authored
commit ab8a261b upstream. On parisc we can not use the existing compat implementation for fanotify_mark() because for the 64bit mask parameter the higher and lower 32bits are ordered differently than what the compat function expects from big endian architectures. Specifically: It finally turned out, that on hppa we end up with different assignments of parameters to kernel arguments depending on if we call the glibc wrapper function int fanotify_mark (int __fanotify_fd, unsigned int __flags, uint64_t __mask, int __dfd, const char *__pathname); or directly calling the syscall manually syscall(__NR_fanotify_mark, ...) Reason is, that the syscall() function is implemented as C-function and because we now have the sysno as first parameter in front of the other parameters the compiler will unexpectedly add an empty paramenter in front of the u64 value to ensure the correct calling alignment for 64bit values. This means, on hppa you can't simply use syscall() to call the kernel fanotify_mark() function directly, but you have to use the glibc function instead. This patch fixes the kernel in the hppa-arch specifc coding to adjust the parameters in a way as if userspace calls the glibc wrapper function fanotify_mark(). Signed-off-by:
-
Helge Deller authored
commit eadcc720 upstream. Signed-off-by:
-
Theodore Ts'o authored
commit 3f1f9b85 upstream. This fixes the following lockdep complaint: [ INFO: possible circular locking dependency detected ] 3.16.0-rc2-mm1+ #7 Tainted: G O ------------------------------------------------------- kworker/u24:0/4356 is trying to acquire lock: (&(&sbi->s_es_lru_lock)->rlock){+.+.-.}, at: [<ffffffff81285fff>] __ext4_es_shrink+0x4f/0x2e0 but task is already holding lock: (&ei->i_es_lock){++++-.}, at: [<ffffffff81286961>] ext4_es_insert_extent+0x71/0x180 which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ei->i_es_lock); lock(&(&sbi->s_es_lru_lock)->rlock); lock(&ei->i_es_lock); lock(&(&sbi->s_es_lru_lock)->rlock); *** DEADLOCK *** 6 locks held by kworker/u24:0/4356: #0: ("writeback"){.+.+.+}, at: [<ffffffff81071d00>] process_one_work+0x180/0x560 #1: ((&(&wb->dwork)->work)){+.+.+.}, at: [<ffffffff81071d00>] process_one_work+0x180/0x560 #2: (&type->s_umount_key#22){++++++}, at: [<ffffffff811a9c74>] grab_super_passive+0x44/0x90 #3: (jbd2_handle){+.+...}, at: [<ffffffff812979f9>] start_this_handle+0x189/0x5f0 #4: (&ei->i_data_sem){++++..}, at: [<ffffffff81247062>] ext4_map_blocks+0x132/0x550 #5: (&ei->i_es_lock){++++-.}, at: [<ffffffff81286961>] ext4_es_insert_extent+0x71/0x180 stack backtrace: CPU: 0 PID: 4356 Comm: kworker/u24:0 Tainted: G O 3.16.0-rc2-mm1+ #7 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback bdi_writeback_workfn (flush-253:0) ffffffff8213dce0 ffff880014b07538 ffffffff815df0bb 0000000000000007 ffffffff8213e040 ffff880014b07588 ffffffff815db3dd ffff880014b07568 ffff880014b07610 ffff88003b868930 ffff88003b868908 ffff88003b868930 Call Trace: [<ffffffff815df0bb>] dump_stack+0x4e/0x68 [<ffffffff815db3dd>] print_circular_bug+0x1fb/0x20c [<ffffffff810a7a3e>] __lock_acquire+0x163e/0x1d00 [<ffffffff815e89dc>] ? retint_restore_args+0xe/0xe [<ffffffff815ddc7b>] ? __slab_alloc+0x4a8/0x4ce [<ffffffff81285fff>] ? __ext4_es_shrink+0x4f/0x2e0 [<ffffffff810a8707>] lock_acquire+0x87/0x120 [<ffffffff81285fff>] ? __ext4_es_shrink+0x4f/0x2e0 [<ffffffff8128592d>] ? ext4_es_free_extent+0x5d/0x70 [<ffffffff815e6f09>] _raw_spin_lock+0x39/0x50 [<ffffffff81285fff>] ? __ext4_es_shrink+0x4f/0x2e0 [<ffffffff8119760b>] ? kmem_cache_alloc+0x18b/0x1a0 [<ffffffff81285fff>] __ext4_es_shrink+0x4f/0x2e0 [<ffffffff812869b8>] ext4_es_insert_extent+0xc8/0x180 [<ffffffff812470f4>] ext4_map_blocks+0x1c4/0x550 [<ffffffff8124c4c4>] ext4_writepages+0x6d4/0xd00 ... Reported-by:
Minchan Kim <minchan@kernel.org> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Reported-by:
-
Roger Quadros authored
commit e73b49f1 upstream. Prevent resources from being freed twice in case device_add() call fails within phy_create(). Also use ida_simple_remove() instead of ida_remove() as we had used ida_simple_get() to allocate the ida. Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Michal Sojka authored
commit d8279a40 upstream. This adds support for Infineon TriBoard TC1798 [1]. Only interface 1 is used as serial line (see [2], Figure 8-6). [1] http://www.infineon.com/cms/de/product/microcontroller/development-tools-software-and-kits/tricore-tm-development-tools-software-and-kits/starterkits-and-evaluation-boards/starter-kit-tc1798/channel.html?channel=db3a304333b8a7ca0133cfa3d73e4268 [2] http://www.infineon.com/dgdl/TriBoardManual-TC1798-V10.pdf?folderId=db3a304412b407950112b409ae7c0343&fileId=db3a304333b8a7ca0133cfae99fe426aSigned-off-by:
Michal Sojka <sojkam1@fel.cvut.cz> Cc: Johan Hovold <johan@kernel.org> Signed-off-by:
-
Anton Blanchard authored
commit f5602941 upstream. We are seeing a lot of PMU warnings on POWER8: Can't find PMC that caused IRQ Looking closer, the active PMC is 0 at this point and we took a PMU exception on the transition from negative to 0. Some versions of POWER8 have an issue where they edge detect and not level detect PMC overflows. A number of places program the PMC with (0x80000000 - period_left), where period_left can be negative. We can either fix all of these or just ensure that period_left is always >= 1. This patch takes the second option. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Joel Stanley authored
commit b50a6c58 upstream. On POWER8 when switching to a KVM guest we set bits in MMCR2 to freeze the PMU counters. Aside from on boot they are then never reset, resulting in stuck perf counters for any user in the guest or host. We now set MMCR2 to 0 whenever enabling the PMU, which provides a sane state for perf to use the PMU counters under either the guest or the host. This was manifesting as a bug with ppc64_cpu --frequency: $ sudo ppc64_cpu --frequency WARNING: couldn't run on cpu 0 WARNING: couldn't run on cpu 8 ... WARNING: couldn't run on cpu 144 WARNING: couldn't run on cpu 152 min: 18446744073.710 GHz (cpu -1) max: 0.000 GHz (cpu -1) avg: 0.000 GHz The command uses a perf counter to measure CPU cycles over a fixed amount of time, in order to approximate the frequency of the machine. The counters were returning zero once a guest was started, regardless of weather it was still running or had been shut down. By dumping the value of MMCR2, it was observed that once a guest is running MMCR2 is set to 1s - which stops counters from running: $ sudo sh -c 'echo p > /proc/sysrq-trigger' CPU: 0 PMU registers, ppmu = POWER8 n_counters = 6 PMC1: 5b635e38 PMC2: 00000000 PMC3: 00000000 PMC4: 00000000 PMC5: 1bf5a646 PMC6: 5793d378 PMC7: deadbeef PMC8: deadbeef MMCR0: 0000000080000000 MMCR1: 000000001e000000 MMCRA: 0000040000000000 MMCR2: fffffffffffffc00 EBBHR: 0000000000000000 EBBRR: 0000000000000000 BESCR: 0000000000000000 SIAR: 00000000000a51cc SDAR: c00000000fc40000 SIER: 0000000001000000 This is done unconditionally in book3s_hv_interrupts.S upon entering the guest, and the original value is only save/restored if the host has indicated it was using the PMU. This is okay, however the user of the PMU needs to ensure that it is in a defined state when it starts using it. Fixes: e05b9b9e ("powerpc/perf: Power8 PMU support") Signed-off-by:
Joel Stanley <joel@jms.id.au> Acked-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Joel Stanley authored
commit 4d9690dd upstream. Instead of separate bits for every POWER8 PMU feature, have a single one for v2.07 of the architecture. This saves us adding a MMCR2 define for a future patch. Signed-off-by:
-
Alexandre Demers authored
commit 41959341 upstream. It reverts commit c745fe61 now that Cayman is stable since VDDCI fix. Spread spectrum was not the culprit. This depends on b0880e87 (drm/radeon/dpm: fix vddci setup typo on cayman). Signed-off-by:
Alexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
