- 17 Feb, 2011 40 commits
-
-
Peter Zijlstra authored
commit 06c3bc65 upstream. cpu_stopper_thread() migration_cpu_stop() __migrate_task() deactivate_task() dequeue_task() dequeue_task_rq() update_curr_rt() Will call update_curr_rt() on rq->curr, which at that time is rq->stop. The problem is that rq->stop.prio matches an RT prio and thus falsely assumes its a rt_sched_class task. Reported-Debuged-Tested-Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <new-submission> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Peter Zijlstra authored
commit 068c5cc5 upstream. By not notifying the controller of the on-exit move back to init_css_set, we fail to move the task out of the previous cgroup's cfs_rq. This leads to an opportunity for a cgroup-destroy to come in and free the cgroup (there are no active tasks left in it after all) to which the not-quite dead task is still enqueued. Reported-by:
Miklos Vajna <vmiklos@frugalware.org> Fixed-by:
Mike Galbraith <efault@gmx.de> Signed-off-by:
-
NeilBrown authored
commit 6bf41237 upstream. wait_for_completion_*_timeout() can return: 0: if the wait timed out -ve: if the wait was interrupted +ve: if the completion was completed. As they currently return an 'unsigned long', the last two cases are not easily distinguished which can easily result in buggy code, as is the case for the recently added wait_for_completion_interruptible_timeout() call in net/sunrpc/cache.c So change them both to return 'long'. As MAX_SCHEDULE_TIMEOUT is LONG_MAX, a large +ve return value should never overflow. Signed-off-by:
NeilBrown <neilb@suse.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: J. Bruce Fields <bfields@fieldses.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> LKML-Reference: <20110105125016.64ccab0e@notabene.brown> Signed-off-by:
-
Eric Dumazet authored
commit 0781b909 upstream. commit 95aac7b1 ("epoll: make epoll_wait() use the hrtimer range feature") added a performance regression because it uses timespec_add_ns() with potential very large 'ns' values. [akpm@linux-foundation.org: s/epoll_set_mstimeout/ep_set_mstimeout/, per Davide] Reported-by:
Simon Kirby <sim@hostway.ca> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Cc: Shawn Bohrer <shawn.bohrer@gmail.com> Acked-by:
Davide Libenzi <davidel@xmailserver.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
David Miller authored
commit 795abaf1 upstream. Commit c0e69a5b ("klist.c: bit 0 in pointer can't be used as flag") intended to make sure that all klist objects were at least pointer size aligned, but used the constant "4" which only works on 32-bit. Use "sizeof(void *)" which is correct in all cases. Signed-off-by:
David S. Miller <davem@davemloft.net> Acked-by:
Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
-
Mel Gorman authored
commit 88f5acf8 upstream. Commit aa454840 ("calculate a better estimate of NR_FREE_PAGES when memory is low") noted that watermarks were based on the vmstat NR_FREE_PAGES. To avoid synchronization overhead, these counters are maintained on a per-cpu basis and drained both periodically and when a threshold is above a threshold. On large CPU systems, the difference between the estimate and real value of NR_FREE_PAGES can be very high. The system can get into a case where pages are allocated far below the min watermark potentially causing livelock issues. The commit solved the problem by taking a better reading of NR_FREE_PAGES when memory was low. Unfortately, as reported by Shaohua Li this accurate reading can consume a large amount of CPU time on systems with many sockets due to cache line bouncing. This patch takes a different approach. For large machines where counter drift might be unsafe and while kswapd is awake, the per-cpu thresholds for the target pgdat are reduced to limit the level of drift to what should be a safe level. This incurs a performance penalty in heavy memory pressure by a factor that depends on the workload and the machine but the machine should function correctly without accidentally exhausting all memory on a node. There is an additional cost when kswapd wakes and sleeps but the event is not expected to be frequent - in Shaohua's test case, there was one recorded sleep and wake event at least. To ensure that kswapd wakes up, a safe version of zone_watermark_ok() is introduced that takes a more accurate reading of NR_FREE_PAGES when called from wakeup_kswapd, when deciding whether it is really safe to go back to sleep in sleeping_prematurely() and when deciding if a zone is really balanced or not in balance_pgdat(). We are still using an expensive function but limiting how often it is called. When the test case is reproduced, the time spent in the watermark functions is reduced. The following report is on the percentage of time spent cumulatively spent in the functions zone_nr_free_pages(), zone_watermark_ok(), __zone_watermark_ok(), zone_watermark_ok_safe(), zone_page_state_snapshot(), zone_page_state(). vanilla 11.6615% disable-threshold 0.2584% David said: : We had to pull aa454840 "mm: page allocator: calculate a better estimate : of NR_FREE_PAGES when memory is low and kswapd is awake" from 2.6.36 : internally because tests showed that it would cause the machine to stall : as the result of heavy kswapd activity. I merged it back with this fix as : it is pending in the -mm tree and it solves the issue we were seeing, so I : definitely think this should be pushed to -stable (and I would seriously : consider it for 2.6.37 inclusion even at this late date). Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Reported-by:
Shaohua Li <shaohua.li@intel.com> Reviewed-by:
Christoph Lameter <cl@linux.com> Tested-by:
Nicolas Bareil <nico@chdir.org> Cc: David Rientjes <rientjes@google.com> Cc: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by:
-
Ian Campbell authored
commit 00f28e40 upstream. This is the correct interface to use and something has broken the use of the previous incorrect interface (which fails because the request conflicts with the resources assigned for the PCI device itself instead of nesting like the PCI interfaces do). Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Kees Cook authored
commit 5b919f83 upstream. Commit fe10ae53 adds a memset() to clear the structure being sent back to userspace, but accidentally used the wrong size. Reported-by:
Brad Spengler <spender@grsecurity.net> Signed-off-by:
Kees Cook <kees.cook@canonical.com> Signed-off-by:
-
H. Peter Anvin authored
commit 76d1f7bf upstream. OLPC uses select for OLPC_OPENFIRMWARE, which means OLPC has to enforce the dependencies for OLPC_OPENFIRMWARE. Make sure it does so. Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Cc: Daniel Drake <dsd@laptop.org> Cc: Andres Salomon <dilinger@queued.net> Cc: Grant Likely <grant.likely@secretlab.ca> LKML-Reference: <20100923162846.D8D409D401B@zog.reactivated.net> Signed-off-by:
-
Christoph Lameter authored
commit 04d94879 upstream. The purpose of the locking is to prevent removal and additions of nodes when statistics are gathered for a slab cache. So we need to avoid racing with memory hotplug functionality. It is enough to take the memory hotplug locks there instead of the slub_lock. online_pages() currently does not acquire the memory_hotplug lock. Another patch will be submitted by the memory hotplug authors to take the memory hotplug lock and describe the uses of the memory hotplug lock to protect against adding and removal of nodes from non hotplug data structures. Reported-and-tested-by:
Bart Van Assche <bvanassche@acm.org> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Pekka Enberg <penberg@kernel.org> Signed-off-by:
-
Boaz Harrosh authored
commit 0b0abeaf upstream. This reverts commit 115e19c5. Apparently setting inode->bdi to one's own sb->s_bdi stops VFS from sending *read-aheads*. This problem was bisected to this commit. A revert fixes it. I'll investigate farther why is this happening for the next Kernel, but for now a revert. I'm sending to stable@kernel.org as well, since it exists also in 2.6.37. 2.6.36 is good and does not have this patch. Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
Sonic Zhang authored
commit a34650f0 upstream. The bfin_sdh driver allocates the wrong size for the private data in the mmc_host. The first parameter of mmc_alloc_host should be the size of the local driver struct rather than the common mmc_host. Signed-off-by:
Sonic Zhang <sonic.zhang@analog.com> Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
commit 01c88e2d upstream. Commit 4b534334 ("memcg: clean up try_charge main loop") removes a cancel of charge at case: memory charge-> success. mem+swap charge-> failure. This leaks usage of memory. Fix it. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Cc: Balbir Singh <balbir@in.ibm.com> Signed-off-by:
-
Russell King authored
commit b0a2679d upstream. Disable the initrd if the passed address already overlaps the reserved region. This avoids oopses on Netwinders when NeTTrom tells the kernel that an initrd is located at mem+4MB, but this overlaps the BSS, resulting in the kernels in-use BSS being freed. This should be applied to v2.6.37-stable. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Changhwan Youn authored
commit a50eb1c7 upstream. This patch is applied according to the commit 1a8e41cd (ARM: 6395/1: VExpress: Set bit 22 in the PL310 (cache controller) AuxCtlr register). Actually, S5PV310 has same cache controller(PL310). Following is from Catalin Marinas' commit. Clearing bit 22 in the PL310 Auxiliary Control register (shared attribute override enable) has the side effect of transforming Normal Shared Non-cacheable reads into Cacheable no-allocate reads. Coherent DMA buffers in Linux always have a Cacheable alias via the kernel linear mapping and the processor can speculatively load cache lines into the PL310 controller. With bit 22 cleared, Non-cacheable reads would unexpectedly hit such cache lines leading to buffer corruption. Signed-off-by:
Changhwan Youn <chaos.youn@samsung.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
-
Kacper Kornet authored
commit aa5bd67d upstream. Since check_prlimit_permission always fails in the case of SUID/GUID processes, such processes are not able to read or set their own limits. This commit changes this by assuming that process can always read/change its own limits. Signed-off-by:
Kacper Kornet <kornet@camk.edu.pl> Acked-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Roland Stigge authored
commit e71a7fd2 upstream. Fix some ADC drivers' _scale interface to correct fixpoint formatted output Signed-off-by:
Roland Stigge <stigge@antcom.de> Acked-by:
Jonathan Cameron <jic23@cam.ac.uk> Acked-by:
Michael Hennerich <Michael.Hennerich@analog.com> Signed-off-by:
-
Don Skidmore authored
commit a124339a upstream. We have found a hardware erratum on 82599 hardware that can lead to unpredictable behavior when Header Splitting mode is enabled. So we are no longer enabling this feature on affected hardware. Please see the 82599 Specification Update for more information. Signed-off-by:
Don Skidmore <donald.c.skidmore@intel.com> Tested-by:
Stephen Ko <stephen.s.ko@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Tim Deegan authored
commit 70a06228 upstream. Fixes a hang when booting as dom0 under Xen, when jiffies can be quite large by the time the kernel init gets this far. Signed-off-by:
Tim Deegan <Tim.Deegan@citrix.com> [jbeulich@novell.com: !time_after() -> time_before_eq() as suggested by Jiri Slaby] Signed-off-by:
Jan Beulich <jbeulich@novell.com> Cc: Jiri Slaby <jslaby@suse.cz> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
-
Suresh Siddha authored
commit f7448548 upstream. Markus Kohn ran into a hard hang regression on an acer aspire 1310, when acpi is enabled. git bisect showed the following commit as the bad one that introduced the boot regression. commit d0af9eed Author: Suresh Siddha <suresh.b.siddha@intel.com> Date: Wed Aug 19 18:05:36 2009 -0700 x86, pat/mtrr: Rendezvous all the cpus for MTRR/PAT init Because of the UP configuration of that platform, native_smp_prepare_cpus() bailed out (in smp_sanity_check()) before doing the set_mtrr_aps_delayed_init() Further down the boot path, native_smp_cpus_done() will call the delayed MTRR initialization for the AP's (mtrr_aps_init()) with mtrr_aps_delayed_init not set. This resulted in the boot processor reprogramming its MTRR's to the values seen during the start of the OS boot. While this is not needed ideally, this shouldn't have caused any side-effects. This is because the reprogramming of MTRR's (set_mtrr_state() that gets called via set_mtrr()) will check if the live register contents are different from what is being asked to write and will do the actual write only if they are different. BP's mtrr state is read during the start of the OS boot and typically nothing would have changed when we ask to reprogram it on BP again because of the above scenario on an UP platform. So on a normal UP platform no reprogramming of BP MTRR MSR's happens and all is well. However, on this platform, bios seems to be modifying the fixed mtrr range registers between the start of OS boot and when we double check the live registers for reprogramming BP MTRR registers. And as the live registers are modified, we end up reprogramming the MTRR's to the state seen during the start of the OS boot. During ACPI initialization, something in the bios (probably smi handler?) don't like this fact and results in a hard lockup. We didn't see this boot hang issue on this platform before the commit d0af9eed, because only the AP's (if any) will program its MTRR's to the value that BP had at the start of the OS boot. Fix this issue by checking mtrr_aps_delayed_init before continuing further in the mtrr_aps_init(). Now, only AP's (if any) will program its MTRR's to the BP values during boot. Addresses https://bugzilla.novell.com/show_bug.cgi?id=623393 [ By the way, this behavior of the bios modifying MTRR's after the start of the OS boot is not common and the kernel is not prepared to handle this situation well. Irrespective of this issue, during suspend/resume, linux kernel will try to reprogram the BP's MTRR values to the values seen during the start of the OS boot. So suspend/resume might be already broken on this platform for all linux kernel versions. ] Reported-and-bisected-by:
Markus Kohn <jabber@gmx.org> Tested-by:
Suresh Siddha <suresh.b.siddha@intel.com> Cc: Thomas Renninger <trenn@novell.com> Cc: Rafael Wysocki <rjw@novell.com> Cc: Venkatesh Pallipadi <venki@google.com> LKML-Reference: <1296694975.4418.402.camel@sbsiddha-MOBL3.sc.intel.com> Signed-off-by:
-
Eric W. Biederman authored
commit 13ad1774 upstream. Ed Swierk <eswierk@bigswitch.com> writes: > On 2.6.35.7 > ip link add link eth0 netns 9999 type macvlan > where 9999 is a nonexistent PID triggers an oops and causes all network functions to hang: > [10663.821898] BUG: unable to handle kernel NULL pointer dereference at 000000000000006d > [10663.821917] IP: [<ffffffff8149c2fa>] __dev_alloc_name+0x9a/0x170 > [10663.821933] PGD 1d3927067 PUD 22f5c5067 PMD 0 > [10663.821944] Oops: 0000 [#1] SMP > [10663.821953] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq > [10663.821959] CPU 3 > [10663.821963] Modules linked in: macvlan ip6table_filter ip6_tables rfcomm ipt_MASQUERADE binfmt_misc iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack sco ipt_REJECT bnep l2cap xt_tcpudp iptable_filter ip_tables x_tables bridge stp vboxnetadp vboxnetflt vboxdrv kvm_intel kvm parport_pc ppdev snd_hda_codec_intelhdmi snd_hda_codec_conexant arc4 iwlagn iwlcore mac80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi i915 snd_seq_midi_event snd_seq thinkpad_acpi drm_kms_helper btusb tpm_tis nvram uvcvideo snd_timer snd_seq_device bluetooth videodev v4l1_compat v4l2_compat_ioctl32 tpm drm tpm_bios snd cfg80211 psmouse serio_raw intel_ips soundcore snd_page_alloc intel_agp i2c_algo_bit video output netconsole configfs lp parport usbhid hid e1000e sdhci_pci ahci libahci sdhci led_class > [10663.822155] > [10663.822161] Pid: 6000, comm: ip Not tainted 2.6.35-23-generic #41-Ubuntu 2901CTO/2901CTO > [10663.822167] RIP: 0010:[<ffffffff8149c2fa>] [<ffffffff8149c2fa>] __dev_alloc_name+0x9a/0x170 > [10663.822177] RSP: 0018:ffff88014aebf7b8 EFLAGS: 00010286 > [10663.822182] RAX: 00000000fffffff4 RBX: ffff8801ad900800 RCX: 0000000000000000 > [10663.822187] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffff88014ad63000 > [10663.822191] RBP: ffff88014aebf808 R08: 0000000000000041 R09: 0000000000000041 > [10663.822196] R10: 0000000000000000 R11: dead000000200200 R12: ffff88014aebf818 > [10663.822201] R13: fffffffffffffffd R14: ffff88014aebf918 R15: ffff88014ad62000 > [10663.822207] FS: 00007f00c487f700(0000) GS:ffff880001f80000(0000) knlGS:0000000000000000 > [10663.822212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [10663.822216] CR2: 000000000000006d CR3: 0000000231f19000 CR4: 00000000000026e0 > [10663.822221] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [10663.822226] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [10663.822231] Process ip (pid: 6000, threadinfo ffff88014aebe000, task ffff88014afb16e0) > [10663.822236] Stack: > [10663.822240] ffff88014aebf808 ffffffff814a2bb5 ffff88014aebf7e8 00000000a00ee8d6 > [10663.822251] <0> 0000000000000000 ffffffffa00ef940 ffff8801ad900800 ffff88014aebf818 > [10663.822265] <0> ffff88014aebf918 ffff8801ad900800 ffff88014aebf858 ffffffff8149c413 > [10663.822281] Call Trace: > [10663.822290] [<ffffffff814a2bb5>] ? dev_addr_init+0x75/0xb0 > [10663.822298] [<ffffffff8149c413>] dev_alloc_name+0x43/0x90 > [10663.822307] [<ffffffff814a85ee>] rtnl_create_link+0xbe/0x1b0 > [10663.822314] [<ffffffff814ab2aa>] rtnl_newlink+0x48a/0x570 > [10663.822321] [<ffffffff814aafcc>] ? rtnl_newlink+0x1ac/0x570 > [10663.822332] [<ffffffff81030064>] ? native_x2apic_icr_read+0x4/0x20 > [10663.822339] [<ffffffff814a8c17>] rtnetlink_rcv_msg+0x177/0x290 > [10663.822346] [<ffffffff814a8aa0>] ? rtnetlink_rcv_msg+0x0/0x290 > [10663.822354] [<ffffffff814c25d9>] netlink_rcv_skb+0xa9/0xd0 > [10663.822360] [<ffffffff814a8a85>] rtnetlink_rcv+0x25/0x40 > [10663.822367] [<ffffffff814c223e>] netlink_unicast+0x2de/0x2f0 > [10663.822374] [<ffffffff814c303e>] netlink_sendmsg+0x1fe/0x2e0 > [10663.822383] [<ffffffff81488533>] sock_sendmsg+0xf3/0x120 > [10663.822391] [<ffffffff815899fe>] ? _raw_spin_lock+0xe/0x20 > [10663.822400] [<ffffffff81168656>] ? __d_lookup+0x136/0x150 > [10663.822406] [<ffffffff815899fe>] ? _raw_spin_lock+0xe/0x20 > [10663.822414] [<ffffffff812b7a0d>] ? _atomic_dec_and_lock+0x4d/0x80 > [10663.822422] [<ffffffff8116ea90>] ? mntput_no_expire+0x30/0x110 > [10663.822429] [<ffffffff81486ff5>] ? move_addr_to_kernel+0x65/0x70 > [10663.822435] [<ffffffff81493308>] ? verify_iovec+0x88/0xe0 > [10663.822442] [<ffffffff81489020>] sys_sendmsg+0x240/0x3a0 > [10663.822450] [<ffffffff8111e2a9>] ? __do_fault+0x479/0x560 > [10663.822457] [<ffffffff815899fe>] ? _raw_spin_lock+0xe/0x20 > [10663.822465] [<ffffffff8116cf4a>] ? alloc_fd+0x10a/0x150 > [10663.822473] [<ffffffff8158d76e>] ? do_page_fault+0x15e/0x350 > [10663.822482] [<ffffffff8100a0f2>] system_call_fastpath+0x16/0x1b > [10663.822487] Code: 90 48 8d 78 02 be 25 00 00 00 e8 92 1d e2 ff 48 85 c0 75 cf bf 20 00 00 00 e8 c3 b1 c6 ff 49 89 c7 b8 f4 ff ff ff 4d 85 ff 74 bd <4d> 8b 75 70 49 8d 45 70 48 89 45 b8 49 83 ee 58 eb 28 48 8d 55 > [10663.822618] RIP [<ffffffff8149c2fa>] __dev_alloc_name+0x9a/0x170 > [10663.822627] RSP <ffff88014aebf7b8> > [10663.822631] CR2: 000000000000006d > [10663.822636] ---[ end trace 3dfd6c3ad5327ca7 ]--- This bug was introduced in: commit 81adee47 Author: Eric W. Biederman <ebiederm@aristanetworks.com> Date: Sun Nov 8 00:53:51 2009 -0800 net: Support specifying the network namespace upon device creation. There is no good reason to not support userspace specifying the network namespace during device creation, and it makes it easier to create a network device and pass it to a child network namespace with a well known name. We have to be careful to ensure that the target network namespace for the new device exists through the life of the call. To keep that logic clear I have factored out the network namespace grabbing logic into rtnl_link_get_net. In addtion we need to continue to pass the source network namespace to the rtnl_link_ops.newlink method so that we can find the base device source network namespace. Signed-off-by:
Eric W. Biederman <ebiederm@aristanetworks.com> Acked-by:
Ed Swierk <eswierk@bigswitch.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Tejun Heo authored
commit 01e05e9a upstream. The wake_up_process() call in ptrace_detach() is spurious and not interlocked with the tracee state. IOW, the tracee could be running or sleeping in any place in the kernel by the time wake_up_process() is called. This can lead to the tracee waking up unexpectedly which can be dangerous. The wake_up is spurious and should be removed but for now reduce its toxicity by only waking up if the tracee is in TRACED or STOPPED state. This bug can possibly be used as an attack vector. I don't think it will take too much effort to come up with an attack which triggers oops somewhere. Most sleeps are wrapped in condition test loops and should be safe but we have quite a number of places where sleep and wakeup conditions are expected to be interlocked. Although the window of opportunity is tiny, ptrace can be used by non-privileged users and with some loading the window can definitely be extended and exploited. Signed-off-by:
Tejun Heo <tj@kernel.org> Acked-by:
Roland McGrath <roland@redhat.com> Acked-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Pavel Machek authored
commit d0694e2a upstream. Unbreak Billionton CF bluetooth card. This actually fixes a regression on zaurus. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Dario Lombardo authored
commit 96a3e79e upstream. Added 0x0307 device id to support Motorola cables to the pl2303 usb serial driver. This cable has a modified chip that is a pl2303, but declares itself as 0307. Fixed by adding the right device id to the supported devices list, assigning it the code labeled PL2303_PRODUCT_ID_MOTOROLA. Signed-off-by:
Dario Lombardo <dario.lombardo@libero.it> Signed-off-by:
-
Ben Hutchings authored
commit 3e517f4b upstream. Commit 0587102c replaced a direct implementation of SIOCGICOUNT with an implementation of tty_operations::get_icount, but it did not actually set rs_360_ops.get_icount. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Christian Lamparter authored
commit 5820de53 upstream. This patch fixes a off-by-one bug which bugged the driver's PS-POLL capability. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Amit Shah authored
commit 2770c5ea upstream. The outvq needs to be woken up on host notifications so that buffers consumed by the host can be reclaimed, outvq freed, and application writes may proceed again. The need for this is now finally noticed when I have qemu patches ready to use nonblocking IO and flow control. CC: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Amit Shah <amit.shah@redhat.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Bruce Rogers authored
commit 3e9d08ec upstream. Under harsh testing conditions, including low memory, the guest would stop receiving packets. With this patch applied we no longer see any problems in the driver while performing these tests for extended periods of time. Make sure napi is scheduled subsequent to each napi_enable. Signed-off-by:
Bruce Rogers <brogers@novell.com> Signed-off-by:
Olaf Kirch <okir@suse.de> Signed-off-by:
-
Mark Brown authored
commit 7f94de48 upstream. Due to the different routing for AIF1 and AIF2 we weren't using a single widget to represent the ADCDAT signal. For consistency add one. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
-
Qiao Zhou authored
commit 78b3fb46 upstream. fix wrong value in wm8994_set_tristate func. when updating reg bits, it should use "value", not "reg". Signed-off-by:
Qiao Zhou <zhouqiao@marvell.com> Acked-by:
-
Mark Brown authored
commit 20a4e7fc upstream. The DC servo codes are actually signed numbers so need to be treated as such. Signed-off-by:
-
Dmitry Eremin-Solenikov authored
commit a3adfa00 upstream. ASoC DAI link descriptions for Corgi, Poodle and Spitz platforms contained incorrect names for cpu_dai and codec, which effectievly disabled sound on theese platforms. Fix that errors. Signed-off-by:
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Acked-by:
-
Mark Brown authored
commit 7d8316df upstream. soc_unregister_ac97_dai_link() takes a CODEC as an argument, not a rtd like the registration function, so give it what it's looking for. Signed-off-by:
Mike Frysinger <vapier.adi@gmail.com> Acked-by:
-
Sudhakar Rajashekhara authored
commit dc5a460a upstream. The codec_name entry for da8xx evm in sound/soc/davinci/davinci-evm.c is not matching with the i2c ids in the board file. Without this fix the soundcard does not get detected on da850/omap-l138/am18x evm. Signed-off-by:
Sudhakar Rajashekhara <sudhakar.raj@ti.com> Tested-by:
Dan Sharon <dansharon@nanometrics.ca> Acked-by:
-
Jean Delvare authored
commit 5219bf88 upstream. Remove real devices first and dummy devices last. This gives device driver which instantiated dummy devices themselves a chance to clean them up before we do. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Tested-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Christian Lamparter authored
commit 3b5c5827 upstream. P54_HDR_FLAG_DATA_OUT_SEQNR is meant to tell the firmware that "the frame's sequence number has already been set by the application." Whereas IEEE80211_TX_CTL_ASSIGN_SEQ is set for frames which lack a valid sequence number and either the driver or firmware has to assign one. Yup, it's the exact opposite! Signed-off-by:
-
Shaohua Li authored
commit ec30f343 upstream. Fix a shutdown regression caused by 2a2d31c8 ("intel_idle: open broadcast clock event"). The clockevent framework can automatically shutdown broadcast timers for hotremove CPUs. And we get a shutdown regression when we shutdown broadcast timer for hot remove CPU, so just delete some code. Also fix some section mismatch. Reported-by:
Ari Savolainen <ari.m.savolainen@gmail.com> Signed-off-by:
-
Shaohua Li authored
commit 2a2d31c8 upstream. Intel_idle driver uses CLOCK_EVT_NOTIFY_BROADCAST_ENTER CLOCK_EVT_NOTIFY_BROADCAST_EXIT for broadcast clock events. The _ENTER/_EXIT doesn't really open broadcast clock events, please see processor_idle.c for an example. In some situation, this will cause boot hang, because some CPUs enters idle but local APIC timer stalls. Reported-and-tested-by:
Yan Zheng <zheng.z.yan@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit d8c216cf upstream. The following scenario is possible with the current cpuidle code and the ACPI cpuidle driver: (1) acpi_processor_cst_has_changed() is called, (2) cpuidle_disable_device() is called, (3) cpuidle_remove_state_sysfs() is called to remove the (presumably outdated) states info from sysfs, (3) acpi_processor_get_power_info() is called, the first entry in the pr->power.states[] table is filled with zeros, (4) acpi_processor_setup_cpuidle() is called and it doesn't fill the first entry in pr->power.states[], (5) cpuidle_enable_device() is called, (6) __cpuidle_register_device() is _not_ called, since the device has already been registered, (7) Consequently, poll_idle_init() is _not_ called either, (8) cpuidle_add_state_sysfs() is called to create the sysfs attributes for the new states and it uses the bogus first table entry from acpi_processor_get_power_info() for creating state0. This problem is avoided if cpuidle_enable_device() unconditionally calls poll_idle_init(). Reported-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Hans-Christian Egtvedt authored
commit 664cb714 upstream. This patch removes the redundant syscalls prototypes in the architecture specific syscalls.h header file. These were identical with the ones in asm-generic/syscalls.h. Signed-off-by:
Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> Reported-by:
Peter Huewe <PeterHuewe@gmx.de> Reported-by:
Sven Schnelle <svens@stackframe.org> Signed-off-by:
-
