- 17 Feb, 2011 40 commits
-
-
David S. Miller authored
[ Upstream commit 09798eb9 ] After commit 25edd694 ("sparc64: Get rid of indirect p1275 PROM call buffer.") we can't pass virtual addresses >4GB to PROM calls. Largely this is never necessary in drivers because we have a copy of the entire PROM device tree in the kernel and a set of of_*() interfaces to access it. Unfortunately there were some lingering prom calls in the atyfb driver, in particular prom_finddevice() was being called with an on-stack address which could be anywhere. This code is actually probing for information we already have, the PROM choosen console output device is stored in of_console_device so all of this nasty code consolidates into a one-line comparison. Next we have some prom_getintdefault() calls which are trivially transformed into the equivalent of_getintprop_default(). Special thanks to Fabio, who figured out exactly where the bootup was hanging. That made this bug trivial to fix. Reported-by:
Fabio M. Di NItto <fabbione@fabbione.net> Reported-by:
Sam Ravnborg <sam@ravnborg.org> Reported-by:
Frans van Berckel <fberckel@xs4all.nl> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Thomas Taranowski authored
commit 12a4dc43 upstream. In fsl_rio_dbell_handler() the code currently simply acknowledges the QFI queue full interrupt, but does nothing to resolve the queue full condition. Instead, it jumps to the end of the isr. When a queue full condition occurs, the isr is then re-entered immediately and continually, forever. The fix is to just fall through and read out current doorbell entries. Signed-off-by:
Thomas Taranowski <tom@baringforge.com> Cc: Alexandre Bounine <alexandre.bounine@idt.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Li Yang <leoli@freescale.com> Cc: Thomas Moll <thomas.moll@sysgo.com> Cc: Micha Nelissen <micha@neli.hopto.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Eric Sandeen authored
commit 2892c15d upstream. In 2.6.37 I was running into oopses with repeated module loads & unloads. I tracked this down to: fb1813f4 ext4: use dedicated slab caches for group_info structures (this was in addition to the features advert unload problem) The kstrdup & subsequent kfree of the cache name was causing a double free. In slub, at least, if I read it right it allocates & frees the name itself, slab seems to do something different... so in slub I think we were leaking -our- cachep->name, and double freeing the one allocated by slub. After getting lost in slab/slub/slob a bit, I just looked at other sized-caches that get allocated. jbd2, biovec, sgpool all do it more or less the way jbd2 does. Below patch follows the jbd2 method of dynamically allocating a cache at mount time from a list of static names. (This might also possibly fix a race creating the caches with parallel mounts running). [Folded in a fix from Dan Carpenter which fixed an off-by-one error in the original patch] Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Curt Wohlgemuth authored
commit d50bdd5a upstream. This fixes a corruption problem with the multi-block writepages submittal change for ext4, from commit bd2d0210 ("ext4: use bio layer instead of buffer layer in mpage_da_submit_io"). (Note that this corruption is not present in 2.6.37 on ext4, because the corruption was detected after the feature was merged in 2.6.37-rc1, and so it was turned off by adding a non-default mount option, mblk_io_submit. With this commit, which hopefully fixes the last of the bugs with this feature, we'll be able to turn on this performance feature by default in 2.6.38, and remove the mblk_io_submit option.) The ext4 code path to bundle multiple pages for writeback in ext4_bio_write_page() had a bug: we should be clearing buffer head dirty flags *before* we submit the bio, not in the completion routine. The patch below was tested on 2.6.37 under KVM with the postgresql script which was submitted by Jon Nelson as documented in commit 1449032b. Without the patch, I'd hit the corruption problem about 50-70% of the time. With the patch, I executed the script > 100 times with no corruption seen. I also fixed a bug to make sure ext4_end_bio() doesn't dereference the bio after the bio_put() call. Reported-by:
Jon Nelson <jnelson@jamponi.net> Reported-by:
Matthias Bayer <jackdachef@gmail.com> Signed-off-by:
Curt Wohlgemuth <curtw@google.com> Signed-off-by:
-
Lukas Czerner authored
commit 8f021222 upstream. Ext4 features interface was not properly unregistered which led to problems while unloading/reloading ext4 module. This commit fixes that by adding proper kobject unregistration code into ext4_exit_fs() as well as fail-path of ext4_init_fs() Reported-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
-
Eric Sandeen authored
commit 8f1f7453 upstream. https://bugzilla.kernel.org/show_bug.cgi?id=27652 If the lazyinit thread is running, the teardown function ext4_destroy_lazyinit_thread() has problems: ext4_clear_request_list(); while (ext4_li_info->li_task) { wake_up(&ext4_li_info->li_wait_daemon); wait_event(ext4_li_info->li_wait_task, ext4_li_info->li_task == NULL); } Clearing the request list will cause the thread to exit and free ext4_li_info, so then we're waiting on something which is getting freed. Fix this up by making the thread respond to kthread_stop, and exit, without the need to wait for that exit in some other homegrown way. Reported-and-Tested-by:
Tao Ma <boyu.mt@taobao.com> Signed-off-by:
-
Theodore Ts'o authored
commit 1c5b9e90 upstream. Commit 40389687 moved a call to ext4_forget() out of ext4_free_branches and let ext4_free_blocks() handle calling bforget(). But that change unfortunately did not replace the call to ext4_forget() with brelse(), which was needed to drop the in-use count of the indirect block's buffer head, which lead to a memory leak when deleting files that used indirect blocks. Fix this. Thanks to Hugh Dickins for pointing this out. Signed-off-by:
-
Jan Kara authored
commit ca6e909f upstream. When ext4_trim_fs() is called to trim a part of a single group, the logic will wrongly set last block of the interval to 'len' instead of 'first_block + len'. Thus a shorter interval is possibly trimmed. Fix it. CC: Lukas Czerner <lczerner@redhat.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Andrew Morton authored
commit 6c5a6cb9 upstream. fs/ext4/super.c: In function 'ext4_register_li_request': fs/ext4/super.c:2936: warning: 'ret' may be used uninitialized in this function It looks buggy to me, too. Cc: Lukas Czerner <lczerner@redhat.com> Signed-off-by:
-
Jan Kara authored
commit b9543dac upstream. When wb_writeback() is called in WB_SYNC_ALL mode, work->nr_to_write is usually set to LONG_MAX. The logic in wb_writeback() then calls __writeback_inodes_sb() with nr_to_write == MAX_WRITEBACK_PAGES and we easily end up with non-positive nr_to_write after the function returns, if the inode has more than MAX_WRITEBACK_PAGES dirty pages at the moment. When nr_to_write is <= 0 wb_writeback() decides we need another round of writeback but this is wrong in some cases! For example when a single large file is continuously dirtied, we would never finish syncing it because each pass would be able to write MAX_WRITEBACK_PAGES and inode dirty timestamp never gets updated (as inode is never completely clean). Thus __writeback_inodes_sb() would write the redirtied inode again and again. Fix the issue by setting nr_to_write to LONG_MAX in WB_SYNC_ALL mode. We do not need nr_to_write in WB_SYNC_ALL mode anyway since write_cache_pages() does livelock avoidance using page tagging in WB_SYNC_ALL mode. This makes wb_writeback() call __writeback_inodes_sb() only once on WB_SYNC_ALL. The latter function won't livelock because it works on - a finite set of files by doing queue_io() once at the beginning - a finite set of pages by PAGECACHE_TAG_TOWRITE page tagging After this patch, program from http://lkml.org/lkml/2010/10/24/154 is no longer able to stall sync forever. [fengguang.wu@intel.com: fix locking comment] Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Dave Chinner <david@fromorbit.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Jan Engelhardt <jengelh@medozas.de> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Jan Kara authored
commit aa373cf5 upstream. Background writeback is easily livelockable in a loop in wb_writeback() by a process continuously re-dirtying pages (or continuously appending to a file). This is in fact intended as the target of background writeback is to write dirty pages it can find as long as we are over dirty_background_threshold. But the above behavior gets inconvenient at times because no other work queued in the flusher thread's queue gets processed. In particular, since e.g. sync(1) relies on flusher thread to do all the IO for it, sync(1) can hang forever waiting for flusher thread to do the work. Generally, when a flusher thread has some work queued, someone submitted the work to achieve a goal more specific than what background writeback does. Moreover by working on the specific work, we also reduce amount of dirty pages which is exactly the target of background writeout. So it makes sense to give specific work a priority over a generic page cleaning. Thus we interrupt background writeback if there is some other work to do. We return to the background writeback after completing all the queued work. This may delay the writeback of expired inodes for a while, however the expired inodes will eventually be flushed to disk as long as the other works won't livelock. [fengguang.wu@intel.com: update comment] Signed-off-by:
-
Jan Kara authored
commit 6585027a upstream. Check whether background writeback is needed after finishing each work. When bdi flusher thread finishes doing some work check whether any kind of background writeback needs to be done (either because dirty_background_ratio is exceeded or because we need to start flushing old inodes). If so, just do background write back. This way, bdi_start_background_writeback() just needs to wake up the flusher thread. It will do background writeback as soon as there is no other work. This is a preparatory patch for the next patch which stops background writeback as soon as there is other work to do. Signed-off-by:
-
Thomas Gleixner authored
commit f1a06390 upstream. move_native_irq() masks and unmasks the interrupt line unconditionally, but the interrupt line might be masked due to a threaded oneshot handler in progress. Unmasking the line in that case can lead to interrupt storms. Observed on PREEMPT_RT. Originally-from: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Hugh Dickins authored
commit fd4a4663 upstream. 2.6.37 added an unmap_and_move_huge_page() for memory failure recovery, but its anon_vma handling was still based around the 2.6.35 conventions. Update it to use page_lock_anon_vma, get_anon_vma, page_unlock_anon_vma, drop_anon_vma in the same way as we're now changing unmap_and_move(). I don't particularly like to propose this for stable when I've not seen its problems in practice nor tested the solution: but it's clearly out of synch at present. Signed-off-by:
Hugh Dickins <hughd@google.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Rik van Riel <riel@redhat.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com> Cc: Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Hugh Dickins authored
commit 1ce82b69 upstream. Increased usage of page migration in mmotm reveals that the anon_vma locking in unmap_and_move() has been deficient since 2.6.36 (or even earlier). Review at the time of f1819427 ("mm: fix hang on anon_vma->root->lock") missed the issue here: the anon_vma to which we get a reference may already have been freed back to its slab (it is in use when we check page_mapped, but that can change), and so its anon_vma->root may be switched at any moment by reuse in anon_vma_prepare. Perhaps we could fix that with a get_anon_vma_unless_zero(), but let's not: just rely on page_lock_anon_vma() to do all the hard thinking for us, then we don't need any rcu read locking over here. In removing the rcu_unlock label: since PageAnon is a bit in page->mapping, it's impossible for a !page->mapping page to be anon; but insert VM_BUG_ON in case the implementation ever changes. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Reviewed-by:
Rik van Riel <riel@redhat.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com> Cc: Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Mel Gorman authored
mm: migration: use rcu_dereference_protected when dereferencing the radix tree slot during file page migration commit 29c1f677 upstream. migrate_pages() -> unmap_and_move() only calls rcu_read_lock() for anonymous pages, as introduced by git commit 989f89c5 ("fix rcu_read_lock() in page migraton"). The point of the RCU protection there is part of getting a stable reference to anon_vma and is only held for anon pages as file pages are locked which is sufficient protection against freeing. However, while a file page's mapping is being migrated, the radix tree is double checked to ensure it is the expected page. This uses radix_tree_deref_slot() -> rcu_dereference() without the RCU lock held triggering the following warning. [ 173.674290] =================================================== [ 173.676016] [ INFO: suspicious rcu_dereference_check() usage. ] [ 173.676016] --------------------------------------------------- [ 173.676016] include/linux/radix-tree.h:145 invoked rcu_dereference_check() without protection! [ 173.676016] [ 173.676016] other info that might help us debug this: [ 173.676016] [ 173.676016] [ 173.676016] rcu_scheduler_active = 1, debug_locks = 0 [ 173.676016] 1 lock held by hugeadm/2899: [ 173.676016] #0: (&(&inode->i_data.tree_lock)->rlock){..-.-.}, at: [<c10e3d2b>] migrate_page_move_mapping+0x40/0x1ab [ 173.676016] [ 173.676016] stack backtrace: [ 173.676016] Pid: 2899, comm: hugeadm Not tainted 2.6.37-rc5-autobuild [ 173.676016] Call Trace: [ 173.676016] [<c128cc01>] ? printk+0x14/0x1b [ 173.676016] [<c1063502>] lockdep_rcu_dereference+0x7d/0x86 [ 173.676016] [<c10e3db5>] migrate_page_move_mapping+0xca/0x1ab [ 173.676016] [<c10e41ad>] migrate_page+0x23/0x39 [ 173.676016] [<c10e491b>] buffer_migrate_page+0x22/0x107 [ 173.676016] [<c10e48f9>] ? buffer_migrate_page+0x0/0x107 [ 173.676016] [<c10e425d>] move_to_new_page+0x9a/0x1ae [ 173.676016] [<c10e47e6>] migrate_pages+0x1e7/0x2fa This patch introduces radix_tree_deref_slot_protected() which calls rcu_dereference_protected(). Users of it must pass in the mapping->tree_lock that is protecting this dereference. Holding the tree lock protects against parallel updaters of the radix tree meaning that rcu_dereference_protected is allowable. [akpm@linux-foundation.org: remove unneeded casts] Signed-off-by:
-
Jerome Marchand authored
commit 09e099d4 upstream. /proc/diskstats would display a strange output as follows. $ cat /proc/diskstats |grep sda 8 0 sda 90524 7579 102154 20464 0 0 0 0 0 14096 20089 8 1 sda1 19085 1352 21841 4209 0 0 0 0 4294967064 15689 4293424691 ~~~~~~~~~~ 8 2 sda2 71252 3624 74891 15950 0 0 0 0 232 23995 1562390 8 3 sda3 54 487 2188 92 0 0 0 0 0 88 92 8 4 sda4 4 0 8 0 0 0 0 0 0 0 0 8 5 sda5 81 2027 2130 138 0 0 0 0 0 87 137 Its reason is the wrong way of accounting hd_struct->in_flight. When a bio is merged into a request belongs to different partition by ELEVATOR_FRONT_MERGE. The detailed root cause is as follows. Assuming that there are two partition, sda1 and sda2. 1. A request for sda2 is in request_queue. Hence sda1's hd_struct->in_flight is 0 and sda2's one is 1. | hd_struct->in_flight --------------------------- sda1 | 0 sda2 | 1 --------------------------- 2. A bio belongs to sda1 is issued and is merged into the request mentioned on step1 by ELEVATOR_BACK_MERGE. The first sector of the request is changed from sda2 region to sda1 region. However the two partition's hd_struct->in_flight are not changed. | hd_struct->in_flight --------------------------- sda1 | 0 sda2 | 1 --------------------------- 3. The request is finished and blk_account_io_done() is called. In this case, sda2's hd_struct->in_flight, not a sda1's one, is decremented. | hd_struct->in_flight --------------------------- sda1 | -1 sda2 | 1 --------------------------- The patch fixes the problem by caching the partition lookup inside the request structure, hence making sure that the increment and decrement will always happen on the same partition struct. This also speeds up IO with accounting enabled, since it cuts down on the number of lookups we have to do. Also add a refcount to struct hd_struct to keep the partition in memory as long as users exist. We use kref_test_and_get() to ensure we don't add a reference to a partition which is going away. Signed-off-by:
Jerome Marchand <jmarchan@redhat.com> Signed-off-by:
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Jerome Marchand authored
commit e4a683c8 upstream. Add kref_test_and_get() function, which atomically add a reference only if refcount is not zero. This prevent to add a reference to an object that is already being removed. Signed-off-by:
-
Paul Fox authored
commit 2fb08e6c upstream. rtc-cmos was setting suspend/resume hooks at the device_driver level. However, the platform bus code (drivers/base/platform.c) only looks for resume hooks at the dev_pm_ops level, or within the platform_driver. Switch rtc_cmos to use dev_pm_ops so that suspend/resume code is executed again. Paul said: : The user visible symptom in our (XO laptop) case was that rtcwake would : fail to wake the laptop. The RTC alarm would expire, but the wakeup : wasn't unmasked. : : As for severity, the impact may have been reduced because if I recall : correctly, the bug only affected platforms with CONFIG_PNP disabled. Signed-off-by:
Paul Fox <pgf@laptop.org> Signed-off-by:
Daniel Drake <dsd@laptop.org> Acked-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Dave Anderson authored
commit ceff1a77 upstream. Commit 34aacb29 ("procfs: Use generic_file_llseek in /proc/kcore") broke seeking on /proc/kcore. This changes it back to use default_llseek in order to restore the original behavior. The problem with generic_file_llseek is that it only allows seeks up to inode->i_sb->s_maxbytes, which is 2GB-1 on procfs, where the memory file offset values in the /proc/kcore PT_LOAD segments may exceed or start beyond that offset value. A similar revert was made for /proc/vmcore. Signed-off-by:
Dave Anderson <anderson@redhat.com> Acked-by:
Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by:
-
Steve Wise authored
commit 6a09a9d6 upstream. MAXBURST cannot exceed 256B for on-chip queues. With a 512B MAXBURST, we can lock up the chip. Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Steve Wise authored
commit 94788657 upstream. The PF passed to FW was 0, causing PCI failures in an SR-IOV environment. Signed-off-by:
-
Steve Wise authored
commit db8b1016 upstream. Re-initializing the wait object in rdma_init()/rdma_fini() causes a timing window which can lead to a deadlock during close. Once this deadlock hits, all RDMA activity over the T4 device will be stuck. There's no need to re-init the wait object, so remove it. Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Jason Baron authored
commit 2d75af2f upstream. On older gcc (3.3) dynamic debug fails to compile: include/net/inet_connection_sock.h: In function `inet_csk_reset_xmit_timer': include/net/inet_connection_sock.h:236: error: duplicate label declaration `do_printk' include/net/inet_connection_sock.h:219: error: this is a previous declaration include/net/inet_connection_sock.h:236: error: duplicate label declaration `out' include/net/inet_connection_sock.h:219: error: this is a previous declaration include/net/inet_connection_sock.h:236: error: duplicate label `do_printk' include/net/inet_connection_sock.h:236: error: duplicate label `out' Fix, by reverting the usage of JUMP_LABEL() in dynamic debug for now. Reported-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by:
Jason Baron <jbaron@redhat.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
J. Bruce Fields authored
commit f6af99ec upstream. According to rfc 3530 BADNAME is for strings that represent paths; BADOWNER is for user/group names that don't map. And the too-long name should probably be BADOWNER as well; it's effectively the same as if we couldn't map it. Reported-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Reported-by:
Simon Kirby <sim@hostway.ca> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Chuck Lever authored
commit 839f7ad6 upstream. Nick Piggin reports: > I'm getting use after frees in aio code in NFS > > [ 2703.396766] Call Trace: > [ 2703.396858] [<ffffffff8100b057>] ? native_sched_clock+0x27/0x80 > [ 2703.396959] [<ffffffff8108509e>] ? put_lock_stats+0xe/0x40 > [ 2703.397058] [<ffffffff81088348>] ? lock_release_holdtime+0xa8/0x140 > [ 2703.397159] [<ffffffff8108a2a5>] lock_acquire+0x95/0x1b0 > [ 2703.397260] [<ffffffff811627db>] ? aio_put_req+0x2b/0x60 > [ 2703.397361] [<ffffffff81039701>] ? get_parent_ip+0x11/0x50 > [ 2703.397464] [<ffffffff81612a31>] _raw_spin_lock_irq+0x41/0x80 > [ 2703.397564] [<ffffffff811627db>] ? aio_put_req+0x2b/0x60 > [ 2703.397662] [<ffffffff811627db>] aio_put_req+0x2b/0x60 > [ 2703.397761] [<ffffffff811647fe>] do_io_submit+0x2be/0x7c0 > [ 2703.397895] [<ffffffff81164d0b>] sys_io_submit+0xb/0x10 > [ 2703.397995] [<ffffffff8100307b>] system_call_fastpath+0x16/0x1b > > Adding some tracing, it is due to nfs completing the request then > returning something other than -EIOCBQUEUED, so aio.c > also completes the request. To address this, prevent the NFS direct I/O engine from completing async iocbs when the forward path returns an error without starting any I/O. This fix appears to survive ^C during both "xfstest no. 208" and "fsx -Z." It's likely this bug has existed for a very long while, as we are seeing very similar symptoms in OEL 5. Copying stable. Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Trond Myklebust authored
commit e00b8a24 upstream. There is no reason to be freeing the delegation cred in the rcu callback, and doing so is resulting in a lockdep complaint that rpc_credcache_lock is being called from both softirq and non-softirq contexts. Reported-by:
-
Trond Myklebust authored
commit 8a0eebf6 upstream. Commit c0204fd2 (NFS: Clean up nfs4_proc_create()) broke NFSv3 exclusive open by removing the code that passes the O_EXCL flag down to nfs3_proc_create(). This patch reverts that offending hunk from the original commit. Reported-by:
Nick Bowler <nbowler@elliptictech.com> Signed-off-by:
-
Trond Myklebust authored
commit 6650239a upstream. vm_map_ram() is not available on NOMMU platforms, and causes trouble on incoherrent architectures such as ARM when we access the page data through both the direct and the virtual mapping. The alternative is to use the direct mapping to access page data for the case when we are not crossing a page boundary, but to copy the data into a linear scratch buffer when we are accessing data that spans page boundaries. Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Mike Frysinger authored
commit 15d2e22b upstream. One spot was missed in this driver when converting from snd_soc_dai.private_data to snd_soc_dai_get_drvdata. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Mike Frysinger authored
commit e9c20489 upstream. We need to tweak how we query the active capture/playback state after the recent overhauls of common code. Signed-off-by:
-
Dimitris Papastamos authored
commit 7ebcf5d6 upstream. Signed-off-by:
Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Acked-by:
-
Mark Brown authored
commit 4514e899 upstream. When we disable the WM8994 FLL code path sharing means that we end up writing out a configuration. Currently this is the currently active input and output frequency (which causes snd_soc_update_bits() to suppress actual writes both immediately and in the common case where we reenable the same configuration later) but we allow machine drivers to pass through a source of zero. Since the register values written are one less than the source constants this causes corruption of other bitfields in the register. Fix this by using the most recently configured FLL source when none is provided. Signed-off-by:
-
David Henningsson authored
commit a6c47a85 upstream. According to the reporter, node 0x15 needs to be muted for subwoofer to stop sounding. This pin is marked as unused by BIOS, so fix that. BugLink: http://bugs.launchpad.net/bugs/715877 Reported-by: Hans Peter Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 11839aed upstream. The commit 53d7d69d ALSA: hdmi - support infoframe for DisplayPort dropped the initialization of CA field accidentally. This resulted in only two-channel LPCM mode on Nvidia machines. Reference: kernel bug 28592 https://bugzilla.kernel.org/show_bug.cgi?id=28592Signed-off-by:
-
Clemens Ladisch authored
commit b1d4f7f4 upstream. If a timer interrupt was delayed too much, hrtimer_forward_now() will forward the timer expiry more than once. When this happens, the additional number of elapsed ALSA timer ticks must be passed to snd_timer_interrupt() to prevent the ALSA timer from falling behind. This mostly fixes MIDI slowdown problems on highly-loaded systems with badly behaved interrupt handlers. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Reported-and-tested-by:
Arthur Marsh <arthur.marsh@internode.on.net> Signed-off-by:
-
Li Zefan authored
commit 1dbd1951 upstream. While running my ftrace stress test, this showed up: BUG: sleeping function called from invalid context at mm/mmap.c:233 ... note: cat[3293] exited with preempt_count 1 The bug was introduced by commit 91e86e56 ("tracing: Fix recursive user stack trace") Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com> LKML-Reference: <4D0089AC.1020802@cn.fujitsu.com> Signed-off-by:
-
Dirk Eibach authored
commit 2778fb13 upstream. LM64 has 16 degrees Celsius temperature offset on all remote sensor registers. This was not considered When LM64 support was added to lm63.c. Signed-off-by:
Dirk Eibach <eibach@gdsys.de> Signed-off-by:
Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by:
-
Dmitry Torokhov authored
commit 54e74b87 upstream. Do not respond with -EINVAL to EVIOCGKEYCODE for not-yet-mapped scancodes, but rather return KEY_RESERVED. This fixes breakage with Ubuntu's input-kbd utility that stopped returning full keymaps for remote controls. Tested-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Tested-by:
Mark Lord <kernel@teksavvy.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Edgar (gimli) Hucek authored
commit 6021afcf upstream. This patch adds support for the MacBookAir3,1 and MacBookAir3,2 models. [rydberg@euromail.se: touchpad range calibration] Signed-off-by:
Edgar (gimli) Hucek <gimli@dark-green.com> Signed-off-by:
Henrik Rydberg <rydberg@euromail.se> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
