--- /dev/null
+From stable-bounces@linux.kernel.org Sat Jan 26 04:57:05 2008
+From: Michael Buesch <mb@bu3sch.de>
+Date: Sat, 26 Jan 2008 13:54:52 +0100
+Subject: b43: Reject new firmware early
+To: stable@kernel.org
+Cc: linux-wireless@vger.kernel.org, Bcm43xx-dev@lists.berlios.de
+Message-ID: <200801261354.52659.mb@bu3sch.de>
+Content-Disposition: inline
+
+From: Michael Buesch <mb@bu3sch.de>
+
+(not in mainline, as it is not applicable.)
+
+We must reject new incompatible firmware early to avoid
+running into strange transmission failures.
+
+The current development tree supports newer firmware revisions.
+These revisions cause strange failures on the stable 2.6.24 kernel.
+Add a check to avoid confusing users a lot.
+
+Signed-off-by: Michael Buesch <mb@bu3sch.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/b43/main.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/net/wireless/b43/main.c
++++ b/drivers/net/wireless/b43/main.c
+@@ -1800,6 +1800,18 @@ static int b43_upload_microcode(struct b
+ err = -EOPNOTSUPP;
+ goto out;
+ }
++ if (fwrev > 351) {
++ b43err(dev->wl, "YOUR FIRMWARE IS TOO NEW. Please downgrade your "
++ "firmware.\n");
++ b43err(dev->wl, "Use this firmware tarball: "
++ "http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2\n");
++ b43err(dev->wl, "Use this b43-fwcutter tarball: "
++ "http://bu3sch.de/b43/fwcutter/b43-fwcutter-009.tar.bz2\n");
++ b43err(dev->wl, "Read, understand and _do_ what this message says, please.\n");
++ b43_write32(dev, B43_MMIO_MACCTL, 0);
++ err = -EOPNOTSUPP;
++ goto out;
++ }
+ b43dbg(dev->wl, "Loading firmware version %u.%u "
+ "(20%.2i-%.2i-%.2i %.2i:%.2i:%.2i)\n",
+ fwrev, fwpatch,
--- /dev/null
+From mingo@elte.hu Sat Feb 2 06:01:49 2008
+From: Nick Piggin <nickpiggin@yahoo.com.au>
+Date: Sat, 2 Feb 2008 15:01:17 +0100
+Subject: fix writev regression: pan hanging unkillable and un-straceable
+To: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>, Nick Piggin <npiggin@suse.de>, "Rafael J. Wysocki" <rjw@sisk.pl>, Greg Kroah-Hartman <gregkh@suse.de>, stable@kernel.org
+Message-ID: <20080202140117.GA4038@elte.hu>
+Content-Disposition: inline
+
+From: Nick Piggin <nickpiggin@yahoo.com.au>
+
+patch 124d3b7041f9a0ca7c43a6293e1cae4576c32fd5 in mainline.
+
+Frederik Himpe reported an unkillable and un-straceable pan process.
+
+Zero length iovecs can go into an infinite loop in writev, because the
+iovec iterator does not always advance over them.
+
+The sequence required to trigger this is not trivial. I think it
+requires that a zero-length iovec be followed by a non-zero-length iovec
+which causes a pagefault in the atomic usercopy. This causes the writev
+code to drop back into single-segment copy mode, which then tries to
+copy the 0 bytes of the zero-length iovec; a zero length copy looks like
+a failure though, so it loops.
+
+Put a test into iov_iter_advance to catch zero-length iovecs. We could
+just put the test in the fallback path, but I feel it is more robust to
+skip over zero-length iovecs throughout the code (iovec iterator may be
+used in filesystems too, so it should be robust).
+
+Signed-off-by: Nick Piggin <npiggin@suse.de>
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ mm/filemap.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/mm/filemap.c
++++ b/mm/filemap.c
+@@ -1733,7 +1733,11 @@ static void __iov_iter_advance_iov(struc
+ const struct iovec *iov = i->iov;
+ size_t base = i->iov_offset;
+
+- while (bytes) {
++ /*
++ * The !iov->iov_len check ensures we skip over unlikely
++ * zero-length segments.
++ */
++ while (bytes || !iov->iov_len) {
+ int copy = min(bytes, iov->iov_len - base);
+
+ bytes -= copy;
+@@ -2251,6 +2255,7 @@ again:
+
+ cond_resched();
+
++ iov_iter_advance(i, copied);
+ if (unlikely(copied == 0)) {
+ /*
+ * If we were unable to copy any data at all, we must
+@@ -2264,7 +2269,6 @@ again:
+ iov_iter_single_seg_count(i));
+ goto again;
+ }
+- iov_iter_advance(i, copied);
+ pos += copied;
+ written += copied;
+
--- /dev/null
+From 296825cbe14d4c95ee9c41ca5824f7487bfb4d9d Mon Sep 17 00:00:00 2001
+From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
+Date: Thu, 31 Jan 2008 22:45:22 +0100
+Subject: sched: fix high wake up latencies with FAIR_USER_SCHED
+
+From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
+
+patch 296825cbe14d4c95ee9c41ca5824f7487bfb4d9d in mainline.
+
+The reason why we are getting better wakeup latencies for
+!FAIR_USER_SCHED is because of this snippet of code in place_entity():
+
+ if (!initial) {
+ /* sleeps upto a single latency don't count. */
+ if (sched_feat(NEW_FAIR_SLEEPERS) && entity_is_task(se))
+ ^^^^^^^^^^^^^^^^^^
+ vruntime -= sysctl_sched_latency;
+
+ /* ensure we never gain time by being placed backwards. */
+ vruntime = max_vruntime(se->vruntime, vruntime);
+ }
+
+NEW_FAIR_SLEEPERS feature gives credit for sleeping only to tasks and
+not group-level entities. With the patch attached, I could see that
+wakeup latencies with FAIR_USER_SCHED are restored to the same level as
+!FAIR_USER_SCHED.
+
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ kernel/sched_fair.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/sched_fair.c
++++ b/kernel/sched_fair.c
+@@ -511,7 +511,7 @@ place_entity(struct cfs_rq *cfs_rq, stru
+
+ if (!initial) {
+ /* sleeps upto a single latency don't count. */
+- if (sched_feat(NEW_FAIR_SLEEPERS) && entity_is_task(se))
++ if (sched_feat(NEW_FAIR_SLEEPERS))
+ vruntime -= sysctl_sched_latency;
+
+ /* ensure we never gain time by being placed backwards. */
--- /dev/null
+From ef9884e6f29bbe1075204f962a00f7533bf7e8f3 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <a.p.zijlstra@chello.nl>
+Date: Thu, 31 Jan 2008 22:45:22 +0100
+Subject: sched: let +nice tasks have smaller impact
+MIME-Version: 1.0
+Content-Type: text/plain; charset=utf-8
+Content-Transfer-Encoding: 8bit
+
+From: Peter Zijlstra <a.p.zijlstra@chello.nl>
+
+patch ef9884e6f29bbe1075204f962a00f7533bf7e8f3 in mainline.
+
+Michel Dänzr has bisected an interactivity problem with
+plus-reniced tasks back to this commit:
+
+ 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
+ commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
+ Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
+ Date: Mon Oct 15 17:00:14 2007 +0200
+
+ sched: another wakeup_granularity fix
+
+ unit mis-match: wakeup_gran was used against a vruntime
+
+fix this by assymetrically scaling the vtime of positive reniced
+tasks.
+
+Bisected-by: Michel Dänzer <michel@tungstengraphics.com>
+Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ kernel/sched_fair.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/kernel/sched_fair.c
++++ b/kernel/sched_fair.c
+@@ -867,7 +867,11 @@ static void check_preempt_wakeup(struct
+ }
+
+ gran = sysctl_sched_wakeup_granularity;
+- if (unlikely(se->load.weight != NICE_0_LOAD))
++ /*
++ * More easily preempt - nice tasks, while not making
++ * it harder for + nice tasks.
++ */
++ if (unlikely(se->load.weight > NICE_0_LOAD))
+ gran = calc_delta_fair(gran, &se->load);
+
+ if (pse->vruntime + gran < se->vruntime)
b43legacy-drop-packets-we-are-not-able-to-encrypt.patch
b43legacy-fix-dma-slot-resource-leakage.patch
selinux-fix-labeling-of-proc-net-inodes.patch
+b43-reject-new-firmware-early.patch
+sched-let-nice-tasks-have-smaller-impact.patch
+sched-fix-high-wake-up-latencies-with-fair_user_sched.patch
+fix-writev-regression-pan-hanging-unkillable-and-un-straceable.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
