commit dd5c324178d21f263c61af77c65f847ae1264de9
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date: Thu Feb 17 16:00:11 2011 -0800
Linux 2.6.32.29
commit d02522a951b6fce56e93cc1729f1039c3412460a
Author: Namhyung Kim <namhyung@gmail.com>
Date: Fri Feb 11 07:07:01 2011 +0100
kernel/user.c: add lock release annotation on free_user()
commit 571428be550fbe37160596995e96ad398873fcbd upstream.
free_user() releases uidhash_lock but was missing annotation. Add it.
This removes following sparse warnings:
include/linux/spinlock.h:339:9: warning: context imbalance in 'free_user' - unexpected unlock
kernel/user.c:120:6: warning: context imbalance in 'free_uid' - wrong count at exit
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Dhaval Giani <dhaval.giani@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit c3d5f1e87ec15d2d306779ffaf95150dc9146d74
Author: Dan Carpenter <error27@gmail.com>
Date: Fri Feb 11 07:04:45 2011 +0100
sched: Remove some dead code
commit 618765801ebc271fe0ba3eca99fcfd62a1f786e1 upstream.
This was left over from "7c9414385e sched: Remove USER_SCHED"
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Dhaval Giani <dhaval.giani@gmail.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
LKML-Reference: <20100315082148.GD18181@bicker>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 97fc6c0d4655abc7ab58dc4c065b5f3fcde2fc6b
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Thu Feb 10 10:23:29 2011 +0100
sched: Fix wake_affine() vs RT tasks
Commit: e51fd5e22e12b39f49b1bb60b37b300b17378a43 upstream
Mike reports that since e9e9250b (sched: Scale down cpu_power due to RT
tasks), wake_affine() goes funny on RT tasks due to them still having a
!0 weight and wake_affine() still subtracts that from the rq weight.
Since nobody should be using se->weight for RT tasks, set the value to
zero. Also, since we now use ->cpu_power to normalize rq weights to
account for RT cpu usage, add that factor into the imbalance computation.
Reported-by: Mike Galbraith <efault@gmx.de>
Tested-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1275316109.27810.22969.camel@twins>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 354f5613d804571fa88ecff8eec02d5ba57d8b07
Author: Nikhil Rao <ncrao@google.com>
Date: Thu Feb 10 10:23:29 2011 +0100
sched: Fix idle balancing
Commit: d5ad140bc1505a98c0f040937125bfcbb508078f upstream
An earlier commit reverts idle balancing throttling reset to fix a 30%
regression in volanomark throughput. We still need to reset idle_stamp
when we pull a task in newidle balance.
Reported-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Nikhil Rao <ncrao@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1290022924-3548-1-git-send-email-ncrao@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 82dd2a0c715ff88660278a3cb8a2d0efa866e234
Author: Alex Shi <alex.shi@intel.com>
Date: Thu Feb 10 10:23:29 2011 +0100
sched: Fix volanomark performance regression
Commit: b5482cfa1c95a188b3054fa33274806add91bbe5 upstream
Commit fab4762 triggers excessive idle balancing, causing a ~30% loss in
volanomark throughput. Remove idle balancing throttle reset.
Originally-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Nikhil Rao <ncrao@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1289928732.5169.211.camel@maggy.simson.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 134f7feec8110044202aa6776f3b700022fe0213
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Thu Feb 10 10:23:29 2011 +0100
sched: Fix cross-sched-class wakeup preemption
Commit: 1e5a74059f9059d330744eac84873b1b99657008 upstream
Instead of dealing with sched classes inside each check_preempt_curr()
implementation, pull out this logic into the generic wakeup preemption
path.
This fixes a hang in KVM (and others) where we are waiting for the
stop machine thread to run ...
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Tested-by: Marcelo Tosatti <mtosatti@redhat.com>
Tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1288891946.2039.31.camel@laptop>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit aa68c0327e866f8c8cdbcea0afa69fcb89ad61a7
Author: Suresh Siddha <suresh.b.siddha@intel.com>
Date: Thu Feb 10 10:23:28 2011 +0100
sched: Use group weight, idle cpu metrics to fix imbalances during idle
Commit: aae6d3ddd8b90f5b2c8d79a2b914d1706d124193 upstream
Currently we consider a sched domain to be well balanced when the imbalance
is less than the domain's imablance_pct. As the number of cores and threads
are increasing, current values of imbalance_pct (for example 25% for a
NUMA domain) are not enough to detect imbalances like:
a) On a WSM-EP system (two sockets, each having 6 cores and 12 logical threads),
24 cpu-hogging tasks get scheduled as 13 on one socket and 11 on another
socket. Leading to an idle HT cpu.
b) On a hypothetial 2 socket NHM-EX system (each socket having 8 cores and
16 logical threads), 16 cpu-hogging tasks can get scheduled as 9 on one
socket and 7 on another socket. Leaving one core in a socket idle
whereas in another socket we have a core having both its HT siblings busy.
While this issue can be fixed by decreasing the domain's imbalance_pct
(by making it a function of number of logical cpus in the domain), it
can potentially cause more task migrations across sched groups in an
overloaded case.
Fix this by using imbalance_pct only during newly_idle and busy
load balancing. And during idle load balancing, check if there
is an imbalance in number of idle cpu's across the busiest and this
sched_group or if the busiest group has more tasks than its weight that
the idle cpu in this_group can pull.
Reported-by: Nikhil Rao <ncrao@google.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1284760952.2676.11.camel@sbsiddha-MOBL3.sc.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 2bdf3dc45d2977de02fc7ae4e804bbf1a2f9e43a
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Thu Feb 10 10:23:28 2011 +0100
sched, cgroup: Fixup broken cgroup movement
Commit: b2b5ce022acf5e9f52f7b78c5579994fdde191d4 upstream
Dima noticed that we fail to correct the ->vruntime of sleeping tasks
when we move them between cgroups.
Reported-by: Dima Zavin <dima@android.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Tested-by: Mike Galbraith <efault@gmx.de>
LKML-Reference: <1287150604.29097.1513.camel@twins>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit ea63ff2b31ea01f1c6a293dc09ad58287b7049be
Author: Ingo Molnar <mingo@elte.hu>
Date: Thu Feb 10 10:23:28 2011 +0100
sched: Export account_system_vtime()
Commit: b7dadc38797584f6203386da1947ed5edf516646 upstream
KVM uses it for example:
ERROR: "account_system_vtime" [arch/x86/kvm/kvm.ko] undefined!
Cc: Venkatesh Pallipadi <venki@google.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1286237003-12406-3-git-send-email-venki@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 19d3e3cbe91fd8c800654ff2b54cdb993cdf0336
Author: Venkatesh Pallipadi <venki@google.com>
Date: Thu Feb 10 10:23:28 2011 +0100
sched: Call tick_check_idle before __irq_enter
Commit: d267f87fb8179c6dba03d08b91952e81bc3723c7 upstream
When CPU is idle and on first interrupt, irq_enter calls tick_check_idle()
to notify interruption from idle. But, there is a problem if this call
is done after __irq_enter, as all routines in __irq_enter may find
stale time due to yet to be done tick_check_idle.
Specifically, trace calls in __irq_enter when they use global clock and also
account_system_vtime change in this patch as it wants to use sched_clock_cpu()
to do proper irq timing.
But, tick_check_idle was moved after __irq_enter intentionally to
prevent problem of unneeded ksoftirqd wakeups by the commit ee5f80a:
irq: call __irq_enter() before calling the tick_idle_check
Impact: avoid spurious ksoftirqd wakeups
Moving tick_check_idle() before __irq_enter and wrapping it with
local_bh_enable/disable would solve both the problems.
Fixed-by: Yong Zhang <yong.zhang0@gmail.com>
Signed-off-by: Venkatesh Pallipadi <venki@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1286237003-12406-9-git-send-email-venki@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit c8c885599ad2115e0a2fe661c2fb6ba4edc92c19
Author: Venkatesh Pallipadi <venki@google.com>
Date: Thu Feb 10 10:23:27 2011 +0100
sched: Remove irq time from available CPU power
Commit: aa483808516ca5cacfa0e5849691f64fec25828e upstream
The idea was suggested by Peter Zijlstra here:
http://marc.info/?l=linux-kernel&m=127476934517534&w=2
irq time is technically not available to the tasks running on the CPU.
This patch removes irq time from CPU power piggybacking on
sched_rt_avg_update().
Tested this by keeping CPU X busy with a network intensive task having 75%
oa a single CPU irq processing (hard+soft) on a 4-way system. And start seven
cycle soakers on the system. Without this change, there will be two tasks on
each CPU. With this change, there is a single task on irq busy CPU X and
remaining 7 tasks are spread around among other 3 CPUs.
Signed-off-by: Venkatesh Pallipadi <venki@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1286237003-12406-8-git-send-email-venki@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 3a69989d43689a40f3af7cad04c5aa840f3d2530
Author: Venkatesh Pallipadi <venki@google.com>
Date: Thu Feb 10 10:23:27 2011 +0100
sched: Do not account irq time to current task
Commit: 305e6835e05513406fa12820e40e4a8ecb63743c upstream
Scheduler accounts both softirq and interrupt processing times to the
currently running task. This means, if the interrupt processing was
for some other task in the system, then the current task ends up being
penalized as it gets shorter runtime than otherwise.
Change sched task accounting to acoount only actual task time from
currently running task. Now update_curr(), modifies the delta_exec to
depend on rq->clock_task.
Note that this change only handles CONFIG_IRQ_TIME_ACCOUNTING case. We can
extend this to CONFIG_VIRT_CPU_ACCOUNTING with minimal effort. But, thats
for later.
This change will impact scheduling behavior in interrupt heavy conditions.
Tested on a 4-way system with eth0 handled by CPU 2 and a network heavy
task (nc) running on CPU 3 (and no RSS/RFS). With that I have CPU 2
spending 75%+ of its time in irq processing. CPU 3 spending around 35%
time running nc task.
Now, if I run another CPU intensive task on CPU 2, without this change
/proc/<pid>/schedstat shows 100% of time accounted to this task. With this
change, it rightly shows less than 25% accounted to this task as remaining
time is actually spent on irq processing.
Signed-off-by: Venkatesh Pallipadi <venki@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1286237003-12406-7-git-send-email-venki@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 3b7d4d545694e8754f212518d80662f2d03a918d
Author: Venkatesh Pallipadi <venki@google.com>
Date: Thu Feb 10 10:23:27 2011 +0100
x86: Add IRQ_TIME_ACCOUNTING
Commit: e82b8e4ea4f3dffe6e7939f90e78da675fcc450e upstream
This patch adds IRQ_TIME_ACCOUNTING option on x86 and runtime enables it
when TSC is enabled.
This change just enables fine grained irq time accounting, isn't used yet.
Following patches use it for different purposes.
Signed-off-by: Venkatesh Pallipadi <venki@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1286237003-12406-6-git-send-email-venki@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 5e7ce6ec134635a572ca0457ed2460dfe70337ea
Author: Venkatesh Pallipadi <venki@google.com>
Date: Thu Feb 10 10:23:27 2011 +0100
sched: Add IRQ_TIME_ACCOUNTING, finer accounting of irq time
Commit: b52bfee445d315549d41eacf2fa7c156e7d153d5 upstream
s390/powerpc/ia64 have support for CONFIG_VIRT_CPU_ACCOUNTING which does
the fine granularity accounting of user, system, hardirq, softirq times.
Adding that option on archs like x86 will be challenging however, given the
state of TSC reliability on various platforms and also the overhead it will
add in syscall entry exit.
Instead, add a lighter variant that only does finer accounting of
hardirq and softirq times, providing precise irq times (instead of timer tick
based samples). This accounting is added with a new config option
CONFIG_IRQ_TIME_ACCOUNTING so that there won't be any overhead for users not
interested in paying the perf penalty.
This accounting is based on sched_clock, with the code being generic.
So, other archs may find it useful as well.
This patch just adds the core logic and does not enable this logic yet.
Signed-off-by: Venkatesh Pallipadi <venki@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1286237003-12406-5-git-send-email-venki@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 9b511401474c4518d214a02a8064b67e038a8e38
Author: Venkatesh Pallipadi <venki@google.com>
Date: Thu Feb 10 10:23:27 2011 +0100
sched: Add a PF flag for ksoftirqd identification
Commit: 6cdd5199daf0cb7b0fcc8dca941af08492612887 upstream
To account softirq time cleanly in scheduler, we need to identify whether
softirq is invoked in ksoftirqd context or softirq at hardirq tail context.
Add PF_KSOFTIRQD for that purpose.
As all PF flag bits are currently taken, create space by moving one of the
infrequently used bits (PF_THREAD_BOUND) down in task_struct to be along
with some other state fields.
Signed-off-by: Venkatesh Pallipadi <venki@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1286237003-12406-4-git-send-email-venki@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 82f7e90e5e68fdaa3c72f3522444f020fd62d7a7
Author: Dave Young <hidave.darkstar@gmail.com>
Date: Thu Feb 10 10:23:26 2011 +0100
sched: Remove unused PF_ALIGNWARN flag
Commit: 637bbdc5b83615ef9f45f50399d1c7f27473c713 upstream
PF_ALIGNWARN is not implemented and it is for 486 as the
comment.
It is not likely someone will implement this flag feature.
So here remove this flag and leave the valuable 0x00000001 for
future use.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
LKML-Reference: <20100913121903.GB22238@darkstar>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 95824433d1945be14c1a859abd9844c7fe09c2d0
Author: Venkatesh Pallipadi <venki@google.com>
Date: Thu Feb 10 10:23:26 2011 +0100
sched: Consolidate account_system_vtime extern declaration
Commit: e1e10a265d28273ab8c70be19d43dcbdeead6c5a upstream
Just a minor cleanup patch that makes things easier to the following patches.
No functionality change in this patch.
Signed-off-by: Venkatesh Pallipadi <venki@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1286237003-12406-3-git-send-email-venki@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 49c6f4a2ba104ce198c61445edbff78ce1508a65
Author: Venkatesh Pallipadi <venki@google.com>
Date: Thu Feb 10 10:23:26 2011 +0100
sched: Fix softirq time accounting
Commit: 75e1056f5c57050415b64cb761a3acc35d91f013 upstream
Peter Zijlstra found a bug in the way softirq time is accounted in
VIRT_CPU_ACCOUNTING on this thread:
http://lkml.indiana.edu/hypermail//linux/kernel/1009.2/01366.html
The problem is, softirq processing uses local_bh_disable internally. There
is no way, later in the flow, to differentiate between whether softirq is
being processed or is it just that bh has been disabled. So, a hardirq when bh
is disabled results in time being wrongly accounted as softirq.
Looking at the code a bit more, the problem exists in !VIRT_CPU_ACCOUNTING
as well. As account_system_time() in normal tick based accouting also uses
softirq_count, which will be set even when not in softirq with bh disabled.
Peter also suggested solution of using 2*SOFTIRQ_OFFSET as irq count
for local_bh_{disable,enable} and using just SOFTIRQ_OFFSET while softirq
processing. The patch below does that and adds API in_serving_softirq() which
returns whether we are currently processing softirq or not.
Also changes one of the usages of softirq_count in net/sched/cls_cgroup.c
to in_serving_softirq.
Looks like many usages of in_softirq really want in_serving_softirq. Those
changes can be made individually on a case by case basis.
Signed-off-by: Venkatesh Pallipadi <venki@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1286237003-12406-2-git-send-email-venki@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 1d3d2371a682f9905153bf28cc21ee1d2184bb44
Author: Nikhil Rao <ncrao@google.com>
Date: Thu Feb 10 10:23:26 2011 +0100
sched: Drop group_capacity to 1 only if local group has extra capacity
Commit: 75dd321d79d495a0ee579e6249ebc38ddbb2667f upstream
When SD_PREFER_SIBLING is set on a sched domain, drop group_capacity to 1
only if the local group has extra capacity. The extra check prevents the case
where you always pull from the heaviest group when it is already under-utilized
(possible with a large weight task outweighs the tasks on the system).
For example, consider a 16-cpu quad-core quad-socket machine with MC and NUMA
scheduling domains. Let's say we spawn 15 nice0 tasks and one nice-15 task,
and each task is running on one core. In this case, we observe the following
events when balancing at the NUMA domain:
- find_busiest_group() will always pick the sched group containing the niced
task to be the busiest group.
- find_busiest_queue() will then always pick one of the cpus running the
nice0 task (never picks the cpu with the nice -15 task since
weighted_cpuload > imbalance).
- The load balancer fails to migrate the task since it is the running task
and increments sd->nr_balance_failed.
- It repeats the above steps a few more times until sd->nr_balance_failed > 5,
at which point it kicks off the active load balancer, wakes up the migration
thread and kicks the nice 0 task off the cpu.
The load balancer doesn't stop until we kick out all nice 0 tasks from
the sched group, leaving you with 3 idle cpus and one cpu running the
nice -15 task.
When balancing at the NUMA domain, we drop sgs.group_capacity to 1 if the child
domain (in this case MC) has SD_PREFER_SIBLING set. Subsequent load checks are
not relevant because the niced task has a very large weight.
In this patch, we add an extra condition to the "if(prefer_sibling)" check in
update_sd_lb_stats(). We drop the capacity of a group only if the local group
has extra capacity, ie. nr_running < group_capacity. This patch preserves the
original intent of the prefer_siblings check (to spread tasks across the system
in low utilization scenarios) and fixes the case above.
It helps in the following ways:
- In low utilization cases (where nr_tasks << nr_cpus), we still drop
group_capacity down to 1 if we prefer siblings.
- On very busy systems (where nr_tasks >> nr_cpus), sgs.nr_running will most
likely be > sgs.group_capacity.
- When balancing large weight tasks, if the local group does not have extra
capacity, we do not pick the group with the niced task as the busiest group.
This prevents failed balances, active migration and the under-utilization
described above.
Signed-off-by: Nikhil Rao <ncrao@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1287173550-30365-5-git-send-email-ncrao@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 703482e7decf80dbf25cda99c35630dff3e3b121
Author: Nikhil Rao <ncrao@google.com>
Date: Thu Feb 10 10:23:25 2011 +0100
sched: Force balancing on newidle balance if local group has capacity
Commit: fab476228ba37907ad75216d0fd9732ada9c119e upstream
This patch forces a load balance on a newly idle cpu when the local group has
extra capacity and the busiest group does not have any. It improves system
utilization when balancing tasks with a large weight differential.
Under certain situations, such as a niced down task (i.e. nice = -15) in the
presence of nr_cpus NICE0 tasks, the niced task lands on a sched group and
kicks away other tasks because of its large weight. This leads to sub-optimal
utilization of the machine. Even though the sched group has capacity, it does
not pull tasks because sds.this_load >> sds.max_load, and f_b_g() returns NULL.
With this patch, if the local group has extra capacity, we shortcut the checks
in f_b_g() and try to pull a task over. A sched group has extra capacity if the
group capacity is greater than the number of running tasks in that group.
Thanks to Mike Galbraith for discussions leading to this patch and for the
insight to reuse SD_NEWIDLE_BALANCE.
Signed-off-by: Nikhil Rao <ncrao@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1287173550-30365-4-git-send-email-ncrao@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 6e1d0fe98a1067b91a2d50040db69b18e5ef3446
Author: Nikhil Rao <ncrao@google.com>
Date: Thu Feb 10 10:23:25 2011 +0100
sched: Set group_imb only a task can be pulled from the busiest cpu
Commit: 2582f0eba54066b5e98ff2b27ef0cfa833b59f54 upstream
When cycling through sched groups to determine the busiest group, set
group_imb only if the busiest cpu has more than 1 runnable task. This patch
fixes the case where two cpus in a group have one runnable task each, but there
is a large weight differential between these two tasks. The load balancer is
unable to migrate any task from this group, and hence do not consider this
group to be imbalanced.
Signed-off-by: Nikhil Rao <ncrao@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1286996978-7007-3-git-send-email-ncrao@google.com>
[ small code readability edits ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 215856a4160cb959194e0605a9fcd6d1e71d2748
Author: Nikhil Rao <ncrao@google.com>
Date: Thu Feb 10 10:23:25 2011 +0100
sched: Do not consider SCHED_IDLE tasks to be cache hot
Commit: ef8002f6848236de5adc613063ebeabddea8a6fb upstream
This patch adds a check in task_hot to return if the task has SCHED_IDLE
policy. SCHED_IDLE tasks have very low weight, and when run with regular
workloads, are typically scheduled many milliseconds apart. There is no
need to consider these tasks hot for load balancing.
Signed-off-by: Nikhil Rao <ncrao@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1287173550-30365-2-git-send-email-ncrao@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit acb2c6dc074dabdf13b759c68d5eb7056a717d2b
Author: Peter Zijlstra <peterz@infradead.org>
Date: Thu Feb 10 10:23:08 2011 +0100
sched: fix RCU lockdep splat from task_group()
Commit: 6506cf6ce68d78a5470a8360c965dafe8e4b78e3 upstream
This addresses the following RCU lockdep splat:
[0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
[0.052999] lockdep: fixing up alternatives.
[0.054105]
[0.054106] ===================================================
[0.054999] [ INFO: suspicious rcu_dereference_check() usage. ]
[0.054999] ---------------------------------------------------
[0.054999] kernel/sched.c:616 invoked rcu_dereference_check() without protection!
[0.054999]
[0.054999] other info that might help us debug this:
[0.054999]
[0.054999]
[0.054999] rcu_scheduler_active = 1, debug_locks = 1
[0.054999] 3 locks held by swapper/1:
[0.054999] #0: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff814be933>] cpu_up+0x42/0x6a
[0.054999] #1: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff810400d8>] cpu_hotplug_begin+0x2a/0x51
[0.054999] #2: (&rq->lock){-.-...}, at: [<ffffffff814be2f7>] init_idle+0x2f/0x113
[0.054999]
[0.054999] stack backtrace:
[0.054999] Pid: 1, comm: swapper Not tainted 2.6.35 #1
[0.054999] Call Trace:
[0.054999] [<ffffffff81068054>] lockdep_rcu_dereference+0x9b/0xa3
[0.054999] [<ffffffff810325c3>] task_group+0x7b/0x8a
[0.054999] [<ffffffff810325e5>] set_task_rq+0x13/0x40
[0.054999] [<ffffffff814be39a>] init_idle+0xd2/0x113
[0.054999] [<ffffffff814be78a>] fork_idle+0xb8/0xc7
[0.054999] [<ffffffff81068717>] ? mark_held_locks+0x4d/0x6b
[0.054999] [<ffffffff814bcebd>] do_fork_idle+0x17/0x2b
[0.054999] [<ffffffff814bc89b>] native_cpu_up+0x1c1/0x724
[0.054999] [<ffffffff814bcea6>] ? do_fork_idle+0x0/0x2b
[0.054999] [<ffffffff814be876>] _cpu_up+0xac/0x127
[0.054999] [<ffffffff814be946>] cpu_up+0x55/0x6a
[0.054999] [<ffffffff81ab562a>] kernel_init+0xe1/0x1ff
[0.054999] [<ffffffff81003854>] kernel_thread_helper+0x4/0x10
[0.054999] [<ffffffff814c353c>] ? restore_args+0x0/0x30
[0.054999] [<ffffffff81ab5549>] ? kernel_init+0x0/0x1ff
[0.054999] [<ffffffff81003850>] ? kernel_thread_helper+0x0/0x10
[0.056074] Booting Node 0, Processors #1lockdep: fixing up alternatives.
[0.130045] #2lockdep: fixing up alternatives.
[0.203089] #3 Ok.
[0.275286] Brought up 4 CPUs
[0.276005] Total of 4 processors activated (16017.17 BogoMIPS).
The cgroup_subsys_state structures referenced by idle tasks are never
freed, because the idle tasks should be part of the root cgroup,
which is not removable.
The problem is that while we do in-fact hold rq->lock, the newly spawned
idle thread's cpu is not yet set to the correct cpu so the lockdep check
in task_group():
lockdep_is_held(&task_rq(p)->lock)
will fail.
But this is a chicken and egg problem. Setting the CPU's runqueue requires
that the CPU's runqueue already be set. ;-)
So insert an RCU read-side critical section to avoid the complaint.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f4de371f2acbfd0516a7123235c428f88da5c85c
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Thu Feb 10 10:22:08 2011 +0100
sched: suppress RCU lockdep splat in task_fork_fair
Commit: b0a0f667a349247bd7f05f806b662a25653822bc upstream
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> /home/greearb/git/linux.wireless-testing/kernel/sched.c:618 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
> rcu_scheduler_active = 1, debug_locks = 1
> 1 lock held by ifup/23517:
> #0: (&rq->lock){-.-.-.}, at: [<c042f782>] task_fork_fair+0x3b/0x108
>
> stack backtrace:
> Pid: 23517, comm: ifup Not tainted 2.6.36-rc6-wl+ #5
> Call Trace:
> [<c075e219>] ? printk+0xf/0x16
> [<c0455842>] lockdep_rcu_dereference+0x74/0x7d
> [<c0426854>] task_group+0x6d/0x79
> [<c042686e>] set_task_rq+0xe/0x57
> [<c042f79e>] task_fork_fair+0x57/0x108
> [<c042e965>] sched_fork+0x82/0xf9
> [<c04334b3>] copy_process+0x569/0xe8e
> [<c0433ef0>] do_fork+0x118/0x262
> [<c076302f>] ? do_page_fault+0x16a/0x2cf
> [<c044b80c>] ? up_read+0x16/0x2a
> [<c04085ae>] sys_clone+0x1b/0x20
> [<c04030a5>] ptregs_clone+0x15/0x30
> [<c0402f1c>] ? sysenter_do_call+0x12/0x38
Here a newly created task is having its runqueue assigned. The new task
is not yet on the tasklist, so cannot go away. This is therefore a false
positive, suppress with an RCU read-side critical section.
Reported-by: Ben Greear <greearb@candelatech.com
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Ben Greear <greearb@candelatech.com
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f1d703449a981bb481fe31f37782e96d6098eaf4
Author: stable-bot for Steven Rostedt <srostedt@redhat.com>
Date: Thu Feb 10 10:21:08 2011 +0100
sched: Give CPU bound RT tasks preference
From:: Steven Rostedt <srostedt@redhat.com>
Commit: b3bc211cfe7d5fe94b310480d78e00bea96fbf2a upstream
If a high priority task is waking up on a CPU that is running a
lower priority task that is bound to a CPU, see if we can move the
high RT task to another CPU first. Note, if all other CPUs are
running higher priority tasks than the CPU bounded current task,
then it will be preempted regardless.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Gregory Haskins <ghaskins@novell.com>
LKML-Reference: <20100921024138.888922071@goodmis.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f266611ef30837a9bff442e905c1a72eca218cef
Author: Steven Rostedt <srostedt@redhat.com>
Date: Thu Feb 10 10:20:08 2011 +0100
sched: Try not to migrate higher priority RT tasks
Commit: 43fa5460fe60dea5c610490a1d263415419c60f6 upstream
When first working on the RT scheduler design, we concentrated on
keeping all CPUs running RT tasks instead of having multiple RT
tasks on a single CPU waiting for the migration thread to move
them. Instead we take a more proactive stance and push or pull RT
tasks from one CPU to another on wakeup or scheduling.
When an RT task wakes up on a CPU that is running another RT task,
instead of preempting it and killing the cache of the running RT
task, we look to see if we can migrate the RT task that is waking
up, even if the RT task waking up is of higher priority.
This may sound a bit odd, but RT tasks should be limited in
migration by the user anyway. But in practice, people do not do
this, which causes high prio RT tasks to bounce around the CPUs.
This becomes even worse when we have priority inheritance, because
a high prio task can block on a lower prio task and boost its
priority. When the lower prio task wakes up the high prio task, if
it happens to be on the same CPU it will migrate off of it.
But in reality, the above does not happen much either, because the
wake up of the lower prio task, which has already been boosted, if
it was on the same CPU as the higher prio task, it would then
migrate off of it. But anyway, we do not want to migrate them
either.
To examine the scheduling, I created a test program and examined it
under kernelshark. The test program created CPU * 2 threads, where
each thread had a different priority. The program takes different
options. The options used in this change log was to have priority
inheritance mutexes or not.
All threads did the following loop:
static void grab_lock(long id, int iter, int l)
{
ftrace_write("thread %ld iter %d, taking lock %d\n",
id, iter, l);
pthread_mutex_lock(&locks[l]);
ftrace_write("thread %ld iter %d, took lock %d\n",
id, iter, l);
busy_loop(nr_tasks - id);
ftrace_write("thread %ld iter %d, unlock lock %d\n",
id, iter, l);
pthread_mutex_unlock(&locks[l]);
}
void *start_task(void *id)
{
[...]
while (!done) {
for (l = 0; l < nr_locks; l++) {
grab_lock(id, i, l);
ftrace_write("thread %ld iter %d sleeping\n",
id, i);
ms_sleep(id);
}
i++;
}
[...]
}
The busy_loop(ms) keeps the CPU spinning for ms milliseconds. The
ms_sleep(ms) sleeps for ms milliseconds. The ftrace_write() writes
to the ftrace buffer to help analyze via ftrace.
The higher the id, the higher the prio, the shorter it does the
busy loop, but the longer it spins. This is usually the case with
RT tasks, the lower priority tasks usually run longer than higher
priority tasks.
At the end of the test, it records the number of loops each thread
took, as well as the number of voluntary preemptions, non-voluntary
preemptions, and number of migrations each thread took, taking the
information from /proc/$$/sched and /proc/$$/status.
Running this on a 4 CPU processor, the results without changes to
the kernel looked like this:
Task vol nonvol migrated iterations
---- --- ------ -------- ----------
0: 53 3220 1470 98
1: 562 773 724 98
2: 752 933 1375 98
3: 749 39 697 98
4: 758 5 515 98
5: 764 2 679 99
6: 761 2 535 99
7: 757 3 346 99
total: 5156 4977 6341 787
Each thread regardless of priority migrated a few hundred times.
The higher priority tasks, were a little better but still took
quite an impact.
By letting higher priority tasks bump the lower prio task from the
CPU, things changed a bit:
Task vol nonvol migrated iterations
---- --- ------ -------- ----------
0: 37 2835 1937 98
1: 666 1821 1865 98
2: 654 1003 1385 98
3: 664 635 973 99
4: 698 197 352 99
5: 703 101 159 99
6: 708 1 75 99
7: 713 1 2 99
total: 4843 6594 6748 789
The total # of migrations did not change (several runs showed the
difference all within the noise). But we now see a dramatic
improvement to the higher priority tasks. (kernelshark showed that
the watchdog timer bumped the highest priority task to give it the
2 count. This was actually consistent with every run).
Notice that the # of iterations did not change either.
The above was with priority inheritance mutexes. That is, when the
higher prority task blocked on a lower priority task, the lower
priority task would inherit the higher priority task (which shows
why task 6 was bumped so many times). When not using priority
inheritance mutexes, the current kernel shows this:
Task vol nonvol migrated iterations
---- --- ------ -------- ----------
0: 56 3101 1892 95
1: 594 713 937 95
2: 625 188 618 95
3: 628 4 491 96
4: 640 7 468 96
5: 631 2 501 96
6: 641 1 466 96
7: 643 2 497 96
total: 4458 4018 5870 765
Not much changed with or without priority inheritance mutexes. But
if we let the high priority task bump lower priority tasks on
wakeup we see:
Task vol nonvol migrated iterations
---- --- ------ -------- ----------
0: 115 3439 2782 98
1: 633 1354 1583 99
2: 652 919 1218 99
3: 645 713 934 99
4: 690 3 3 99
5: 694 1 4 99
6: 720 3 4 99
7: 747 0 1 100
Which shows a even bigger change. The big difference between task 3
and task 4 is because we have only 4 CPUs on the machine, causing
the 4 highest prio tasks to always have preference.
Although I did not measure cache misses, and I'm sure there would
be little to measure since the test was not data intensive, I could
imagine large improvements for higher priority tasks when dealing
with lower priority tasks. Thus, I'm satisfied with making the
change and agreeing with what Gregory Haskins argued a few years
ago when we first had this discussion.
One final note. All tasks in the above tests were RT tasks. Any RT
task will always preempt a non RT task that is running on the CPU
the RT task wants to run on.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Gregory Haskins <ghaskins@novell.com>
LKML-Reference: <20100921024138.605460343@goodmis.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 00f3566f7163fda79001a30cb83387147b402dd4
Author: Venkatesh Pallipadi <venki@google.com>
Date: Thu Feb 10 09:52:52 2011 +0100
sched: Increment cache_nice_tries only on periodic lb
Commit: 58b26c4c025778c09c7a1438ff185080e11b7d0a upstream
scheduler uses cache_nice_tries as an indicator to do cache_hot and
active load balance, when normal load balance fails. Currently,
this value is changed on any failed load balance attempt. That ends
up being not so nice to workloads that enter/exit idle often, as
they do more frequent new_idle balance and that pretty soon results
in cache hot tasks being pulled in.
Making the cache_nice_tries ignore failed new_idle balance seems to
make better sense. With that only the failed load balance in
periodic load balance gets accounted and the rate of accumulation
of cache_nice_tries will not depend on idle entry/exit (short
running sleep-wakeup kind of tasks). This reduces movement of
cache_hot tasks.
schedstat diff (after-before) excerpt from a workload that has
frequent and short wakeup-idle pattern (:2 in cpu col below refers
to NEWIDLE idx) This snapshot was across ~400 seconds.
Without this change:
domainstats: domain0
cpu cnt bln fld imb gain hgain nobusyq nobusyg
0:2 306487 219575 73167 110069413 44583 19070 1172 218403
1:2 292139 194853 81421 120893383 50745 21902 1259 193594
2:2 283166 174607 91359 129699642 54931 23688 1287 173320
3:2 273998 161788 93991 132757146 57122 24351 1366 160422
4:2 289851 215692 62190 83398383 36377 13680 851 214841
5:2 316312 222146 77605 117582154 49948 20281 988 221158
6:2 297172 195596 83623 122133390 52801 21301 929 194667
7:2 283391 178078 86378 126622761 55122 22239 928 177150
8:2 297655 210359 72995 110246694 45798 19777 1125 209234
9:2 297357 202011 79363 119753474 50953 22088 1089 200922
10:2 278797 178703 83180 122514385 52969 22726 1128 177575
11:2 272661 167669 86978 127342327 55857 24342 1195 166474
12:2 293039 204031 73211 110282059 47285 19651 948 203083
13:2 289502 196762 76803 114712942 49339 20547 1016 195746
14:2 264446 169609 78292 115715605 50459 21017 982 168627
15:2 260968 163660 80142 116811793 51483 21281 1064 162596
With this change:
domainstats: domain0
cpu cnt bln fld imb gain hgain nobusyq nobusyg
0:2 272347 187380 77455 105420270 24975 1 953 186427
1:2 267276 172360 86234 116242264 28087 6 1028 171332
2:2 259769 156777 93281 123243134 30555 1 1043 155734
3:2 250870 143129 97627 127370868 32026 6 1188 141941
4:2 248422 177116 64096 78261112 22202 2 757 176359
5:2 275595 180683 84950 116075022 29400 6 778 179905
6:2 262418 162609 88944 119256898 31056 4 817 161792
7:2 252204 147946 92646 122388300 32879 4 824 147122
8:2 262335 172239 81631 110477214 26599 4 864 171375
9:2 261563 164775 88016 117203621 28331 3 849 163926
10:2 243389 140949 93379 121353071 29585 2 909 140040
11:2 242795 134651 98310 124768957 30895 2 1016 133635
12:2 255234 166622 79843 104696912 26483 4 746 165876
13:2 244944 151595 83855 109808099 27787 3 801 150794
14:2 241301 140982 89935 116954383 30403 6 845 140137
15:2 232271 128564 92821 119185207 31207 4 1416 127148
Signed-off-by: Venkatesh Pallipadi <venki@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1284167957-3675-1-git-send-email-venki@google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit deb28d43cd91df0ba8cc261532730c416679e123
Author: Suresh Siddha <suresh.b.siddha@intel.com>
Date: Thu Feb 10 09:52:07 2011 +0100
sched: Move sched_avg_update() to update_cpu_load()
Commit: da2b71edd8a7db44fe1746261410a981f3e03632 upstream
Currently sched_avg_update() (which updates rt_avg stats in the rq)
is getting called from scale_rt_power() (in the load balance context)
which doesn't take rq->lock.
Fix it by moving the sched_avg_update() to more appropriate
update_cpu_load() where the CFS load gets updated as well.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1282596171.2694.3.camel@sbsiddha-MOBL3>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 05db2a0c01f58216a33f94153cd46a9190de3514
Author: Li Zefan <lizf@cn.fujitsu.com>
Date: Thu Feb 10 09:50:40 2011 +0100
sched: Remove remaining USER_SCHED code
Commit: 32bd7eb5a7f4596c8440dd9440322fe9e686634d upstream
This is left over from commit 7c9414385e ("sched: Remove USER_SCHED"")
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Acked-by: Dhaval Giani <dhaval.giani@gmail.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: David Howells <dhowells@redhat.com>
LKML-Reference: <4BA9A05F.7010407@cn.fujitsu.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
commit b271aebc0a8e8e75c8f32cd0a9a41a0b8a6166e8
Author: Dhaval Giani <dhaval.giani@gmail.com>
Date: Thu Feb 10 09:48:04 2011 +0100
sched: Remove USER_SCHED
Commit: 7c9414385ebfdd87cc542d4e7e3bb0dbb2d3ce25 upstream
Remove the USER_SCHED feature. It has been scheduled to be removed in
2.6.34 as per http://marc.info/?l=linux-kernel&m=125728479022976&w=2
[trace from referenced thread]
[1046577.884289] general protection fault: 0000 [#1] SMP
[1046577.911332] last sysfs file: /sys/devices/platform/coretemp.7/temp1_input
[1046577.938715] CPU 3
[1046577.965814] Modules linked in: ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables coretemp k8temp
[1046577.994456] Pid: 38, comm: events/3 Not tainted 2.6.32.27intel #1 X8DT3
[1046578.023166] RIP: 0010:[] [] sched_destroy_group+0x3c/0x10d
[1046578.052639] RSP: 0000:ffff88043e5abe10 EFLAGS: 00010097
[1046578.081360] RAX: ffff880139fa5540 RBX: ffff8803d18419c0 RCX: ffff8801d2f8fb78
[1046578.109903] RDX: dead000000200200 RSI: 0000000000000000 RDI: 0000000000000000
[1046578.109905] RBP: 0000000000000246 R08: 0000000000000020 R09: ffffffff816339b8
[1046578.109907] R10: 0000000004e6e5f0 R11: 0000000000000006 R12: ffffffff816339b8
[1046578.109909] R13: ffff8803d63ac4e0 R14: ffff88043e582340 R15: ffffffff8104a216
[1046578.109911] FS: 0000000000000000(0000) GS:ffff880028260000(0000) knlGS:0000000000000000
[1046578.109914] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[1046578.109915] CR2: 00007f55ab220000 CR3: 00000001e5797000 CR4: 00000000000006e0
[1046578.109917] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[1046578.109919] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[1046578.109922] Process events/3 (pid: 38, threadinfo ffff88043e5aa000, task ffff88043e582340)
[1046578.109923] Stack:
[1046578.109924] ffff8803d63ac498 ffff8803d63ac4d8 ffff8803d63ac440 ffffffff8104a2c3
[1046578.109927] <0> ffff88043e5abef8 ffff880028276040 ffff8803d63ac4d8 ffffffff81050395
[1046578.109929] <0> ffff88043e582340 ffff88043e5826c8 ffff88043e582340 ffff88043e5abfd8
[1046578.109932] Call Trace:
[1046578.109938] [] ? cleanup_user_struct+0xad/0xcc
[1046578.109942] [] ? worker_thread+0x148/0x1d4
[1046578.109946] [] ? autoremove_wake_function+0x0/0x2e
[1046578.109948] [] ? worker_thread+0x0/0x1d4
[1046578.109951] [] ? kthread+0x79/0x81
[1046578.109955] [] ? child_rip+0xa/0x20
[1046578.109957] [] ? kthread+0x0/0x81
[1046578.109959] [] ? child_rip+0x0/0x20
[1046578.109961] Code: 3c 00 4c 8b 25 02 98 3d 00 48 89 c5 83 cf ff eb 5c 48 8b 43 10 48 63 f7 48 8b 04 f0 48 8b 90 80 00 00 00 48 8b 48 78 48 89 51 08 <48> 89 0a 48 b9 00 02 20 00 00 00 ad de 48 89 88 80 00 00 00 48
[1046578.109975] RIP [] sched_destroy_group+0x3c/0x10d
[1046578.109979] RSP
[1046578.109981] ---[ end trace 5ebc2944b7872d4a ]---
Signed-off-by: Dhaval Giani <dhaval.giani@gmail.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1263990378.24844.3.camel@localhost>
LKML-Reference: http://marc.info/?l=linux-kernel&m=129466345327931
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
commit 265fed586c302c716caa1c1bd71cb4fbb8250105
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date: Thu Dec 23 11:12:42 2010 -0800
usb: Realloc xHCI structures after a hub is verified.
commit 653a39d1f61bdc9f277766736d21d2e9be0391cb upstream.
When there's an xHCI host power loss after a suspend from memory, the USB
core attempts to reset and verify the USB devices that are attached to the
system. The xHCI driver has to reallocate those devices, since the
hardware lost all knowledge of them during the power loss.
When a hub is plugged in, and the host loses power, the xHCI hardware
structures are not updated to say the device is a hub. This is usually
done in hub_configure() when the USB hub is detected. That function is
skipped during a reset and verify by the USB core, since the core restores
the old configuration and alternate settings, and the hub driver has no
idea this happened. This bug makes the xHCI host controller reject the
enumeration of low speed devices under the resumed hub.
Therefore, make the USB core re-setup the internal xHCI hub device
information by calling update_hub_device() when hub_activate() is called
for a hub reset resume. After a host power loss, all devices under the
roothub get a reset-resume or a disconnect.
This patch should be queued for the 2.6.37 stable tree.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 45bfd7bfc6cf32f8e60bb91b32349f0b5090eea3
Author: Suresh Siddha <suresh.b.siddha@intel.com>
Date: Thu Feb 3 12:20:04 2011 -0800
x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm
commit 831d52bc153971b70e64eccfbed2b232394f22f8 upstream.
Clearing the cpu in prev's mm_cpumask early will avoid the flush tlb
IPI's while the cr3 is still pointing to the prev mm. And this window
can lead to the possibility of bogus TLB fills resulting in strange
failures. One such problematic scenario is mentioned below.
T1. CPU-1 is context switching from mm1 to mm2 context and got a NMI
etc between the point of clearing the cpu from the mm_cpumask(mm1)
and before reloading the cr3 with the new mm2.
T2. CPU-2 is tearing down a specific vma for mm1 and will proceed with
flushing the TLB for mm1. It doesn't send the flush TLB to CPU-1
as it doesn't see that cpu listed in the mm_cpumask(mm1).
T3. After the TLB flush is complete, CPU-2 goes ahead and frees the
page-table pages associated with the removed vma mapping.
T4. CPU-2 now allocates those freed page-table pages for something
else.
T5. As the CR3 and TLB caches for mm1 is still active on CPU-1, CPU-1
can potentially speculate and walk through the page-table caches
and can insert new TLB entries. As the page-table pages are
already freed and being used on CPU-2, this page walk can
potentially insert a bogus global TLB entry depending on the
(random) contents of the page that is being used on CPU-2.
T6. This bogus TLB entry being global will be active across future CR3
changes and can result in weird memory corruption etc.
To avoid this issue, for the prev mm that is handing over the cpu to
another mm, clear the cpu from the mm_cpumask(prev) after the cr3 is
changed.
Marking it for -stable, though we haven't seen any reported failure that
can be attributed to this.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 7a9e4b42c8245453c766c87b9902126b291d629f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jan 20 10:03:24 2011 +0000
drm/i915: Add dependency on CONFIG_TMPFS
commit f7ab9b407b3bc83161c2aa74c992ba4782e87c9c upstream.
Without tmpfs, shmem_readpage() is not compiled in causing an OOPS as
soon as we try to allocate some swappable pages for GEM.
Jan 19 22:52:26 harlie kernel: Modules linked in: i915(+) drm_kms_helper cfbcopyarea video backlight cfbimgblt cfbfillrect
Jan 19 22:52:26 harlie kernel:
Jan 19 22:52:26 harlie kernel: Pid: 1125, comm: modprobe Not tainted 2.6.37Harlie #10 To be filled by O.E.M./To be filled by O.E.M.
Jan 19 22:52:26 harlie kernel: EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 3
Jan 19 22:52:26 harlie kernel: EIP is at 0x0
Jan 19 22:52:26 harlie kernel: EAX: 00000000 EBX: f7b7d000 ECX: f3383100 EDX: f7b7d000
Jan 19 22:52:26 harlie kernel: ESI: f1456118 EDI: 00000000 EBP: f2303c98 ESP: f2303c7c
Jan 19 22:52:26 harlie kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Jan 19 22:52:26 harlie kernel: Process modprobe (pid: 1125, ti=f2302000 task=f259cd80 task.ti=f2302000)
Jan 19 22:52:26 harlie kernel: Stack:
Jan 19 22:52:26 harlie udevd-work[1072]: '/sbin/modprobe -b pci:v00008086d00000046sv00000000sd00000000bc03sc00i00' unexpected exit with status 0x0009
Jan 19 22:52:26 harlie kernel: c1074061 000000d0 f2f42b80 00000000 000a13d2 f2d5dcc0 00000001 f2303cac
Jan 19 22:52:26 harlie kernel: c107416f 00000000 000a13d2 00000000 f2303cd4 f8d620ed f2cee620 00001000
Jan 19 22:52:26 harlie kernel: 00000000 000a13d2 f1456118 f2d5dcc0 f1a40000 00001000 f2303d04 f8d637ab
Jan 19 22:52:26 harlie kernel: Call Trace:
Jan 19 22:52:26 harlie kernel: [<c1074061>] ? do_read_cache_page+0x71/0x160
Jan 19 22:52:26 harlie kernel: [<c107416f>] ? read_cache_page_gfp+0x1f/0x30
Jan 19 22:52:26 harlie kernel: [<f8d620ed>] ? i915_gem_object_get_pages+0xad/0x1d0 [i915]
Jan 19 22:52:26 harlie kernel: [<f8d637ab>] ? i915_gem_object_bind_to_gtt+0xeb/0x2d0 [i915]
Jan 19 22:52:26 harlie kernel: [<f8d65961>] ? i915_gem_object_pin+0x151/0x190 [i915]
Jan 19 22:52:26 harlie kernel: [<c11e16ed>] ? drm_gem_object_init+0x3d/0x60
Jan 19 22:52:26 harlie kernel: [<f8d65aa5>] ? i915_gem_init_ringbuffer+0x105/0x1e0 [i915]
Jan 19 22:52:26 harlie kernel: [<f8d571b7>] ? i915_driver_load+0x667/0x1160 [i915]
Reported-by: John J. Stimson-III <john@idsfa.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f7bf04886cbe5d7618d6b0dcb67291903cbfefa8
Author: Knut Petersen <knut_petersen@t-online.de>
Date: Fri Jan 14 15:38:10 2011 +0000
drm/i915/lvds: Add AOpen i915GMm-HFS to the list of false-positive LVDS
commit 22ab70d3262ddb6e69b3c246a34e2967ba5eb1e8 upstream.
Signed-off-by: Knut Petersen <knut_petersen@t-online.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit df3625188a1bf6d54be65b0878b7b39abf41305f
Author: Alex Deucher <alexdeucher@gmail.com>
Date: Wed Feb 2 19:46:06 2011 -0500
drm/radeon/kms: fix s/r issues with bios scratch regs
commit 87364760de5d631390c478fcbac8db1b926e0adf upstream.
The accelerate mode bit gets checked by certain atom
command tables to set up some register state. It needs
to be clear when setting modes and set when not.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=26942
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit cce639ad46294d234d3ff1feaf0718b5977b19de
Author: Alex Deucher <alexdeucher@gmail.com>
Date: Tue Feb 1 19:06:46 2011 -0500
drm/radeon: remove 0x4243 pci id
commit 63a507800c8aca5a1891d598ae13f829346e8e39 upstream.
0x4243 is a PCI bridge, not a GPU.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=33815
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit fdf06b2a372fffe242f2f024fe87ffb827d87f5b
Author: Alex Deucher <alexdeucher@gmail.com>
Date: Mon Jan 31 16:48:51 2011 -0500
drm/radeon/kms: add pll debugging output
commit 51d4bf840a27fe02c883ddc6d9708af056773769 upstream.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit e45fd967e36fc0fe7ea63437089fe690b094a5e5
Author: Alex Deucher <alexdeucher@gmail.com>
Date: Tue Jan 18 18:26:11 2011 +0000
drm/radeon/kms: make the mac rv630 quirk generic
commit be23da8ad219650517cbbb7acbeaeb235667113a upstream.
Seems some other boards do this as well.
Reported-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f06aaf2bcb9c347f36c2e6de03c0a0ae7ed3c969
Author: Alex Deucher <alexdeucher@gmail.com>
Date: Tue Jan 4 00:43:39 2011 -0500
drm/radeon/kms: add quirk for Mac Radeon HD 2600 card
commit f598aa7593427ffe3a61e7767c34bd695a5e7ed0 upstream.
Reported-by: å±‹å›½é¥ <hyagni@gmail.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 05b0d76d763e7dd670ad98500241de64ffc1a2f5
Author: Mike Snitzer <snitzer@redhat.com>
Date: Thu Jan 13 19:59:46 2011 +0000
dm mpath: disable blk_abort_queue
commit 09c9d4c9b6a2b5909ae3c6265e4cd3820b636863 upstream.
Revert commit 224cb3e981f1b2f9f93dbd49eaef505d17d894c2
dm: Call blk_abort_queue on failed paths
Multipath began to use blk_abort_queue() to allow for
lower latency path deactivation. This was found to
cause list corruption:
the cmd gets blk_abort_queued/timedout run on it and the scsi eh
somehow is able to complete and run scsi_queue_insert while
scsi_request_fn is still trying to process the request.
https://www.redhat.com/archives/dm-devel/2010-November/msg00085.html
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Cc: Mike Anderson <andmike@linux.vnet.ibm.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 67c39be22dd4201f827f85863787ad9569c2940c
Author: Mike Snitzer <snitzer@redhat.com>
Date: Thu Jan 13 19:53:46 2011 +0000
dm: dont take i_mutex to change device size
commit c217649bf2d60ac119afd71d938278cffd55962b upstream.
No longer needlessly hold md->bdev->bd_inode->i_mutex when changing the
size of a DM device. This additional locking is unnecessary because
i_size_write() is already protected by the existing critical section in
dm_swap_table(). DM already has a reference on md->bdev so the
associated bd_inode may be changed without lifetime concerns.
A negative side-effect of having held md->bdev->bd_inode->i_mutex was
that a concurrent DM device resize and flush (via fsync) would deadlock.
Dropping md->bdev->bd_inode->i_mutex eliminates this potential for
deadlock. The following reproducer no longer deadlocks:
https://www.redhat.com/archives/dm-devel/2009-July/msg00284.html
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit b2e683301e2201b7da14a52b9d0c8d2cc55a3c0d
Author: Amitkumar Karwar <akarwar@marvell.com>
Date: Tue Jan 11 16:14:24 2011 -0800
ieee80211: correct IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK macro
commit 8d661f1e462d50bd83de87ee628aaf820ce3c66c upstream.
It is defined in include/linux/ieee80211.h. As per IEEE spec.
bit6 to bit15 in block ack parameter represents buffer size.
So the bitmask should be 0xFFC0.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 638f3ef4ace0d7e1079c6f3189fa84d981deec7d
Author: Eric Paris <eparis@redhat.com>
Date: Thu Dec 2 16:13:40 2010 -0500
SELinux: do not compute transition labels on mountpoint labeled filesystems
commit 415103f9932d45f7927f4b17e3a9a13834cdb9a1 upstream.
selinux_inode_init_security computes transitions sids even for filesystems
that use mount point labeling. It shouldn't do that. It should just use
the mount point label always and no matter what.
This causes 2 problems. 1) it makes file creation slower than it needs to be
since we calculate the transition sid and 2) it allows files to be created
with a different label than the mount point!
# id -Z
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
# sesearch --type --class file --source sysadm_t --target tmp_t
Found 1 semantic te rules:
type_transition sysadm_t tmp_t : file user_tmp_t;
# mount -o loop,context="system_u:object_r:tmp_t:s0" /tmp/fs /mnt/tmp
# ls -lZ /mnt/tmp
drwx------. root root system_u:object_r:tmp_t:s0 lost+found
# touch /mnt/tmp/file1
# ls -lZ /mnt/tmp
-rw-r--r--. root root staff_u:object_r:user_tmp_t:s0 file1
drwx------. root root system_u:object_r:tmp_t:s0 lost+found
Whoops, we have a mount point labeled filesystem tmp_t with a user_tmp_t
labeled file!
Signed-off-by: Eric Paris <eparis@redhat.com>
Reviewed-by: Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 599fde16508b7684f105f4c202a823b4afd4c8c7
Author: Eric Paris <eparis@redhat.com>
Date: Thu Dec 16 11:46:51 2010 -0500
SELinux: define permissions for DCB netlink messages
commit 350e4f31e0eaf56dfc3b328d24a11bdf42a41fb8 upstream.
Commit 2f90b865 added two new netlink message types to the netlink route
socket. SELinux has hooks to define if netlink messages are allowed to
be sent or received, but it did not know about these two new message
types. By default we allow such actions so noone likely noticed. This
patch adds the proper definitions and thus proper permissions
enforcement.
Signed-off-by: Eric Paris <eparis@redhat.com>
Cc: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 25e442e2eacdc1bc8fadcd895aa40aaaf66164d3
Author: Stefan Berger <stefanb@linux.vnet.ibm.com>
Date: Tue Jan 11 14:37:29 2011 -0500
tpm_tis: Use timeouts returned from TPM
commit 9b29050f8f75916f974a2d231ae5d3cd59792296 upstream.
The current TPM TIS driver in git discards the timeout values returned
from the TPM. The check of the response packet needs to consider that
the return_code field is 0 on success and the size of the expected
packet is equivalent to the header size + u32 length indicator for the
TPM_GetCapability() result + 3 timeout indicators of type u32.
I am also adding a sysfs entry 'timeouts' showing the timeouts that are
being used.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Tested-by: Guillaume Chazarain <guichaz@gmail.com>
Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 5718043736912b35b06b55a261c294a1e467b6e8
Author: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Date: Fri Nov 12 22:30:02 2010 +0100
TPM: Long default timeout fix
commit c4ff4b829ef9e6353c0b133b7adb564a68054979 upstream.
If duration variable value is 0 at this point, it's because
chip->vendor.duration wasn't filled by tpm_get_timeouts() yet.
This patch sets then the lowest timeout just to give enough
time for tpm_get_timeouts() to further succeed.
This fix avoids long boot times in case another entity attempts
to send commands to the TPM when the TPM isn't accessible.
Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit c873af89555d5012ad0568c695e31ade2a5b17e5
Author: Tejun Heo <tj@kernel.org>
Date: Sun Jan 9 17:48:20 2011 -0500
pata_mpc52xx: inherit from ata_bmdma_port_ops
commit 77c5fd19075d299fe820bb59bb21b0b113676e20 upstream.
pata_mpc52xx supports BMDMA but inherits ata_sff_port_ops which
triggers BUG_ON() when a DMA command is issued. Fix it.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Roman Fietze <roman.fietze@telemotive.de>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 6d82749eb6e07f5cade8eb6479f74af06b96ef47
Author: NeilBrown <neilb@suse.de>
Date: Wed Jan 12 09:03:35 2011 +1100
md: fix regression with re-adding devices to arrays with no metadata
commit bf572541ab44240163eaa2d486b06f306a31d45a upstream.
Commit 1a855a0606 (2.6.37-rc4) fixed a problem where devices were
re-added when they shouldn't be but caused a regression in a less
common case that means sometimes devices cannot be re-added when they
should be.
In particular, when re-adding a device to an array without metadata
we should always access the device, but after the above commit we
didn't.
This patch sets the In_sync flag in that case so that the re-add
succeeds.
This patch is suitable for any -stable kernel to which 1a855a0606 was
applied.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 04c7ff0534cb383ecb266f0779face9bea9f828d
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Mon Jan 10 12:56:05 2011 +0100
hostap_cs: fix sleeping function called from invalid context
commit 4e5518ca53be29c1ec3c00089c97bef36bfed515 upstream.
pcmcia_request_irq() and pcmcia_enable_device() are intended
to be called from process context (first function allocate memory
with GFP_KERNEL, second take a mutex). We can not take spin lock
and call them.
It's safe to move spin lock after pcmcia_enable_device() as we
still hold off IRQ until dev->base_addr is 0 and driver will
not proceed with interrupts when is not ready.
Patch resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=643758
Reported-and-tested-by: rbugz@biobind.com
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit b5dc8db4a135a1f4505558e492621380f4adb8e8
Author: Anton Blanchard <anton@samba.org>
Date: Thu Jan 20 14:44:33 2011 -0800
kernel/smp.c: fix smp_call_function_many() SMP race
commit 6dc19899958e420a931274b94019e267e2396d3e upstream.
I noticed a failure where we hit the following WARN_ON in
generic_smp_call_function_interrupt:
if (!cpumask_test_and_clear_cpu(cpu, data->cpumask))
continue;
data->csd.func(data->csd.info);
refs = atomic_dec_return(&data->refs);
WARN_ON(refs < 0); <-------------------------
We atomically tested and cleared our bit in the cpumask, and yet the
number of cpus left (ie refs) was 0. How can this be?
It turns out commit 54fdade1c3332391948ec43530c02c4794a38172
("generic-ipi: make struct call_function_data lockless") is at fault. It
removes locking from smp_call_function_many and in doing so creates a
rather complicated race.
The problem comes about because:
- The smp_call_function_many interrupt handler walks call_function.queue
without any locking.
- We reuse a percpu data structure in smp_call_function_many.
- We do not wait for any RCU grace period before starting the next
smp_call_function_many.
Imagine a scenario where CPU A does two smp_call_functions back to back,
and CPU B does an smp_call_function in between. We concentrate on how CPU
C handles the calls:
CPU A CPU B CPU C CPU D
smp_call_function
smp_call_function_interrupt
walks
call_function.queue sees
data from CPU A on list
smp_call_function
smp_call_function_interrupt
walks
call_function.queue sees
(stale) CPU A on list
smp_call_function int
clears last ref on A
list_del_rcu, unlock
smp_call_function reuses
percpu *data A
data->cpumask sees and
clears bit in cpumask
might be using old or new fn!
decrements refs below 0
set data->refs (too late!)
The important thing to note is since the interrupt handler walks a
potentially stale call_function.queue without any locking, then another
cpu can view the percpu *data structure at any time, even when the owner
is in the process of initialising it.
The following test case hits the WARN_ON 100% of the time on my PowerPC
box (having 128 threads does help :)
#include <linux/module.h>
#include <linux/init.h>
#define ITERATIONS 100
static void do_nothing_ipi(void *dummy)
{
}
static void do_ipis(struct work_struct *dummy)
{
int i;
for (i = 0; i < ITERATIONS; i++)
smp_call_function(do_nothing_ipi, NULL, 1);
printk(KERN_DEBUG "cpu %d finished\n", smp_processor_id());
}
static struct work_struct work[NR_CPUS];
static int __init testcase_init(void)
{
int cpu;
for_each_online_cpu(cpu) {
INIT_WORK(&work[cpu], do_ipis);
schedule_work_on(cpu, &work[cpu]);
}
return 0;
}
static void __exit testcase_exit(void)
{
}
module_init(testcase_init)
module_exit(testcase_exit)
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Anton Blanchard");
I tried to fix it by ordering the read and the write of ->cpumask and
->refs. In doing so I missed a critical case but Paul McKenney was able
to spot my bug thankfully :) To ensure we arent viewing previous
iterations the interrupt handler needs to read ->refs then ->cpumask then
->refs _again_.
Thanks to Milton Miller and Paul McKenney for helping to debug this issue.
[miltonm@bga.com: add WARN_ON and BUG_ON, remove extra read of refs before initial read of mask that doesn't help (also noted by Peter Zijlstra), adjust comments, hopefully clarify scenario ]
[miltonm@bga.com: remove excess tests]
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Milton Miller <miltonm@bga.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 8dfd49103914a72c64f0bbd88411125b03f44772
Author: Guy Martin <gmsoft@tuxicoman.be>
Date: Mon Dec 6 16:48:04 2010 +0100
parisc : Remove broken line wrapping handling pdc_iodc_print()
commit fbea668498e93bb38ac9226c7af9120a25957375 upstream.
Remove the broken line wrapping handling in pdc_iodc_print().
It is broken in 3 ways :
- It doesn't keep track of the current screen position, it just
assumes that the new buffer will be printed at the begining of the
screen.
- It doesn't take in account that non printable characters won't
increase the current position on the screen.
- And last but not least, it triggers a kernel panic if a backspace
is the first char in the provided buffer :
Backtrace:
[<0000000040128ec4>] pdc_console_write+0x44/0x78
[<0000000040128f18>] pdc_console_tty_write+0x20/0x38
[<000000004032f1ac>] n_tty_write+0x2a4/0x550
[<000000004032b158>] tty_write+0x1e0/0x2d8
[<00000000401bb420>] vfs_write+0xb8/0x188
[<00000000401bb630>] sys_write+0x68/0xb8
[<0000000040104eb8>] syscall_exit+0x0/0x14
Most terminals handle the line wrapping just fine. I've confirmed that
it works correctly on a C8000 with both vga and serial output.
Signed-off-by: Guy Martin <gmsoft@tuxicoman.be>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 6513be80668759a78d1acc8d5a149140c7f4d009
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu Jan 20 20:35:23 2011 +0000
powerpc: Fix some 6xx/7xxx CPU setup functions
commit 1f1936ff3febf38d582177ea319eaa278f32c91f upstream.
Some of those functions try to adjust the CPU features, for example
to remove NAP support on some revisions. However, they seem to use
r5 as an index into the CPU table entry, which might have been right
a long time ago but no longer is. r4 is the right register to use.
This probably caused some off behaviours on some PowerMac variants
using 750cx or 7455 processor revisions.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit d845c588162145fa6fa7bf49bd07f3fb7e767c5a
Author: David Miller <davem@davemloft.net>
Date: Sun Feb 13 16:37:07 2011 -0800
klist: Fix object alignment on 64-bit.
commit 795abaf1e4e188c4171e3cd3dbb11a9fcacaf505 upstream.
Commit c0e69a5bbc6f ("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: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 018f58922d74c64c8b9f48cb0f336d715ae00078
Author: Dario Lombardo <dario.lombardo@libero.it>
Date: Fri Jan 21 15:35:19 2011 +0100
drivers: update to pl2303 usb-serial to support Motorola cables
commit 96a3e79edff6f41b0f115a82f1a39d66218077a7 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: Greg Kroah-Hartman <gregkh@suse.de>
commit a0320bb9c2bca6f40e5753c17446135ae656da62
Author: Simone Contini <s.contini@oltrelinux.com>
Date: Mon Apr 12 23:25:10 2010 +0200
USB: serial: pl2303: Hybrid reader Uniform HCR331
commit 18344a1cd5889d48dac67229fcf024ed300030d5 upstream.
I tried a magnetic stripe reader
(http://www.kimaldi.com/kimaldi_eng/productos/lectores_de_tarjetas/lectores_tarjeta_chip_y_dni/lector_hibrido_uniform_hcr_331)
and I see that it is interfaced with a PL2303. I wrote a patch to use
your driver which simply adds the product ID for the device and it
seems working fine.
From: Simone Contini <s.contini@oltrelinux.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 01a3ca1a18a394231fc5865ca365722c02b0fe4d
Author: Tim Deegan <Tim.Deegan@citrix.com>
Date: Thu Feb 10 08:50:41 2011 +0000
fix jiffy calculations in calibrate_delay_direct to handle overflow
commit 70a062286b9dfcbd24d2e11601aecfead5cf709a 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: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit bb103a6907a1d23f1b1a5110794b0a08c2b9ac26
Author: Suresh Siddha <suresh.b.siddha@intel.com>
Date: Wed Feb 2 17:02:55 2011 -0800
x86, mtrr: Avoid MTRR reprogramming on BP during boot on UP platforms
commit f7448548a9f32db38f243ccd4271617758ddfe2c 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 d0af9eed5aa91b6b7b5049cae69e5ea956fd85c3
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 d0af9eed5aa91b6b7b5049cae69e5ea956fd85c3, 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: Markus Kohn <jabber@gmx.org>
Signed-off-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: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 16d0a1bf7848b5eaf520a9467e7c99c1e7064dfb
Author: Tejun Heo <tj@kernel.org>
Date: Thu Feb 10 15:01:22 2011 -0800
ptrace: use safer wake up on ptrace_detach()
commit 01e05e9a90b8f4c3997ae0537e87720eb475e532 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit bd577e06041f41ac77c8e44ad4047502483cc439
Author: Pavel Machek <pavel@ucw.cz>
Date: Sun Jan 9 08:38:48 2011 +0100
serial: unbreak billionton CF card
commit d0694e2aeb815042aa0f3e5036728b3db4446f1d upstream.
Unbreak Billionton CF bluetooth card. This actually fixes a regression
on zaurus.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit c514f424190f82233365de5293cecc5cbb23ed9c
Author: Jean Delvare <khali@linux-fr.org>
Date: Fri Jan 14 22:03:49 2011 +0100
i2c: Unregister dummy devices last on adapter removal
commit 5219bf884b6e2b54e734ca1799b6f0014bb2b4b7 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: Greg Kroah-Hartman <gregkh@suse.de>
commit 524d108836b3f33e143f539c947475be8d43a655
Author: Christian Lamparter <chunkeey@googlemail.com>
Date: Thu Jan 6 23:47:52 2011 +0100
p54: fix sequence no. accounting off-by-one error
commit 3b5c5827d1f80ad8ae844a8b1183f59ddb90fe25 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: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 3a3425ed91e96b56ab21227c93d8ce4c94510feb
Author: Sven Neumann <s.neumann@raumfeld.com>
Date: Fri Nov 12 11:36:22 2010 +0100
ds2760_battery: Fix calculation of time_to_empty_now
commit 86af95039b69a90db15294eb1f9c147f1df0a8ea upstream.
A check against division by zero was modified in commit b0525b48.
Since this change time_to_empty_now is always reported as zero
while the battery is discharging and as a negative value while
the battery is charging. This is because current is negative while
the battery is discharging.
Fix the check introduced by commit b0525b48 so that time_to_empty_now
is reported correctly during discharge and as zero while charging.
Signed-off-by: Sven Neumann <s.neumann@raumfeld.com>
Acked-by: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 518874df037d8db7eb03688586a44a99b840bb2a
Author: Milton Miller <miltonm@bga.com>
Date: Fri Jan 7 02:55:06 2011 -0600
virtio: remove virtio-pci root device
commit 8b3bb3ecf1934ac4a7005ad9017de1127e2fbd2f upstream.
We sometimes need to map between the virtio device and
the given pci device. One such use is OS installer that
gets the boot pci device from BIOS and needs to
find the relevant block device. Since it can't,
installation fails.
Instead of creating a top-level devices/virtio-pci
directory, create each device under the corresponding
pci device node. Symlinks to all virtio-pci
devices can be found under the pci driver link in
bus/pci/drivers/virtio-pci/devices, and all virtio
devices under drivers/bus/virtio/devices.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Gleb Natapov <gleb@redhat.com>
Tested-by: "Daniel P. Berrange" <berrange@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 4ff49d83acf048f949e2082f577e2fa36b0cfa37
Author: Tejun Heo <tj@kernel.org>
Date: Wed Dec 22 10:06:36 2010 +0100
PCI: pci-stub: ignore zero-length id parameters
commit 99a0fadf561e1f553c08f0a29f8b2578f55dd5f0 upstream.
pci-stub uses strsep() to separate list of ids and generates a warning
message when it fails to parse an id. However, not specifying the
parameter results in ids set to an empty string. strsep() happily
returns the empty string as the first token and thus triggers the
warning message spuriously.
Make the tokner ignore zero length ids.
Reported-by: Chris Wright <chrisw@sous-sol.org>
Reported-by: Prasad Joshi <P.G.Joshi@student.reading.ac.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 6399e7b53fe9eb4289e6dfc987e09f393da8aba1
Author: Thomas Taranowski <tom@baringforge.com>
Date: Wed Jan 12 17:00:44 2011 -0800
rapidio: fix hang on RapidIO doorbell queue full condition
commit 12a4dc43911785f51a596f771ae0701b18d436f1 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: Greg Kroah-Hartman <gregkh@suse.de>
commit 9980ac8114583f0e40492bbe36e7c82a410bbec9
Author: Don Fry <donald.h.fry@intel.com>
Date: Sun Feb 6 09:29:45 2011 -0800
iwlagn: Re-enable RF_KILL interrupt when down
commit 3dd823e6b86407aed1a025041d8f1df77e43a9c8 upstream.
With commit 554d1d027b19265c4aa3f718b3126d2b86e09a08 only one RF_KILL
interrupt will be seen by the driver when the interface is down.
Re-enable the interrupt when it occurs to see all transitions.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit be35d0253b65307932a065d12c18a9ac9e52b161
Author: Paul Fox <pgf@laptop.org>
Date: Wed Jan 12 17:00:07 2011 -0800
rtc-cmos: fix suspend/resume
commit 2fb08e6ca9f00d1aedb3964983e9c8f84b36b807 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit b365683faf48505e05fdd48001ccf5dbd22aeabd
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Fri Jan 21 15:54:57 2011 +0000
NFS: Fix "kernel BUG at fs/aio.c:554!"
commit 839f7ad6932d95f4d5ae7267b95c574714ff3d5b 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 <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 3680eb53aaa92d88d06bb6f50ef3be0b8b2628dc
Author: Mike Frysinger <vapier@gentoo.org>
Date: Tue Jan 11 19:57:33 2011 -0500
ASoC: Blackfin AC97: fix build error after multi-component update
commit e9c2048915048d605fd76539ddd96f00d593e1eb upstream.
We need to tweak how we query the active capture/playback state after
the recent overhauls of common code.
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: Greg Kroah-Hartman <gregkh@suse.de>
commit 845e2327784e47e42e20b231b51046a95d868067
Author: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Date: Fri Jan 14 15:59:13 2011 +0000
ASoC: WM8990: msleep() takes milliseconds not jiffies
commit 7ebcf5d6021a696680ee77d9162a2edec2d671dd upstream.
Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 9f2d7ebc444664e791e357075ebb80174fb7daf6
Author: Clemens Ladisch <clemens@ladisch.de>
Date: Thu Feb 10 16:15:44 2011 +0100
ALSA: hrtimer: handle delayed timer interrupts
commit b1d4f7f4bdcf9915c41ff8cfc4425c84dabb1fde 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: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 1e81d74b8bbd77d990a367cbe380637eaa12513d
Author: Edgar (gimli) Hucek <gimli@dark-green.com>
Date: Tue Nov 9 17:38:42 2010 +0100
input: bcm5974: Add support for MacBookAir3
commit 6021afcf19d8c6f5db6d11cadcfb6a22d0c28a48 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: Greg Kroah-Hartman <gregkh@suse.de>
commit 366bc80896e5789386d6cf81189dad4106e64712
Author: Jiri Kosina <jkosina@suse.cz>
Date: Sat Jan 8 01:37:26 2011 -0800
Input: i8042 - introduce 'notimeout' blacklist for Dell Vostro V13
commit f8313ef1f448006207f12c107123522c8bc00f15 upstream.
i8042 controller present in Dell Vostro V13 errorneously signals spurious
timeouts.
Introduce i8042.notimeout parameter for ignoring i8042-signalled timeouts
and apply this quirk automatically for Dell Vostro V13, based on DMI match.
In addition to that, this machine also needs to be added to nomux blacklist.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Cc: Tim Gardner <tcanonical@tpi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit fd9ea125b48590b9b21a7fa5e8879334fac9831b
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Feb 2 17:16:38 2011 +0100
ALSA: hda - Fix memory leaks in conexant jack arrays
commit 70f7db11c45a313b23922cacf248c613c3b2144c upstream.
The Conexant codec driver adds the jack arrays in init callback which
may be called also in each PM resume. This results in the addition of
new jack element at each time.
The fix is to check whether the requested jack is already present in
the array.
Reference: Novell bug 668929
https://bugzilla.novell.com/show_bug.cgi?id=668929
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit fe46374bd611afa1a17c08ac623f777453fd9c34
Author: David Henningsson <david.henningsson@canonical.com>
Date: Tue Jan 25 19:44:26 2011 +0100
ALSA: HDA: Fix dmesg output of HDMI supported bits
commit d757534ed15387202e322854cd72dc58bbb975de upstream.
This typo caused the dmesg output of the supported bits of HDMI
to be cut off early.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 6b7efe67a438a783fe5dbb08500fbd17102172b2
Author: Raymond Yau <superquad.vortex2@gmail.com>
Date: Sun Jan 16 10:55:54 2011 +0800
ALSA : au88x0 - Limit number of channels to fix Oops via OSS emu
commit d9ab344336f74c012f6643ed3d1ad8ca0136de3b upstream.
Fix playback/capture channels patch to change supported playback
channels of au8830 to 1,2,4 and capture channels to 1,2.
This prevent oops when oss emulation use SNDCTL_DSP_CHANNELS to
set 3 Channels
Signed-off-by: Raymond Yau <superquad.vortex2@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 00fac7c1a420f8e48a2f70c37bdb8c80c73d5c01
Author: Mauro Carvalho Chehab <mchehab@redhat.com>
Date: Mon Oct 25 17:51:15 2010 -0300
em28xx: Fix audio input for Terratec Grabby
commit a3fa904ec79b94f0db7faed010ff94d42f7d1d47 upstream.
The audio input line was wrong. Fix it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 4e01d9a60906a6bd5748a19dafc7e0578a24f2ac
Author: Mauro Carvalho Chehab <mchehab@redhat.com>
Date: Thu Jan 6 08:16:04 2011 -0200
radio-aimslab.c: Fix gcc 4.5+ bug
commit e3c92215198cb6aa00ad38db2780faa6b72e0a3f upstream.
gcc 4.5+ doesn't properly evaluate some inlined expressions.
A previous patch were proposed by Andrew Morton using noinline.
However, the entire inlined function is bogus, so let's just
remove it and be happy.
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 42bae3676e4369425e79af00a8ad88ca070dacc1
Author: Kashyap, Desai <kashyap.desai@lsi.com>
Date: Tue Jan 4 11:38:39 2011 +0530
mpt2sas: Kernel Panic during Large Topology discovery
commit 4224489f45b503f0a1f1cf310f76dc108f45689a upstream.
There was a configuration page timing out during the initial port
enable at driver load time. The port enable would fail, and this would
result in the driver unloading itself, meanwhile the driver was accessing
freed memory in another context resulting in the panic. The fix is to
prevent access to freed memory once the driver had issued the diag reset
which woke up the sleeping port enable process. The routine
_base_reset_handler was reorganized so the last sleeping process woken up was
the port_enable.
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 084b3706631ae3776e9b6805622b57d783a3ae3b
Author: Kashyap, Desai <kashyap.desai@lsi.com>
Date: Tue Jan 4 11:34:57 2011 +0530
mpt2sas: Correct resizing calculation for max_queue_depth
commit 11e1b961ab067ee3acaf723531da4d3f23e1d6f7 upstream.
The ioc->hba_queue_depth is not properly resized when the controller
firmware reports that it supports more outstanding IO than what can be fit
inside the reply descriptor pool depth. This is reproduced by setting the
controller global credits larger than 30,000. The bug results in an
incorrect sizing of the queues. The fix is to resize the queue_size by
dividing queue_diff by two.
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit a0d877da29837d8b0852ae0a236529d4e734ab1e
Author: Kashyap, Desai <kashyap.desai@lsi.com>
Date: Tue Jan 4 11:32:13 2011 +0530
mpt2sas: Fix device removal handshake for zoned devices
commit 4dc2757a2e9a9d1f2faee4fc6119276fc0061c16 upstream.
When zoning end devices, the driver is not sending device
removal handshake alogrithm to firmware. This results in controller
firmware not sending sas topology add events the next time the device is
added. The fix is the driver should be doing the device removal handshake
even though the PHYSTATUS_VACANT bit is set in the PhyStatus of the
event data. The current design is avoiding the handshake when the
VACANT bit is set in the phy status.
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit ea8027f35061c4a8ded0b6dc53743ea1f3f6a839
Author: James Bottomley <James.Bottomley@suse.de>
Date: Thu Jan 20 17:26:44 2011 -0600
libsas: fix runaway error handler problem
commit 9ee91f7fb550a4c82f82d9818e42493484c754af upstream.
libsas makes use of scsi_schedule_eh() but forgets to clear the
host_eh_scheduled flag in its error handling routine. Because of this,
the error handler thread never gets to sleep; it's constantly awake and
trying to run the error routine leading to console spew and inability to
run anything else (at least on a UP system). The fix is to clear the
flag as we splice the work queue.
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit dd049cc831488809c22281bbef77eee1d0bd0395
Author: James Bottomley <James.Bottomley@suse.de>
Date: Fri Dec 17 15:36:34 2010 -0500
fix medium error problems with some arrays which can cause data corruption
commit a8733c7baf457b071528e385a0b7d4aaec79287c upstream.
Our current handling of medium error assumes that data is returned up
to the bad sector. This assumption holds good for all disk devices,
all DIF arrays and most ordinary arrays. However, an LSI array engine
was recently discovered which reports a medium error without returning
any data. This means that when we report good data up to the medium
error, we've reported junk originally in the buffer as good. Worse,
if the read consists of requested data plus a readahead, and the error
occurs in readahead, we'll just strip off the readahead and report
junk up to userspace as good data with no error.
The fix for this is to have the error position computation take into
account the amount of data returned by the driver using the scsi
residual data. Unfortunately, not every driver fills in this data,
but for those who don't, it's set to zero, which means we'll think a
full set of data was transferred and the behaviour will be identical
to the prior behaviour of the code (believe the buffer up to the error
sector). All modern drivers seem to set the residual, so that should
fix up the LSI failure/corruption case.
Reported-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit bbdd08ebd2bfa1a6c337e6a85a5bf64223bb41bf
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date: Fri Feb 26 22:37:54 2010 +0100
correct vdso version string
commit 13c6680acb3df25722858566b42759215ea5d2e0 upstream.
The glibc vdso code for s390 uses the version string 2.6.29, the
kernel uses the version string 2.6.26. No wonder the vdso code
is never used. The first kernel version to contain the vdso code
is 2.6.29 which makes this the correct version.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 092c913d48c3f592a9ba116429ed7489e4d263e2
Author: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Date: Wed Nov 10 05:03:15 2010 -0800
ath9k: Fix bug in delimiter padding computation
commit 39ec2997c374b528cdbf65099b6d6b8593a67f7f upstream.
There is a roundng error in delimiter padding computation
which causes severe throughput drop with some of AR9003.
signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 23b85e641a0189357462e3cab55e1d93e85428d1
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Thu Dec 23 12:38:21 2010 +0100
iwlagn: enable only rfkill interrupt when device is down
commit 554d1d027b19265c4aa3f718b3126d2b86e09a08 upstream.
Since commit 6cd0b1cb872b3bf9fc5de4536404206ab74bafdd "iwlagn: fix
hw-rfkill while the interface is down", we enable interrupts when
device is not ready to receive them. However hardware, when it is in
some inconsistent state, can generate other than rfkill interrupts
and crash the system. I can reproduce crash with "kernel BUG at
drivers/net/wireless/iwlwifi/iwl-agn.c:1010!" message, when forcing
firmware restarts.
To fix only enable rfkill interrupt when down device and after probe.
I checked patch on laptop with 5100 device, rfkill change is still
passed to user space when device is down.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit f3a234342aa4ceb45adf1e11c16b11fdb297300c
Author: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Date: Mon Mar 8 12:25:15 2010 +0100
hvc_iucv: allocate memory buffers for IUCV in zone DMA
commit 91a970d9889c7d6f451ee91ed361d0f0119d3778 upstream.
The device driver must allocate memory for IUCV buffers with GFP_DMA,
because IUCV cannot address memory above 2GB (31bit addresses only).
Because the IUCV ignores the higher bits of the address, sending and
receiving IUCV data with this driver might cause memory corruptions.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: maximilian attems <max@stro.at>
commit 47aab12693ef835f80c1d49f0f24b062dcac629b
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date: Wed Feb 2 13:42:58 2011 -0800
staging: hv: Enable sending GARP packet after live migration
commit 7c161d0b900ea9bd9fc5ea5d3fa9916e9eb0dd88 upstream.
The hv_netvsc gets RNDIS_STATUS_MEDIA_CONNECT event after the VM
is live migrated. Adding call to netif_notify_peers() for this event
to send GARP (Gratuitous ARP) to notify network peers. Otherwise,
the VM's network connection may stop after a live migration.
This patch should also be applied to stable kernel 2.6.32 and later.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit df8ce7c6f9bbc168c52a9e5412b0dd3e31fb29d6
Author: Ky Srinivasan <ksrinivasan@novell.com>
Date: Thu Dec 16 18:59:19 2010 -0700
Staging: hv: fix sysfs symlink on hv block device
commit 268eff909afaca93188d2d14554cbf824f6a0e41 upstream.
The block device does not create the proper symlink in sysfs because we
forgot to set up the gendisk structure properly. This patch fixes the
issue.
Signed-off-by: K. Y. Srinivasan <ksrinivasan@novell.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 3b7c17442d1bee08df0bf35ffb31d5d4847c823c
Author: Ian Abbott <abbotti@mev.co.uk>
Date: Wed Jan 19 11:48:44 2011 +0000
staging: comedi: ni_labpc: Use shared IRQ for PCMCIA card
commit d1ce318496f5943d2cc5e20171fc383a59a1421f upstream.
The ni_labpc driver module only requests a shared IRQ for PCI devices,
requesting a non-shared IRQ for non-PCI devices.
As this module is also used by the ni_labpc_cs module for certain
National Instruments PCMCIA cards, it also needs to request a shared IRQ
for PCMCIA devices, otherwise you get a IRQ mismatch with the CardBus
controller.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit e3173458bd06d19f93c0af3aded9caaf02a6f5f9
Author: Ruben Smits <ruben.smits@mech.kuleuven.be>
Date: Sat Dec 11 08:26:18 2010 +0100
staging: comedi: add support for newer jr3 1-channel pci board
commit 6292817d58637f85dd623cfe563c7f5ec4f4c470 upstream.
add DEVICE_ID to table
Signed-off-by: Ruben Smits <ruben.smits@mech.kuleuven.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 0df14562c291a90c9e74f80b5ee671df474de6cb
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Mon Jan 31 10:56:37 2011 -0500
USB: prevent buggy hubs from crashing the USB stack
commit d199c96d41d80a567493e12b8e96ea056a1350c1 upstream.
If anyone comes across a high-speed hub that (by mistake or by design)
claims to have no Transaction Translators, plugging a full- or
low-speed device into it will cause the USB stack to crash. This
patch (as1446) prevents the problem by ignoring such devices, since
the kernel has no way to communicate with them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Perry Neben <neben@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 244fd77310911f6bbe92a2b62e91b85621094107
Author: Michael Williamson <michael.h.williamson@gmail.com>
Date: Thu Jan 27 18:36:19 2011 -0600
USB: ftdi_sio: Add VID=0x0647, PID=0x0100 for Acton Research spectrograph
commit 28fe2eb0162a1d23370dd99ff7d0e35632b1ee91 upstream.
Add the USB Vendor ID and Product ID for a Acton Research Corp.
spectrograph device with a FTDI chip for serial I/O.
Signed-off-by: Michael H Williamson <michael.h.williamson@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit b04d5729e9261f0834344122af34bfcf4b5ac65a
Author: Arvid Ephraim Picciani <arvid.picciani@nokia.com>
Date: Tue Jan 25 15:58:40 2011 +0100
USB: cdc-acm: Adding second ACM channel support for Nokia N8
commit 721d92fc6373dee15846216f9d178ec240ec0fd7 upstream.
This adds the N8 to the list of devices in cdc-acm, in order to get the
secondary ACM device exposed.
In the spirit of:
http://kerneltrap.org/mailarchive/linux-usb/2010/9/4/6264554
Signed-off-by: Arvid Ephraim Picciani <arvid.picciani@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit cbb040960b82ff530af0249c324650256bdddde5
Author: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Date: Sat Jan 29 15:32:52 2011 +0100
USB: ftdi_sio: add ST Micro Connect Lite uart support
commit 6ec2f46c4b4abf48c88c0ae7c476f347b97e1105 upstream.
on ST Micro Connect Lite we have 4 port
Part A and B for the JTAG
Port C Uart
Port D for PIO
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit d5e403535d8a03932c2692a64d11f3c8b57409d3
Author: Nick Holloway <Nick.Holloway@pyrites.org.uk>
Date: Wed Jan 26 21:47:43 2011 +0000
USB: Storage: Add unusual_devs entry for VTech Kidizoom
commit c25f6b1591b158f7ae3b9132367d0fa6d632e70e upstream.
This device suffers from the off-by-one error when reporting the capacity,
so add entry with US_FL_FIX_CAPACITY.
Signed-off-by: Nick Holloway <Nick.Holloway@pyrites.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit e4aa87db536270f7861bfe63d8471133900f864b
Author: Ionut Nicu <ionut.nicu@gmail.com>
Date: Tue Dec 28 22:21:08 2010 +0200
USB: ti_usb: fix module removal
commit b14de3857227cd978f515247853fd15cc2425d3e upstream.
If usb_deregister() is called after usb_serial_deregister() when
the device is plugged in, the following Oops occurs:
[ 95.337377] BUG: unable to handle kernel NULL pointer dereference at 00000010
[ 95.338236] IP: [<c0776b2d>] klist_put+0x12/0x62
[ 95.338356] *pdpt = 000000003001a001 *pde = 0000000000000000
[ 95.338356] Oops: 0000 [#1] SMP
[ 95.340499] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.2/usb8/idVendor
[ 95.340499] Modules linked in: ti_usb_3410_5052(-) usbserial cpufreq_ondemand acpi_cpufreq mperf iptable_nat nf_nat iptable_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput arc4 ecb iwlagn iwlcore mac80211 cfg80211 microcode pcspkr acer_wmi joydev wmi sky2 [last unloaded: scsi_wait_scan]
[ 95.341908]
[ 95.341908] Pid: 1532, comm: modprobe Not tainted 2.6.37-rc7+ #6 Eiger /Aspire 5930
[ 95.341908] EIP: 0060:[<c0776b2d>] EFLAGS: 00010246 CPU: 0
[ 95.341908] EIP is at klist_put+0x12/0x62
[ 95.341908] EAX: 00000000 EBX: eedc0c84 ECX: c09c21b4 EDX: 00000001
[ 95.341908] ESI: 00000000 EDI: efaa0c1c EBP: f214fe2c ESP: f214fe1c
[ 95.341908] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 95.341908] Process modprobe (pid: 1532, ti=f214e000 task=efaaf080 task.ti=f214e000)
[ 95.341908] Stack:
[ 95.341908] f214fe24 eedc0c84 efaaf080 efaa0c1c f214fe34 c0776ba8 f214fe5c c0776c76
[ 95.341908] c09c21b4 c09c21b4 eedc0c84 efaaf080 00000000 c0634398 eafe2d1c f7b515f0
[ 95.341908] f214fe6c c0631b5c eafe2d50 eafe2d1c f214fe7c c0631ba2 eafe2d1c eafe2c00
[ 95.341908] Call Trace:
[ 95.341908] [<c0776ba8>] ? klist_del+0xd/0xf
[ 95.341908] [<c0776c76>] ? klist_remove+0x48/0x74
[ 95.341908] [<c0634398>] ? devres_release_all+0x49/0x51
[ 95.341908] [<c0631b5c>] ? __device_release_driver+0x7b/0xa4
[ 95.341908] [<c0631ba2>] ? device_release_driver+0x1d/0x28
[ 95.341908] [<c06317c4>] ? bus_remove_device+0x92/0xa1
[ 95.341908] [<c062f3d8>] ? device_del+0xf9/0x13e
[ 95.341908] [<f7b06146>] ? usb_serial_disconnect+0xd9/0x116 [usbserial]
[ 95.341908] [<c0681e3f>] ? usb_disable_interface+0x32/0x40
[ 95.341908] [<c0683972>] ? usb_unbind_interface+0x48/0xfd
[ 95.341908] [<c0631b43>] ? __device_release_driver+0x62/0xa4
[ 95.341908] [<c06320b9>] ? driver_detach+0x62/0x81
[ 95.341908] [<c0631a41>] ? bus_remove_driver+0x8f/0xae
[ 95.341908] [<c063214c>] ? driver_unregister+0x50/0x57
[ 95.341908] [<c0682f95>] ? usb_deregister+0x77/0x84
[ 95.341908] [<f7b505b6>] ? ti_exit+0x26/0x28 [ti_usb_3410_5052]
[ 95.341908] [<c046a307>] ? sys_delete_module+0x181/0x1de
[ 95.341908] [<c04e2727>] ? path_put+0x1a/0x1d
[ 95.341908] [<c047f4c5>] ? audit_syscall_entry+0x116/0x138
[ 95.341908] [<c04094df>] ? sysenter_do_call+0x12/0x28
[ 95.341908] Code: 00 83 7d f0 00 74 09 85 f6 74 05 89 f0 ff 55 f0 8b 43 04 5a 5b 5e 5f 5d c3 55 89 e5 57 56 53 89 c3 83 ec 04 8b 30 83 e6 fe 89 f0 <8b> 7e 10 88 55 f0 e8 47 26 01 00 8a 55 f0 84 d2 74 17 f6 03 01
[ 95.341908] EIP: [<c0776b2d>] klist_put+0x12/0x62 SS:ESP 0068:f214fe1c
[ 95.341908] CR2: 0000000000000010
[ 95.342357] ---[ end trace 8124d00ad871ad18 ]---
Signed-off-by: Ionut Nicu <ionut.nicu@mindbit.ro>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit e6ce8fe6ad7daa30685381e22058e1625f7fcb70
Author: Bjørn Mork <bjorn@mork.no>
Date: Mon Jan 17 14:19:37 2011 +0100
USB: io_edgeport: fix the reported firmware major and minor
commit 271c1150b4f8e1685e5a8cbf76e329ec894481da upstream.
The major and minor number saved in the product_info structure
were copied from the address instead of the data, causing an
inconsistency in the reported versions during firmware loading:
usb 4-1: firmware: requesting edgeport/down.fw
/usr/src/linux/drivers/usb/serial/io_edgeport.c: downloading firmware version (930) 1.16.4
[..]
/usr/src/linux/drivers/usb/serial/io_edgeport.c: edge_startup - time 3 4328191260
/usr/src/linux/drivers/usb/serial/io_edgeport.c: FirmwareMajorVersion 0.0.4
This can cause some confusion whether firmware loaded successfully
or not.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 88721a2f24cae27132ed54dc2e6e4ae093621bcc
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Mon Jan 10 11:24:14 2011 -0500
USB: g_printer: fix bug in module parameter definitions
commit ad84e4a9efb7c8ed322bafb6ebdb9c3a49a3d3a8 upstream.
This patch (as1442) fixes a bug in g_printer: Module parameters should
not be marked "__initdata" if they are accessible in sysfs (i.e., if
the mode value in the module_param() macro is nonzero). Otherwise
attempts to access the parameters will cause addressing violations.
Character-string module parameters must not be marked "__initdata"
if the module can be unloaded, because the kernel needs to access the
parameter variable at unload time in order to free the
dynamically-allocated string.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Roland Kletzing <devzero@web.de>
CC: Craig W. Nadler <craig@nadler.us>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit bd49d662e09555107eca05d29f849fb40e31c49c
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Thu Jan 6 10:17:09 2011 -0500
USB: EHCI: fix DMA deallocation bug
commit f75593ceaa08e6d27aec1a5de31cded19e850dd1 upstream.
This patch (as1440) fixes a bug in ehci-hcd. ehci->periodic_size is
used to compute the size in a dma_alloc_coherent() call, but then it
gets changed later on. As a result, the corresponding call to
dma_free_coherent() passes a different size from the original
allocation. Fix the problem by adjusting ehci->periodic_size before
carrying out any of the memory allocations.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 4e588965b910e1f364d7fcd8c36281e341e43e2e
Author: Alex He <alex.he@amd.com>
Date: Tue Dec 21 17:45:46 2010 +0800
USB: EHCI: ASPM quirk of ISOC on AMD Hudson
commit baab93afc2844b68d57b0dcca5e1d34c5d7cf411 upstream.
AMD Hudson also needs the same ASPM quirk as SB800
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 4155a3a3e86176cb26adf9fee545b4e0355ded0e
Author: Nicolaus Colberg <nicolaus.colberg@cinterion.com>
Date: Wed Jan 12 16:30:03 2011 +0100
USB: adding USB support for Cinterion's HC2x, EU3 and PH8 products
commit aa52b3a92918039b273fc9d1994bd34227c40269 upstream.
/drivers/usb/serial/option.c: Adding support for Cinterion's HC25, HC28,
HC28J, EU3-E, EU3-P and PH8 by correcting/adding Cinterion's and
Siemens' Vendor IDs as well as Product IDs and USB_DEVICE tuples
Signed-off-by: Nicolaus Colberg <nicolaus.colberg@cinterion.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 773fc4ef6bdabd94b51be0c6b55c426247726356
Author: Pieter Maes <maescool@gmail.com>
Date: Tue Jan 18 00:26:16 2011 +0100
USB: serial: Updated support for ICOM devices
commit a9d61bc49188e32d2ae9cf0f683cde3e1744feef upstream.
I found the original patch on the db0fhn repeater wiki (couldn't find the email
of the origial author) I guess it was never commited.
I updated and added some Icom HAM-radio devices to the ftdi driver.
Added extra comments to make clear what devices it are.
Signed-off-by: Pieter Maes <maescool@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 69124c7b494704af342411e00435435a40ab133b
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Tue Jan 25 13:07:04 2011 -0500
USB: usb-storage: unusual_devs entry for Coby MP3 player
commit 3ea3c9b5a8464ec8223125f95e5dddb3bfd02a39 upstream.
This patch (as1444) adds an unusual_devs entry for an MP3 player from
Coby electronics. The device has two nasty bugs.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jasper Mackenzie <scarletpimpernal@hotmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 316168a8ca6bc2c9e800717d5e178b3df708cd5e
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Mon Jan 3 16:47:49 2011 -0500
USB: usb-storage: unusual_devs entry for CamSport Evo
commit 12f68c480c7155a66bd2a76ab2fef28dd5f93fa2 upstream.
This patch (as1438) adds an unusual_devs entry for the MagicPixel
FW_Omega2 chip, used in the CamSport Evo camera. The firmware
incorrectly reports a vendor-specific bDeviceClass.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: <ttkspam@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 255639227afcaff09a84ff2fc4cef8019f15c8c1
Author: Richard Schütz <r.schtz@t-online.de>
Date: Wed Dec 22 14:28:56 2010 +0100
USB: usb-storage: unusual_devs update for TrekStor DataStation maxi g.u external hard drive enclosure
commit 7e1e7bd9dbd469267b6e6de1bf8d71a7d65ce86a upstream.
The TrekStor DataStation maxi g.u external hard drive enclosure uses a
JMicron USB to SATA chip which needs the US_FL_IGNORE_RESIDUE flag to work
properly.
Signed-off-by: Richard Schütz <r.schtz@t-online.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 3e1413a0a0c594c6ad5fd3bf05f70ebcc26fb76c
Author: Richard Schütz <r.schtz@t-online.de>
Date: Sun Dec 19 21:18:38 2010 +0100
USB: usb-storage: unusual_devs update for Cypress ATACB
commit cae41118f50ef0c431e13159df6d7dd8bbd54004 upstream.
New device ID added for unusual Cypress ATACB device.
Signed-off-by: Richard Schütz <r.schtz@t-online.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 9a75e86ebe7ffa8980594fca3ab5ce156fbdccb6
Author: Craig Shelley <craig@microtron.org.uk>
Date: Sun Jan 2 21:59:08 2011 +0000
USB: CP210x Removed incorrect device ID
commit 9926c0df7b31b2128eebe92e0e2b052f380ea464 upstream.
Device ID removed 0x10C4/0x8149 for West Mountain Radio Computerized
Battery Analyzer. This device is actually based on a SiLabs C8051Fxxx,
see http://www.etheus.net/SiUSBXp_Linux_Driver for further info.
Signed-off-by: Craig Shelley <craig@microtron.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 97cbe1aec37af4d9c460fad3f80a69528e52ced7
Author: Craig Shelley <craig@microtron.org.uk>
Date: Sun Jan 2 21:51:46 2011 +0000
USB: CP210x Add two device IDs
commit faea63f7ccfddfb8fc19798799fcd38c58415172 upstream.
Device Ids added for IRZ Automation Teleport SG-10 GSM/GPRS Modem and
DekTec DTA Plus VHF/UHF Booster/Attenuator.
Signed-off-by: Craig Shelley <craig@microtron.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 6fe7015007299e14f5ea212a503bcba5958c7086
Author: Libor Pechacek <lpechacek@suse.cz>
Date: Fri Jan 14 14:30:21 2011 +0100
USB: serial: handle Data Carrier Detect changes
commit d14fc1a74e846d7851f24fc9519fe87dc12a1231 upstream.
Alan's commit 335f8514f200e63d689113d29cb7253a5c282967 introduced
.carrier_raised function in several drivers. That also means
tty_port_block_til_ready can now suspend the process trying to open the serial
port when Carrier Detect is low and put it into tty_port.open_wait queue. We
need to wake up the process when Carrier Detect goes high and trigger TTY
hangup when CD goes low.
Some of the devices do not report modem status line changes, or at least we
don't understand the status message, so for those we remove .carrier_raised
again.
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit b858a2d32e8879ae6e662f42c941bf01e86a3b79
Author: Jean Delvare <khali@linux-fr.org>
Date: Wed Jan 12 21:55:09 2011 +0100
hwmon: (via686a) Initialize fan_div values
commit f790674d3f87df6390828ac21a7d1530f71b59c8 upstream.
Functions set_fan_min() and set_fan_div() assume that the fan_div
values have already been read from the register. The driver currently
doesn't initialize them at load time, they are only set when function
via686a_update_device() is called. This means that set_fan_min() and
set_fan_div() misbehave if, for example, "sensors -s" is called
before any monitoring application (e.g. "sensors") is has been run.
Fix the problem by always initializing the fan_div values at device
bind time.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 9380934bbfa7da816aec4c4345f41f9841fde711
Author: Karsten Wiese <fzu@wemgehoertderstaat.de>
Date: Tue Jan 4 01:20:37 2011 +0100
ALSA: snd-usb-us122l: Fix missing NULL checks
commit cdce2db74e156fbd9a2dc3c7b246166f8b70955b upstream.
Fix missing NULL checks in usb_stream_hwdep_poll() and usb_stream_hwdep_ioctl().
Wake up poll waiters before returning from usb_stream_hwdep_ioctl().
Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit a9e2725b9d41dfbd886bb677203c658e5d8fea12
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date: Tue Jan 25 17:42:29 2011 +0800
rt2x00: add device id for windy31 usb device
commit 9c4cf6d94fb362c27a24df5223ed6e327eb7279a upstream.
This patch adds the device id for the windy31 USB device to the rt73usb
driver.
Thanks to Ralf Flaxa for reporting this and providing testing and a
sample device.
Reported-by: Ralf Flaxa <rf@suse.de>
Tested-by: Ralf Flaxa <rf@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit bb671b2cd755014d087c1fbaed9dd11f56019aff
Author: Alex He <alex.he@amd.com>
Date: Tue Dec 7 10:10:08 2010 +0800
USB: EHCI: ASPM quirk of ISOC on AMD SB800
commit 05570297ecbe834b1756b522412b68eaffb9ab11 upstream.
When ASPM PM Feature is enabled on UMI link, devices that use ISOC stream of
data transfer may be exposed to longer latency causing less than optimal per-
formance of the device. The longer latencies are normal and are due to link
wake time coming out of low power state which happens frequently to save
power when the link is not active.
The following code will make exception for certain features of ASPM to be by
passed and keep the logic normal state only when the ISOC device is connected
and active. This change will allow the device to run at optimal performance
yet minimize the impact on overall power savings.
Signed-off-by: Alex He <alex.he@amd.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 9aedc2591445761cfb886234c2af10315e7e2fa0
Author: Márton Németh <nm127@freemail.hu>
Date: Mon Dec 13 21:59:09 2010 +0100
staging: usbip: remove double giveback of URB
commit 7571f089d7522a95c103558faf313c7af8856ceb upstream.
In the vhci_urb_dequeue() function the TCP connection is checked twice.
Each time when the TCP connection is closed the URB is unlinked and given
back. Remove the second attempt of unlinking and giving back of the URB completely.
This patch fixes the bug described at https://bugzilla.kernel.org/show_bug.cgi?id=24872 .
Signed-off-by: Márton Németh <nm127@freemail.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>