* [072/474] mm, x86: Saving vmcore with non-lazy freeing of vmas
2011-03-17 21:38 [000/474] 2.6.33.8-longterm review Greg KH
@ 2011-03-17 21:22 ` Greg KH
2011-03-17 21:22 ` [078/474] x86, kdump: Change copy_oldmem_page() to use cached addressing Greg KH
` (7 subsequent siblings)
8 siblings, 0 replies; 16+ messages in thread
From: Greg KH @ 2011-03-17 21:22 UTC (permalink / raw)
To: stable-review; +Cc: Andrew Morton, Ingo Molnar, kexec, Cliff Wickman
2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
Content-Length: 2026
Lines: 68
From: Cliff Wickman <cpw@sgi.com>
commit 3ee48b6af49cf534ca2f481ecc484b156a41451d upstream.
During the reading of /proc/vmcore the kernel is doing
ioremap()/iounmap() repeatedly. And the buildup of un-flushed
vm_area_struct's is causing a great deal of overhead. (rb_next()
is chewing up most of that time).
This solution is to provide function set_iounmap_nonlazy(). It
causes a subsequent call to iounmap() to immediately purge the
vma area (with try_purge_vmap_area_lazy()).
With this patch we have seen the time for writing a 250MB
compressed dump drop from 71 seconds to 44 seconds.
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: kexec@lists.infradead.org
LKML-Reference: <E1OwHZ4-0005WK-Tw@eag09.americas.sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/x86/include/asm/io.h | 1 +
arch/x86/kernel/crash_dump_64.c | 1 +
mm/vmalloc.c | 9 +++++++++
3 files changed, 11 insertions(+)
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -172,6 +172,7 @@ static inline void __iomem *ioremap(reso
extern void iounmap(volatile void __iomem *addr);
+extern void set_iounmap_nonlazy(void);
#ifdef CONFIG_X86_32
# include "io_32.h"
--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
@@ -46,6 +46,7 @@ ssize_t copy_oldmem_page(unsigned long p
} else
memcpy(buf, vaddr + offset, csize);
+ set_iounmap_nonlazy();
iounmap(vaddr);
return csize;
}
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -513,6 +513,15 @@ static atomic_t vmap_lazy_nr = ATOMIC_IN
static void purge_fragmented_blocks_allcpus(void);
/*
+ * called before a call to iounmap() if the caller wants vm_area_struct's
+ * immediately freed.
+ */
+void set_iounmap_nonlazy(void)
+{
+ atomic_set(&vmap_lazy_nr, lazy_max_pages()+1);
+}
+
+/*
* Purges all lazily-freed vmap areas.
*
* If sync is 0 then don't purge if there is already a purge in progress.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 16+ messages in thread
* [078/474] x86, kdump: Change copy_oldmem_page() to use cached addressing
2011-03-17 21:38 [000/474] 2.6.33.8-longterm review Greg KH
2011-03-17 21:22 ` [072/474] mm, x86: Saving vmcore with non-lazy freeing of vmas Greg KH
@ 2011-03-17 21:22 ` Greg KH
2011-03-17 21:24 ` [213/474] x86, hotplug: Use mwait to offline a processor, fix the legacy case Greg KH
` (6 subsequent siblings)
8 siblings, 0 replies; 16+ messages in thread
From: Greg KH @ 2011-03-17 21:22 UTC (permalink / raw)
To: stable-review; +Cc: Ingo Molnar, kexec, Cliff Wickman, Eric W. Biederman
2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
Content-Length: 1077
Lines: 35
From: Cliff Wickman <cpw@sgi.com>
commit 37a2f9f30a360fb03522d15c85c78265ccd80287 upstream.
The copy of /proc/vmcore to a user buffer proceeds much faster
if the kernel addresses memory as cached.
With this patch we have seen an increase in transfer rate from
less than 15MB/s to 80-460MB/s, depending on size of the
transfer. This makes a big difference in time needed to save a
system dump.
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: kexec@lists.infradead.org
LKML-Reference: <E1OtMLz-0001yp-Ia@eag09.americas.sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/x86/kernel/crash_dump_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
@@ -34,7 +34,7 @@ ssize_t copy_oldmem_page(unsigned long p
if (!csize)
return 0;
- vaddr = ioremap(pfn << PAGE_SHIFT, PAGE_SIZE);
+ vaddr = ioremap_cache(pfn << PAGE_SHIFT, PAGE_SIZE);
if (!vaddr)
return -ENOMEM;
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 16+ messages in thread
* [213/474] x86, hotplug: Use mwait to offline a processor, fix the legacy case
2011-03-17 21:38 [000/474] 2.6.33.8-longterm review Greg KH
2011-03-17 21:22 ` [072/474] mm, x86: Saving vmcore with non-lazy freeing of vmas Greg KH
2011-03-17 21:22 ` [078/474] x86, kdump: Change copy_oldmem_page() to use cached addressing Greg KH
@ 2011-03-17 21:24 ` Greg KH
2011-03-17 21:27 ` [421/474] powerpc/kexec: Fix orphaned offline CPUs across kexec Greg KH
` (5 subsequent siblings)
8 siblings, 0 replies; 16+ messages in thread
From: Greg KH @ 2011-03-17 21:24 UTC (permalink / raw)
To: stable-review, stable; +Cc: Len Brown, linux-pm, x86, H. Peter Anvin
2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
Content-Length: 4240
Lines: 156
From: H. Peter Anvin <hpa@linux.intel.com>
upstream ea53069231f9317062910d6e772cca4ce93de8c8
x86, hotplug: Use mwait to offline a processor, fix the legacy case
Here included also some small follow-on patches to the same code:
upstream a68e5c94f7d3dd64fef34dd5d97e365cae4bb42a
x86, hotplug: Move WBINVD back outside the play_dead loop
upstream ce5f68246bf2385d6174856708d0b746dc378f20
x86, hotplug: In the MWAIT case of play_dead, CLFLUSH the cache line
https://bugzilla.kernel.org/show_bug.cgi?id=5471
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/x86/include/asm/processor.h | 23 ----------
arch/x86/kernel/smpboot.c | 85 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 84 insertions(+), 24 deletions(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -767,29 +767,6 @@ extern unsigned long boot_option_idle_o
extern unsigned long idle_halt;
extern unsigned long idle_nomwait;
-/*
- * on systems with caches, caches must be flashed as the absolute
- * last instruction before going into a suspended halt. Otherwise,
- * dirty data can linger in the cache and become stale on resume,
- * leading to strange errors.
- *
- * perform a variety of operations to guarantee that the compiler
- * will not reorder instructions. wbinvd itself is serializing
- * so the processor will not reorder.
- *
- * Systems without cache can just go into halt.
- */
-static inline void wbinvd_halt(void)
-{
- mb();
- /* check for clflush to determine if wbinvd is legal */
- if (cpu_has_clflush)
- asm volatile("cli; wbinvd; 1: hlt; jmp 1b" : : : "memory");
- else
- while (1)
- halt();
-}
-
extern void enable_sep_cpu(void);
extern int sysenter_setup(void);
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1329,11 +1329,94 @@ void play_dead_common(void)
local_irq_disable();
}
+#define MWAIT_SUBSTATE_MASK 0xf
+#define MWAIT_SUBSTATE_SIZE 4
+
+#define CPUID_MWAIT_LEAF 5
+#define CPUID5_ECX_EXTENSIONS_SUPPORTED 0x1
+
+/*
+ * We need to flush the caches before going to sleep, lest we have
+ * dirty data in our caches when we come back up.
+ */
+static inline void mwait_play_dead(void)
+{
+ unsigned int eax, ebx, ecx, edx;
+ unsigned int highest_cstate = 0;
+ unsigned int highest_subcstate = 0;
+ int i;
+ void *mwait_ptr;
+
+ if (!cpu_has(¤t_cpu_data, X86_FEATURE_MWAIT))
+ return;
+ if (!cpu_has(¤t_cpu_data, X86_FEATURE_CLFLSH))
+ return;
+ if (current_cpu_data.cpuid_level < CPUID_MWAIT_LEAF)
+ return;
+
+ eax = CPUID_MWAIT_LEAF;
+ ecx = 0;
+ native_cpuid(&eax, &ebx, &ecx, &edx);
+
+ /*
+ * eax will be 0 if EDX enumeration is not valid.
+ * Initialized below to cstate, sub_cstate value when EDX is valid.
+ */
+ if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED)) {
+ eax = 0;
+ } else {
+ edx >>= MWAIT_SUBSTATE_SIZE;
+ for (i = 0; i < 7 && edx; i++, edx >>= MWAIT_SUBSTATE_SIZE) {
+ if (edx & MWAIT_SUBSTATE_MASK) {
+ highest_cstate = i;
+ highest_subcstate = edx & MWAIT_SUBSTATE_MASK;
+ }
+ }
+ eax = (highest_cstate << MWAIT_SUBSTATE_SIZE) |
+ (highest_subcstate - 1);
+ }
+
+ /*
+ * This should be a memory location in a cache line which is
+ * unlikely to be touched by other processors. The actual
+ * content is immaterial as it is not actually modified in any way.
+ */
+ mwait_ptr = ¤t_thread_info()->flags;
+
+ wbinvd();
+
+ while (1) {
+ /*
+ * The CLFLUSH is a workaround for erratum AAI65 for
+ * the Xeon 7400 series. It's not clear it is actually
+ * needed, but it should be harmless in either case.
+ * The WBINVD is insufficient due to the spurious-wakeup
+ * case where we return around the loop.
+ */
+ clflush(mwait_ptr);
+ __monitor(mwait_ptr, 0, 0);
+ mb();
+ __mwait(eax, 0);
+ }
+}
+
+static inline void hlt_play_dead(void)
+{
+ if (current_cpu_data.x86 >= 4)
+ wbinvd();
+
+ while (1) {
+ native_halt();
+ }
+}
+
void native_play_dead(void)
{
play_dead_common();
tboot_shutdown(TB_SHUTDOWN_WFS);
- wbinvd_halt();
+
+ mwait_play_dead(); /* Only returns on failure */
+ hlt_play_dead();
}
#else /* ... !CONFIG_HOTPLUG_CPU */
^ permalink raw reply [flat|nested] 16+ messages in thread
* [421/474] powerpc/kexec: Fix orphaned offline CPUs across kexec
2011-03-17 21:38 [000/474] 2.6.33.8-longterm review Greg KH
` (2 preceding siblings ...)
2011-03-17 21:24 ` [213/474] x86, hotplug: Use mwait to offline a processor, fix the legacy case Greg KH
@ 2011-03-17 21:27 ` Greg KH
2011-03-17 21:28 ` [430/474] MIPS: MTX-1: Make au1000_eth probe all PHY addresses Greg KH
` (4 subsequent siblings)
8 siblings, 0 replies; 16+ messages in thread
From: Greg KH @ 2011-03-17 21:27 UTC (permalink / raw)
To: stable-review, stable
Cc: greg, benh, linux-kernel, anton, Matt Evans, Kamalesh babulal
2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
Content-Length: 2566
Lines: 74
From: Matt Evans <matt@ozlabs.org>
Commit: e8e5c2155b0035b6e04f29be67f6444bc914005b upstream
When CPU hotplug is used, some CPUs may be offline at the time a kexec is
performed. The subsequent kernel may expect these CPUs to be already running,
and will declare them stuck. On pseries, there's also a soft-offline (cede)
state that CPUs may be in; this can also cause problems as the kexeced kernel
may ask RTAS if they're online -- and RTAS would say they are. The CPU will
either appear stuck, or will cause a crash as we replace its cede loop beneath
it.
This patch kicks each present offline CPU awake before the kexec, so that
none are forever lost to these assumptions in the subsequent kernel.
Now, the behaviour is that all available CPUs that were offlined are now
online & usable after the kexec. This mimics the behaviour of a full reboot
(on which all CPUs will be restarted).
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Kamalesh babulal <kamalesh@linux.vnet.ibm.com>
cc: Anton Blanchard <anton@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/powerpc/kernel/machine_kexec_64.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -15,6 +15,7 @@
#include <linux/thread_info.h>
#include <linux/init_task.h>
#include <linux/errno.h>
+#include <linux/cpu.h>
#include <asm/page.h>
#include <asm/current.h>
@@ -169,10 +170,34 @@ static void kexec_smp_down(void *arg)
/* NOTREACHED */
}
+/*
+ * We need to make sure each present CPU is online. The next kernel will scan
+ * the device tree and assume primary threads are online and query secondary
+ * threads via RTAS to online them if required. If we don't online primary
+ * threads, they will be stuck. However, we also online secondary threads as we
+ * may be using 'cede offline'. In this case RTAS doesn't see the secondary
+ * threads as offline -- and again, these CPUs will be stuck.
+ *
+ * So, we online all CPUs that should be running, including secondary threads.
+ */
+static void wake_offline_cpus(void)
+{
+ int cpu = 0;
+
+ for_each_present_cpu(cpu) {
+ if (!cpu_online(cpu)) {
+ printk(KERN_INFO "kexec: Waking offline cpu %d.\n",
+ cpu);
+ cpu_up(cpu);
+ }
+ }
+}
+
static void kexec_prepare_cpus(void)
{
int my_cpu, i, notified=-1;
+ wake_offline_cpus();
smp_call_function(kexec_smp_down, NULL, /* wait */0);
my_cpu = get_cpu();
^ permalink raw reply [flat|nested] 16+ messages in thread
* [430/474] MIPS: MTX-1: Make au1000_eth probe all PHY addresses
2011-03-17 21:38 [000/474] 2.6.33.8-longterm review Greg KH
` (3 preceding siblings ...)
2011-03-17 21:27 ` [421/474] powerpc/kexec: Fix orphaned offline CPUs across kexec Greg KH
@ 2011-03-17 21:28 ` Greg KH
2011-03-18 5:26 ` [000/474] 2.6.33.8-longterm review Mike Galbraith
` (3 subsequent siblings)
8 siblings, 0 replies; 16+ messages in thread
From: Greg KH @ 2011-03-17 21:28 UTC (permalink / raw)
To: stable-review, linux-mips; +Cc: Florian Fainelli, Ralf Baechle
2.6.33-longterm review patch. If anyone has any objections, please let us know.
------------------
Content-Length: 1478
Lines: 50
From: Florian Fainelli <florian@openwrt.org>
commit bf3a1eb85967dcbaae42f4fcb53c2392cec32677 upstream.
When au1000_eth probes the MII bus for PHY address, if we do not set
au1000_eth platform data's phy_search_highest_address, the MII probing
logic will exit early and will assume a valid PHY is found at address 0.
For MTX-1, the PHY is at address 31, and without this patch, the link
detection/speed/duplex would not work correctly.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
To: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/2111/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/mips/alchemy/mtx-1/platform.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/arch/mips/alchemy/mtx-1/platform.c
+++ b/arch/mips/alchemy/mtx-1/platform.c
@@ -28,6 +28,8 @@
#include <linux/mtd/physmap.h>
#include <mtd/mtd-abi.h>
+#include <asm/mach-au1x00/au1xxx_eth.h>
+
static struct gpio_keys_button mtx1_gpio_button[] = {
{
.gpio = 207,
@@ -140,10 +142,17 @@ static struct __initdata platform_device
&mtx1_mtd,
};
+static struct au1000_eth_platform_data mtx1_au1000_eth0_pdata = {
+ .phy_search_highest_addr = 1,
+ .phy1_search_mac0 = 1,
+};
+
static int __init mtx1_register_devices(void)
{
int rc;
+ au1xxx_override_eth_cfg(0, &mtx1_au1000_eth0_pdata);
+
rc = gpio_request(mtx1_gpio_button[0].gpio,
mtx1_gpio_button[0].desc);
if (rc < 0) {
^ permalink raw reply [flat|nested] 16+ messages in thread
* [000/474] 2.6.33.8-longterm review
@ 2011-03-17 21:38 Greg KH
2011-03-17 21:22 ` [072/474] mm, x86: Saving vmcore with non-lazy freeing of vmas Greg KH
` (8 more replies)
0 siblings, 9 replies; 16+ messages in thread
From: Greg KH @ 2011-03-17 21:38 UTC (permalink / raw)
To: linux-kernel, stable, stable-review; +Cc: torvalds, akpm, mgalbraith, tglx
Yeah, I know what you are thinking, "What, 2.6.33, are you crazy?"
I'd prefer it if you didn't answer that question...
Anyway, yes, a .33 kernel release, strange isn't it.
Turns out there are a lot of people "stuck" on the 2.6.33 kernel series
for a variety of valid reasons, not the least being the Real Time
patchset. So, in the copious spare time I have, I've been trying to
keep up with the patches that have been applied to the different
longterm and stable kernel trees and have been queueing them up for .33
as well.
Here's the result of that. A 474 patch series that is bigger than most
people ever want to review, or see in their inboxes. Because of that,
it is ONLY being sent to the stable-review@kernel.org mailing list. If
you want to see the individual patches, look at the git tree of the
patch queue, or look at that mailing list.
So, if you are using .33, please give this patch a test and let me know
if I've messed up anything (hint, I think I did, it's up to you to
figure it out, consider it a test to see if anyone actually cares about
this kernel version.)
If I missed anything that I should have in here, please let me know.
Responses should be made by Saturday, March 19, 2011, 21:00:00 UTC.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.33.8-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
MAINTAINERS | 6 +
Makefile | 2 +-
arch/arm/include/asm/assembler.h | 2 +-
arch/arm/kernel/signal.c | 4 +-
arch/arm/lib/findbit.S | 6 +-
arch/ia64/include/asm/compat.h | 2 +-
arch/ia64/kernel/fsys.S | 30 +++-
arch/mips/alchemy/mtx-1/platform.c | 9 +
arch/mips/include/asm/compat.h | 2 +-
arch/parisc/include/asm/compat.h | 2 +-
arch/powerpc/include/asm/compat.h | 2 +-
arch/powerpc/include/asm/hvcall.h | 1 +
arch/powerpc/kernel/cpu_setup_6xx.S | 40 +++---
arch/powerpc/kernel/crash.c | 11 +-
arch/powerpc/kernel/machine_kexec_64.c | 25 +++
arch/powerpc/kernel/ppc970-pmu.c | 2 +
arch/powerpc/kernel/setup_64.c | 17 ++-
arch/powerpc/platforms/pseries/hvCall.S | 38 +++++
arch/powerpc/platforms/pseries/lpar.c | 70 +++++++--
arch/powerpc/platforms/pseries/plpar_wrappers.h | 18 ++
arch/powerpc/sysdev/fsl_rio.c | 1 -
arch/s390/include/asm/compat.h | 2 +-
arch/s390/include/asm/processor.h | 5 -
arch/s390/include/asm/vdso.h | 2 +-
arch/s390/kernel/traps.c | 37 ----
arch/s390/kernel/vtime.c | 19 ++
arch/sparc/include/asm/compat.h | 2 +-
arch/um/drivers/ubd_kern.c | 9 +-
arch/um/kernel/uml.lds.S | 2 +-
arch/um/os-Linux/time.c | 2 +-
arch/x86/ia32/ia32entry.S | 22 ++-
arch/x86/include/asm/acpi.h | 1 +
arch/x86/include/asm/amd_iommu_proto.h | 6 +
arch/x86/include/asm/amd_iommu_types.h | 12 ++
arch/x86/include/asm/compat.h | 2 +-
arch/x86/include/asm/cpufeature.h | 2 +-
arch/x86/include/asm/io.h | 1 +
arch/x86/include/asm/mmu_context.h | 5 +-
arch/x86/include/asm/pgtable_32.h | 1 +
arch/x86/include/asm/processor.h | 23 ---
arch/x86/include/asm/pvclock.h | 1 +
arch/x86/include/asm/smp.h | 9 +-
arch/x86/include/asm/smpboot_hooks.h | 2 +-
arch/x86/include/asm/trampoline.h | 5 +-
arch/x86/kernel/Makefile | 2 +
arch/x86/kernel/acpi/boot.c | 14 +-
arch/x86/kernel/amd_iommu.c | 4 +-
arch/x86/kernel/amd_iommu_init.c | 67 +++++---
arch/x86/kernel/apic/apic.c | 8 +
arch/x86/kernel/apic/io_apic.c | 14 ++-
arch/x86/kernel/apic/probe_64.c | 7 -
arch/x86/kernel/cpu/amd.c | 3 +-
arch/x86/kernel/cpu/common.c | 4 +-
arch/x86/kernel/cpu/cpu.h | 1 +
arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c | 1 +
arch/x86/kernel/cpu/intel.c | 1 +
arch/x86/kernel/cpu/mcheck/mce_amd.c | 9 +-
arch/x86/kernel/cpu/mtrr/cleanup.c | 2 +-
arch/x86/kernel/cpu/mtrr/main.c | 10 +-
arch/x86/kernel/crash_dump_64.c | 3 +-
arch/x86/kernel/e820.c | 10 +-
arch/x86/kernel/early-quirks.c | 21 ++-
arch/x86/kernel/head_32.S | 8 +-
arch/x86/kernel/hpet.c | 2 +-
arch/x86/kernel/hw_breakpoint.c | 4 +
arch/x86/kernel/olpc.c | 5 +-
arch/x86/kernel/pvclock.c | 5 +
arch/x86/kernel/reboot.c | 2 +-
arch/x86/kernel/setup.c | 2 +
arch/x86/kernel/smp.c | 15 +-
arch/x86/kernel/smpboot.c | 117 +++++++++++---
arch/x86/kernel/trampoline.c | 17 ++
arch/x86/kvm/x86.c | 2 +-
arch/x86/mm/fault.c | 7 +
arch/x86/mm/srat_64.c | 8 +-
arch/x86/vdso/Makefile | 4 +-
arch/x86/xen/enlighten.c | 4 -
arch/x86/xen/smp.c | 6 +-
arch/x86/xen/time.c | 2 +
block/blk-map.c | 2 +
block/blk-settings.c | 2 +-
block/bsg.c | 2 +-
block/cfq-iosched.c | 4 +
block/scsi_ioctl.c | 34 +++-
drivers/acpi/acpica/aclocal.h | 1 +
drivers/acpi/acpica/dswexec.c | 19 ++-
drivers/acpi/blacklist.c | 16 ++
drivers/acpi/ec.c | 3 +
drivers/ata/ahci.c | 5 +
drivers/ata/libata-core.c | 24 ++-
drivers/ata/libata-scsi.c | 5 +-
drivers/ata/pata_mpc52xx.c | 2 +-
drivers/block/pktcdvd.c | 2 +-
drivers/bluetooth/hci_ldisc.c | 7 +
drivers/char/hpet.c | 17 ++
drivers/char/hvc_iucv.c | 6 +-
drivers/char/mem.c | 3 +-
drivers/char/pcmcia/synclink_cs.c | 2 +
drivers/char/tpm/tpm.c | 28 +++-
drivers/char/tpm/tpm.h | 2 +
drivers/char/tpm/tpm_tis.c | 28 +++-
drivers/char/tty_buffer.c | 14 ++-
drivers/char/tty_ldisc.c | 51 +++++-
drivers/char/vt_ioctl.c | 11 +-
drivers/crypto/padlock-aes.c | 2 +-
drivers/dma/mv_xor.c | 4 +-
drivers/edac/amd64_edac.c | 2 +-
drivers/firewire/core-card.c | 11 +-
drivers/firewire/ohci.c | 64 ++++++--
drivers/gpu/drm/Kconfig | 3 +
drivers/gpu/drm/drm_crtc.c | 10 +-
drivers/gpu/drm/drm_irq.c | 3 +-
drivers/gpu/drm/i915/intel_lvds.c | 8 +
drivers/gpu/drm/radeon/atombios_dp.c | 4 +-
drivers/gpu/drm/radeon/radeon_atombios.c | 16 ++-
drivers/gpu/drm/radeon/radeon_display.c | 6 +-
drivers/gpu/drm/ttm/ttm_bo.c | 84 ++++++++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
drivers/hwmon/adm1026.c | 20 +-
drivers/hwmon/f71882fg.c | 2 +-
drivers/hwmon/lm85.c | 1 +
drivers/hwmon/via686a.c | 14 ++-
drivers/i2c/i2c-core.c | 14 ++-
drivers/infiniband/core/cm.c | 1 +
drivers/infiniband/core/cma.c | 15 ++
drivers/infiniband/core/uverbs_cmd.c | 101 +++++++-----
drivers/infiniband/hw/cxgb3/iwch_cm.c | 6 +-
drivers/input/joydev.c | 3 +
drivers/input/mouse/bcm5974.c | 40 +++++
drivers/isdn/hisax/config.c | 18 ++-
drivers/isdn/hisax/hisax.h | 1 +
drivers/leds/leds-ss4200.c | 1 +
drivers/md/dm-mpath.c | 12 --
drivers/md/dm.c | 5 +-
drivers/md/md.c | 19 ++-
drivers/md/raid1.c | 1 +
drivers/media/dvb/dvb-usb/dib0700_devices.c | 21 ++-
drivers/media/dvb/frontends/dib7000m.c | 19 ++
drivers/media/dvb/frontends/dib7000m.h | 15 ++
drivers/media/dvb/ttpci/av7110_ca.c | 2 +-
drivers/media/radio/radio-aimslab.c | 24 +--
drivers/media/video/cx231xx/cx231xx-cards.c | 14 +-
drivers/media/video/em28xx/em28xx-cards.c | 4 +-
drivers/media/video/ivtv/ivtvfb.c | 2 +
drivers/media/video/v4l2-compat-ioctl32.c | 32 +++--
drivers/message/fusion/mptctl.c | 8 +
drivers/message/fusion/mptscsih.c | 9 +-
drivers/mfd/ucb1x00-ts.c | 12 +-
drivers/misc/sgi-xp/xpc_partition.c | 25 ++-
drivers/misc/sgi-xp/xpc_uv.c | 17 ++
drivers/mmc/host/sdhci-s3c.c | 6 +-
drivers/mtd/chips/jedec_probe.c | 32 ++--
drivers/mtd/nand/omap2.c | 2 +-
drivers/mtd/onenand/generic.c | 2 +-
drivers/mtd/onenand/omap2.c | 2 +-
drivers/net/atlx/atl1.c | 5 +-
drivers/net/b44.c | 4 +-
drivers/net/benet/be.h | 2 +
drivers/net/benet/be_main.c | 18 +-
drivers/net/bnx2.c | 20 ++-
drivers/net/e1000e/netdev.c | 3 +-
drivers/net/igb/igb_main.c | 2 +-
drivers/net/ixgbe/ixgbe_main.c | 5 +
drivers/net/netxen/netxen_nic_init.c | 3 -
drivers/net/r6040.c | 12 +-
drivers/net/r8169.c | 12 +-
drivers/net/wireless/ath/ath9k/hw.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 15 ++-
drivers/net/wireless/iwlwifi/iwl-helpers.h | 6 +
drivers/net/wireless/orinoco/main.c | 6 +
drivers/net/wireless/orinoco/wext.c | 4 +-
drivers/net/wireless/p54/eeprom.c | 4 +-
drivers/net/wireless/p54/p54pci.c | 14 +-
drivers/net/wireless/p54/p54usb.c | 22 +++-
drivers/net/wireless/p54/txrx.c | 2 +-
drivers/net/wireless/rt2x00/rt73usb.c | 1 +
drivers/pci/dmar.c | 5 +
drivers/pci/pci-stub.c | 3 +
drivers/pci/pci-sysfs.c | 22 ++-
drivers/pci/pci.h | 7 +-
drivers/pci/proc.c | 2 +-
drivers/pci/quirks.c | 43 +++++
drivers/platform/x86/acer-wmi.c | 4 +-
drivers/platform/x86/asus_acpi.c | 8 +-
drivers/platform/x86/tc1100-wmi.c | 2 +-
drivers/platform/x86/wmi.c | 2 +-
drivers/power/ds2760_battery.c | 2 +-
drivers/power/olpc_battery.c | 8 +-
drivers/rtc/rtc-cmos.c | 16 +-
drivers/s390/char/keyboard.c | 3 +-
drivers/s390/cio/qdio.h | 6 +
drivers/s390/cio/qdio_main.c | 43 +++--
drivers/scsi/bfa/bfa_core.c | 22 +++
drivers/scsi/device_handler/scsi_dh_alua.c | 2 +
drivers/scsi/gdth.c | 8 +
drivers/scsi/libsas/sas_ata.c | 1 +
drivers/scsi/libsas/sas_scsi_host.c | 1 +
drivers/scsi/mpt2sas/mpt2sas_base.c | 24 ++-
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 4 +-
drivers/scsi/scsi_lib.c | 3 +-
drivers/scsi/scsi_sysfs.c | 3 +-
drivers/scsi/sd.c | 24 ++-
drivers/serial/8250.c | 3 +-
drivers/ssb/b43_pci_bridge.c | 1 +
drivers/ssb/driver_chipcommon_pmu.c | 17 +-
drivers/ssb/pci.c | 20 +--
drivers/ssb/pcmcia.c | 2 +-
drivers/staging/asus_oled/asus_oled.c | 8 +-
drivers/staging/comedi/drivers/jr3_pci.c | 7 +
drivers/staging/comedi/drivers/ni_labpc.c | 3 +-
drivers/staging/frontier/tranzport.c | 2 +-
drivers/staging/hv/blkvsc_drv.c | 1 +
drivers/staging/hv/netvsc_drv.c | 1 +
drivers/staging/line6/control.c | 204 +++++++++++-----------
drivers/staging/line6/midi.c | 4 +-
drivers/staging/line6/pod.c | 32 ++--
drivers/staging/line6/toneport.c | 4 +-
drivers/staging/line6/variax.c | 12 +-
drivers/staging/rt2860/chips/rt3090.c | 3 +-
drivers/staging/rt2860/chips/rt30xx.c | 4 +-
drivers/staging/rt2860/rt_main_dev.c | 2 -
drivers/staging/rt2860/usb_main_dev.c | 1 +
drivers/staging/rtl8187se/r8185b_init.c | 30 +++-
drivers/staging/samsung-laptop/samsung-laptop.c | 2 +-
drivers/staging/usbip/usbip_event.c | 16 +--
drivers/staging/usbip/vhci.h | 6 +-
drivers/staging/usbip/vhci_hcd.c | 70 ++++++---
drivers/staging/usbip/vhci_rx.c | 15 +-
drivers/usb/atm/ueagle-atm.c | 6 +-
drivers/usb/core/devio.c | 7 +-
drivers/usb/core/file.c | 35 ++--
drivers/usb/core/hub.c | 35 ++++-
drivers/usb/core/message.c | 15 +-
drivers/usb/core/quirks.c | 8 +
drivers/usb/gadget/atmel_usba_udc.c | 3 +
drivers/usb/gadget/printer.c | 14 +-
drivers/usb/host/ehci-hcd.c | 29 ++--
drivers/usb/host/isp1760-hcd.c | 22 ++-
drivers/usb/host/isp1760-hcd.h | 1 +
drivers/usb/host/xhci-ring.c | 50 ++++--
drivers/usb/misc/cypress_cy7c63.c | 6 +-
drivers/usb/misc/iowarrior.c | 3 +-
drivers/usb/misc/sisusbvga/sisusb.c | 1 +
drivers/usb/misc/trancevibrator.c | 2 +-
drivers/usb/misc/usbled.c | 2 +-
drivers/usb/misc/usbsevseg.c | 10 +-
drivers/usb/misc/uss720.c | 4 +-
drivers/usb/musb/blackfin.c | 4 +-
drivers/usb/musb/omap2430.c | 1 +
drivers/usb/serial/ch341.c | 11 ++
drivers/usb/serial/cp210x.c | 18 +--
drivers/usb/serial/digi_acceleport.c | 10 -
drivers/usb/serial/ftdi_sio.c | 76 ++++++++-
drivers/usb/serial/ftdi_sio_ids.h | 64 +++++++-
drivers/usb/serial/generic.c | 20 +++
drivers/usb/serial/io_edgeport.c | 4 +-
drivers/usb/serial/keyspan_pda.c | 17 --
drivers/usb/serial/kobil_sct.c | 2 +-
drivers/usb/serial/opticon.c | 6 +-
drivers/usb/serial/option.c | 25 +++-
drivers/usb/serial/pl2303.c | 13 ++
drivers/usb/serial/pl2303.h | 2 +
drivers/usb/serial/sierra.c | 3 +
drivers/usb/serial/spcp8x5.c | 6 +-
drivers/usb/serial/ti_usb_3410_5052.c | 2 +-
drivers/usb/serial/visor.c | 12 ++
drivers/usb/storage/sierra_ms.c | 2 +-
drivers/usb/storage/unusual_cypress.h | 5 +
drivers/usb/storage/unusual_devs.h | 39 +++++
drivers/video/backlight/backlight.c | 12 +-
drivers/video/efifb.c | 61 ++++++--
drivers/video/sis/sis_main.c | 3 +
drivers/video/via/accel.c | 7 +-
drivers/video/via/ioctl.c | 2 +
drivers/virtio/virtio_pci.c | 21 +--
drivers/xen/events.c | 2 +-
fs/aio.c | 3 +
fs/bio.c | 23 +++-
fs/btrfs/super.c | 5 +-
fs/char_dev.c | 4 +-
fs/cifs/cifsproto.h | 2 +-
fs/cifs/cifssmb.c | 4 +-
fs/cifs/file.c | 17 +-
fs/ecryptfs/inode.c | 6 +
fs/eventpoll.c | 95 +++++++++++
fs/exec.c | 19 ++
fs/ext2/namei.c | 9 +-
fs/ext4/balloc.c | 3 -
fs/ext4/ext4.h | 2 +
fs/ext4/extents.c | 9 +-
fs/ext4/mballoc.h | 2 -
fs/file_table.c | 2 +-
fs/fuse/file.c | 134 ++++++++++++++--
fs/fuse/fuse_i.h | 6 +-
fs/nfs/direct.c | 34 +++--
fs/nfs/file.c | 4 +-
fs/nfs/mount_clnt.c | 4 +-
fs/nfsd/nfs3xdr.c | 6 +-
fs/nfsd/nfs4xdr.c | 12 +-
fs/nfsd/vfs.c | 2 +-
fs/nfsd/xdr4.h | 21 +--
fs/notify/inotify/inotify_user.c | 7 +-
fs/ocfs2/refcounttree.c | 7 +-
fs/ocfs2/stack_user.c | 2 +-
fs/ocfs2/symlink.c | 2 +-
fs/partitions/ldm.c | 5 +
fs/partitions/mac.c | 17 +-
fs/pipe.c | 2 +-
fs/proc/array.c | 5 +-
fs/proc/task_mmu.c | 8 +-
fs/reiserfs/ioctl.c | 7 +-
fs/reiserfs/xattr_acl.c | 6 +-
fs/xfs/linux-2.6/xfs_ioctl.c | 2 +
include/drm/drmP.h | 2 +-
include/drm/drm_pciids.h | 3 +-
include/drm/ttm/ttm_bo_api.h | 4 +-
include/keys/rxrpc-type.h | 1 -
include/linux/blkdev.h | 4 +-
include/linux/compat.h | 2 +
include/linux/cred.h | 21 +---
include/linux/ftrace.h | 2 +
include/linux/ieee80211.h | 2 +-
include/linux/klist.h | 2 +-
include/linux/mmzone.h | 13 ++
include/linux/netdevice.h | 4 +
include/linux/pci_ids.h | 4 +
include/linux/ssb/ssb.h | 5 +-
include/linux/ssb/ssb_driver_chipcommon.h | 15 ++-
include/linux/usb/serial.h | 3 +
include/linux/vmstat.h | 22 +++
include/net/sctp/sm.h | 1 +
include/net/sctp/structs.h | 3 +
include/net/sock.h | 1 +
include/net/udp.h | 1 +
include/net/x25.h | 4 +
init/calibrate.c | 6 +-
ipc/compat.c | 6 +
ipc/compat_mq.c | 5 +
ipc/sem.c | 2 +
ipc/shm.c | 1 +
kernel/compat.c | 21 +++
kernel/cpuset.c | 7 +-
kernel/cred.c | 41 ++++-
kernel/exit.c | 22 ++-
kernel/futex.c | 31 ++--
kernel/hrtimer.c | 13 ++-
kernel/hw_breakpoint.c | 3 +-
kernel/irq/manage.c | 2 +-
kernel/irq/proc.c | 2 +-
kernel/latencytop.c | 17 +-
kernel/power/snapshot.c | 7 +-
kernel/power/user.c | 2 +-
kernel/printk.c | 2 +
kernel/ptrace.c | 2 +-
kernel/sched.c | 17 +-
kernel/signal.c | 43 ++++--
kernel/smp.c | 30 ++++
kernel/sys.c | 2 +
kernel/time/tick-broadcast.c | 10 +
kernel/time/tick-common.c | 6 +-
kernel/time/tick-internal.h | 3 +
kernel/timer.c | 6 +
kernel/trace/ftrace.c | 52 +++++-
kernel/trace/ring_buffer.c | 2 +-
kernel/trace/trace.c | 10 +-
lib/percpu_counter.c | 1 +
mm/filemap.c | 3 +
mm/internal.h | 2 +-
mm/memory.c | 32 +++-
mm/memory_hotplug.c | 2 +-
mm/mempolicy.c | 2 +-
mm/mlock.c | 8 +
mm/mmap.c | 16 ++-
mm/mmzone.c | 21 +++
mm/mprotect.c | 2 +-
mm/mremap.c | 4 +-
mm/nommu.c | 1 +
mm/page_alloc.c | 33 +++-
mm/percpu.c | 2 +-
mm/swapfile.c | 6 +-
mm/vmalloc.c | 9 +
mm/vmscan.c | 53 +++++-
mm/vmstat.c | 15 ++-
net/can/bcm.c | 2 +-
net/compat.c | 10 +-
net/core/dev.c | 20 ++-
net/core/ethtool.c | 4 +-
net/core/iovec.c | 17 +-
net/core/rtnetlink.c | 3 +
net/core/stream.c | 8 +-
net/dccp/input.c | 7 +-
net/decnet/af_decnet.c | 2 +
net/econet/af_econet.c | 91 +++++------
net/ipv4/datagram.c | 5 +-
net/ipv4/inet_timewait_sock.c | 2 +
net/ipv4/ip_gre.c | 1 +
net/ipv4/ip_output.c | 19 ++-
net/ipv4/ipip.c | 1 +
net/ipv4/route.c | 7 +-
net/ipv4/tcp.c | 11 +-
net/ipv4/tcp_input.c | 2 +
net/ipv4/udp.c | 44 +++++
net/ipv4/xfrm4_policy.c | 4 +-
net/ipv6/datagram.c | 7 +-
net/ipv6/ip6_output.c | 18 ++-
net/ipv6/route.c | 28 +++-
net/ipv6/sit.c | 2 +-
net/ipv6/udp.c | 10 +
net/irda/iriap.c | 3 +-
net/irda/parameters.c | 4 +-
net/mac80211/rx.c | 4 -
net/netfilter/nf_conntrack_core.c | 3 +-
net/netfilter/nf_log.c | 4 +
net/phonet/pep.c | 3 +-
net/rds/page.c | 27 +---
net/rds/rdma.c | 2 +-
net/rose/af_rose.c | 4 +-
net/sctp/auth.c | 8 +-
net/sctp/input.c | 22 ++-
net/sctp/output.c | 1 -
net/sctp/sm_sideeffect.c | 35 ++++
net/sctp/transport.c | 2 +
net/socket.c | 4 +
net/sunrpc/cache.c | 4 +-
net/sunrpc/svc_xprt.c | 9 +-
net/wireless/wext-priv.c | 2 +-
net/x25/af_x25.c | 47 +++++-
net/x25/x25_facilities.c | 32 +++-
net/x25/x25_in.c | 17 ++-
net/x25/x25_link.c | 4 +
security/integrity/ima/ima_policy.c | 2 +
security/keys/keyctl.c | 6 +-
security/selinux/hooks.c | 11 +-
security/selinux/nlmsgtab.c | 2 +
sound/core/control.c | 5 +
sound/core/hrtimer.c | 5 +-
sound/core/rawmidi.c | 4 +-
sound/oss/soundcard.c | 4 +-
sound/pci/au88x0/au88x0_pcm.c | 24 +++-
sound/pci/hda/hda_eld.c | 2 +-
sound/pci/hda/hda_intel.c | 2 +
sound/pci/hda/patch_analog.c | 1 +
sound/pci/hda/patch_conexant.c | 8 +-
sound/pci/hda/patch_realtek.c | 22 ++-
sound/pci/hda/patch_sigmatel.c | 2 +
sound/pci/intel8x0.c | 6 +
sound/pci/oxygen/oxygen.c | 4 +
sound/pci/rme9652/hdsp.c | 1 +
sound/pci/rme9652/hdspm.c | 1 +
sound/soc/blackfin/bf5xx-ac97.c | 4 +-
sound/soc/codecs/wm8990.c | 10 +-
sound/usb/caiaq/audio.c | 2 +-
sound/usb/caiaq/midi.c | 2 +-
sound/usb/usx2y/us122l.c | 41 +++---
454 files changed, 3937 insertions(+), 1490 deletions(-)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [000/474] 2.6.33.8-longterm review
2011-03-17 21:38 [000/474] 2.6.33.8-longterm review Greg KH
` (4 preceding siblings ...)
2011-03-17 21:28 ` [430/474] MIPS: MTX-1: Make au1000_eth probe all PHY addresses Greg KH
@ 2011-03-18 5:26 ` Mike Galbraith
2011-03-18 8:44 ` Thomas Gleixner
` (2 subsequent siblings)
8 siblings, 0 replies; 16+ messages in thread
From: Mike Galbraith @ 2011-03-18 5:26 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, stable, stable-review, torvalds, akpm, tglx
On Thu, 2011-03-17 at 14:38 -0700, Greg KH wrote:
> Yeah, I know what you are thinking, "What, 2.6.33, are you crazy?"
Nah, dedicated. Thanks for the effort.
> So, if you are using .33, please give this patch a test and let me know
> if I've messed up anything (hint, I think I did, it's up to you to
> figure it out, consider it a test to see if anyone actually cares about
> this kernel version.)
I've cloned it, donning hip-waders.
-Mike
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [000/474] 2.6.33.8-longterm review
2011-03-17 21:38 [000/474] 2.6.33.8-longterm review Greg KH
` (5 preceding siblings ...)
2011-03-18 5:26 ` [000/474] 2.6.33.8-longterm review Mike Galbraith
@ 2011-03-18 8:44 ` Thomas Gleixner
2011-03-19 14:47 ` Remy Bohmer
2011-03-18 9:21 ` John Kacur
[not found] ` <20110317212903.394948496@clark.kroah.org>
8 siblings, 1 reply; 16+ messages in thread
From: Thomas Gleixner @ 2011-03-18 8:44 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, stable, stable-review, torvalds, akpm, mgalbraith
On Thu, 17 Mar 2011, Greg KH wrote:
> Yeah, I know what you are thinking, "What, 2.6.33, are you crazy?"
Aren't we all crazy ?
> I'd prefer it if you didn't answer that question...
Too late. You should have put this before the question.
> So, if you are using .33, please give this patch a test and let me know
> if I've messed up anything (hint, I think I did, it's up to you to
> figure it out, consider it a test to see if anyone actually cares about
> this kernel version.)
We'll pull it into rt and figure out what breaks.
Thanks for the effort,
tglx
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [000/474] 2.6.33.8-longterm review
2011-03-17 21:38 [000/474] 2.6.33.8-longterm review Greg KH
` (6 preceding siblings ...)
2011-03-18 8:44 ` Thomas Gleixner
@ 2011-03-18 9:21 ` John Kacur
2011-03-18 19:36 ` Greg KH
[not found] ` <20110317212903.394948496@clark.kroah.org>
8 siblings, 1 reply; 16+ messages in thread
From: John Kacur @ 2011-03-18 9:21 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, stable, stable-review, torvalds, akpm, mgalbraith, tglx
On Thu, Mar 17, 2011 at 10:38 PM, Greg KH <gregkh@suse.de> wrote:
> Yeah, I know what you are thinking, "What, 2.6.33, are you crazy?"
>
> I'd prefer it if you didn't answer that question...
>
> Anyway, yes, a .33 kernel release, strange isn't it.
>
> Turns out there are a lot of people "stuck" on the 2.6.33 kernel series
> for a variety of valid reasons, not the least being the Real Time
> patchset. So, in the copious spare time I have, I've been trying to
> keep up with the patches that have been applied to the different
> longterm and stable kernel trees and have been queueing them up for .33
> as well.
>
> Here's the result of that. A 474 patch series that is bigger than most
> people ever want to review, or see in their inboxes. Because of that,
> it is ONLY being sent to the stable-review@kernel.org mailing list. If
> you want to see the individual patches, look at the git tree of the
> patch queue, or look at that mailing list.
>
> So, if you are using .33, please give this patch a test and let me know
> if I've messed up anything (hint, I think I did, it's up to you to
> figure it out, consider it a test to see if anyone actually cares about
> this kernel version.)
>
> If I missed anything that I should have in here, please let me know.
>
> Responses should be made by Saturday, March 19, 2011, 21:00:00 UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.33.8-rc1.gz
> and the diffstat can be found below.
>
There is no rc1, so I assume
http://kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.33.8.bz2
is correct?
Which git tree do I want to use?
Thanks
John Kacur
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [000/474] 2.6.33.8-longterm review
2011-03-18 9:21 ` John Kacur
@ 2011-03-18 19:36 ` Greg KH
2011-03-19 10:08 ` [stable] " John Kacur
0 siblings, 1 reply; 16+ messages in thread
From: Greg KH @ 2011-03-18 19:36 UTC (permalink / raw)
To: John Kacur
Cc: linux-kernel, stable, stable-review, torvalds, akpm, mgalbraith, tglx
On Fri, Mar 18, 2011 at 10:21:54AM +0100, John Kacur wrote:
> On Thu, Mar 17, 2011 at 10:38 PM, Greg KH <gregkh@suse.de> wrote:
> > Yeah, I know what you are thinking, "What, 2.6.33, are you crazy?"
> >
> > I'd prefer it if you didn't answer that question...
> >
> > Anyway, yes, a .33 kernel release, strange isn't it.
> >
> > Turns out there are a lot of people "stuck" on the 2.6.33 kernel series
> > for a variety of valid reasons, not the least being the Real Time
> > patchset. So, in the copious spare time I have, I've been trying to
> > keep up with the patches that have been applied to the different
> > longterm and stable kernel trees and have been queueing them up for .33
> > as well.
> >
> > Here's the result of that. A 474 patch series that is bigger than most
> > people ever want to review, or see in their inboxes. Because of that,
> > it is ONLY being sent to the stable-review@kernel.org mailing list. If
> > you want to see the individual patches, look at the git tree of the
> > patch queue, or look at that mailing list.
> >
> > So, if you are using .33, please give this patch a test and let me know
> > if I've messed up anything (hint, I think I did, it's up to you to
> > figure it out, consider it a test to see if anyone actually cares about
> > this kernel version.)
> >
> > If I missed anything that I should have in here, please let me know.
> >
> > Responses should be made by Saturday, March 19, 2011, 21:00:00 UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.33.8-rc1.gz
> > and the diffstat can be found below.
> >
>
> There is no rc1, so I assume
> http://kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.33.8.bz2
> is correct?
Doh, yes, that is correct, I forgot to put -rc in the Makefile, and my
scripts just picked it up and went from there. My fault.
> Which git tree do I want to use?
There is no git tree of the expanded tree of patches, just use that
patch on top of 2.6.33.7 please.
Or you can apply the quilt patchs, all 474 of them, which are included
in the longterm-2.6.33 queue on git.kernel.org
thanks,
greg k-h
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [stable] [000/474] 2.6.33.8-longterm review
2011-03-18 19:36 ` Greg KH
@ 2011-03-19 10:08 ` John Kacur
0 siblings, 0 replies; 16+ messages in thread
From: John Kacur @ 2011-03-19 10:08 UTC (permalink / raw)
To: Greg KH
Cc: mgalbraith, linux-kernel, stable, tglx, akpm, torvalds, stable-review
On Fri, Mar 18, 2011 at 8:36 PM, Greg KH <gregkh@suse.de> wrote:
> On Fri, Mar 18, 2011 at 10:21:54AM +0100, John Kacur wrote:
>> On Thu, Mar 17, 2011 at 10:38 PM, Greg KH <gregkh@suse.de> wrote:
>> > Yeah, I know what you are thinking, "What, 2.6.33, are you crazy?"
>> >
>> > I'd prefer it if you didn't answer that question...
>> >
>> > Anyway, yes, a .33 kernel release, strange isn't it.
>> >
>> > Turns out there are a lot of people "stuck" on the 2.6.33 kernel series
>> > for a variety of valid reasons, not the least being the Real Time
>> > patchset. So, in the copious spare time I have, I've been trying to
>> > keep up with the patches that have been applied to the different
>> > longterm and stable kernel trees and have been queueing them up for .33
>> > as well.
>> >
>> > Here's the result of that. A 474 patch series that is bigger than most
>> > people ever want to review, or see in their inboxes. Because of that,
>> > it is ONLY being sent to the stable-review@kernel.org mailing list. If
>> > you want to see the individual patches, look at the git tree of the
>> > patch queue, or look at that mailing list.
>> >
>> > So, if you are using .33, please give this patch a test and let me know
>> > if I've messed up anything (hint, I think I did, it's up to you to
>> > figure it out, consider it a test to see if anyone actually cares about
>> > this kernel version.)
>> >
>> > If I missed anything that I should have in here, please let me know.
>> >
>> > Responses should be made by Saturday, March 19, 2011, 21:00:00 UTC.
>> > Anything received after that time might be too late.
>> >
>> > The whole patch series can be found in one patch at:
>> > kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.33.8-rc1.gz
>> > and the diffstat can be found below.
>> >
>>
>> There is no rc1, so I assume
>> http://kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.33.8.bz2
>> is correct?
>
> Doh, yes, that is correct, I forgot to put -rc in the Makefile, and my
> scripts just picked it up and went from there. My fault.
>
>> Which git tree do I want to use?
>
> There is no git tree of the expanded tree of patches, just use that
> patch on top of 2.6.33.7 please.
>
> Or you can apply the quilt patchs, all 474 of them, which are included
> in the longterm-2.6.33 queue on git.kernel.org
>
Thanks, actually that was what I was looking for, the git tree of the
quilt patches. Which are easy to script as git commits which makes
techniques like bisection easy.
Thanks
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [000/474] 2.6.33.8-longterm review
2011-03-18 8:44 ` Thomas Gleixner
@ 2011-03-19 14:47 ` Remy Bohmer
2011-03-20 12:52 ` Thomas Gleixner
0 siblings, 1 reply; 16+ messages in thread
From: Remy Bohmer @ 2011-03-19 14:47 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Greg KH, linux-kernel, linux-rt-users
Hi,
2011/3/18 Thomas Gleixner <tglx@linutronix.de>:
> On Thu, 17 Mar 2011, Greg KH wrote:
>
>> Yeah, I know what you are thinking, "What, 2.6.33, are you crazy?"
>
> Aren't we all crazy ?
>
>> I'd prefer it if you didn't answer that question...
>
> Too late. You should have put this before the question.
>
>> So, if you are using .33, please give this patch a test and let me know
>> if I've messed up anything (hint, I think I did, it's up to you to
>> figure it out, consider it a test to see if anyone actually cares about
>> this kernel version.)
>
> We'll pull it into rt and figure out what breaks.
Can you please elaborate somewhat on the status of the RT-patchset
development for 2.6.38 and on?
It is silent about it for quite a while now, and actually the gap
between mainstream and the latest RT has never been this big before...
Are there major complications, lack on time or hands? Can I help ?
Thanks for the all the effort,
Kind regards,
Remy
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [000/474] 2.6.33.8-longterm review
2011-03-19 14:47 ` Remy Bohmer
@ 2011-03-20 12:52 ` Thomas Gleixner
2011-03-20 14:06 ` Niccolò Belli
0 siblings, 1 reply; 16+ messages in thread
From: Thomas Gleixner @ 2011-03-20 12:52 UTC (permalink / raw)
To: Remy Bohmer; +Cc: Greg KH, linux-kernel, linux-rt-users
On Sat, 19 Mar 2011, Remy Bohmer wrote:
> Hi,
>
> 2011/3/18 Thomas Gleixner <tglx@linutronix.de>:
> > On Thu, 17 Mar 2011, Greg KH wrote:
> >
> >> Yeah, I know what you are thinking, "What, 2.6.33, are you crazy?"
> >
> > Aren't we all crazy ?
> >
> >> I'd prefer it if you didn't answer that question...
> >
> > Too late. You should have put this before the question.
> >
> >> So, if you are using .33, please give this patch a test and let me know
> >> if I've messed up anything (hint, I think I did, it's up to you to
> >> figure it out, consider it a test to see if anyone actually cares about
> >> this kernel version.)
> >
> > We'll pull it into rt and figure out what breaks.
>
> Can you please elaborate somewhat on the status of the RT-patchset
> development for 2.6.38 and on?
Working on it.
> It is silent about it for quite a while now, and actually the gap
> between mainstream and the latest RT has never been this big before...
> Are there major complications, lack on time or hands? Can I help ?
I concentrated on getting stuff upstream and reworking to make it more
palatable and maintainable.
Thanks,
tglx
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [000/474] 2.6.33.8-longterm review
2011-03-20 12:52 ` Thomas Gleixner
@ 2011-03-20 14:06 ` Niccolò Belli
0 siblings, 0 replies; 16+ messages in thread
From: Niccolò Belli @ 2011-03-20 14:06 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Remy Bohmer, Greg KH, linux-kernel, linux-rt-users
Il 20/03/2011 13:52, Thomas Gleixner ha scritto:
> On Sat, 19 Mar 2011, Remy Bohmer wrote:
>> Can you please elaborate somewhat on the status of the RT-patchset
>> development for 2.6.38 and on?
>
> Working on it.
>
>> It is silent about it for quite a while now, and actually the gap
>> between mainstream and the latest RT has never been this big before...
>> Are there major complications, lack on time or hands? Can I help ?
>
> I concentrated on getting stuff upstream and reworking to make it more
> palatable and maintainable.
Is there a working (where working means working for testing purposes)
snapshot somewhere?
Thanks,
Darkbasic
^ permalink raw reply [flat|nested] 16+ messages in thread
* [regression] Re: [213/474] x86, hotplug: Use mwait to offline a processor, fix the legacy case
[not found] ` <20110317212903.394948496@clark.kroah.org>
@ 2011-08-28 18:40 ` Jonathan Nieder
[not found] ` <20110828184004.GA7690@elie.gateway.2wire.net>
1 sibling, 0 replies; 16+ messages in thread
From: Jonathan Nieder @ 2011-08-28 18:40 UTC (permalink / raw)
To: Len Brown
Cc: Greg KH, Robert Scott, x86, Frédéric Boiteux, stable,
Venkatesh Pallipadi, linux-pm, H. Peter Anvin, stable-review
Hi,
On 2011-03-17, Greg KH wrote:
> 2.6.33-longterm review patch. If anyone has any objections, please let us know.
[...]
> From: H. Peter Anvin <hpa@linux.intel.com>
>
> upstream ea53069231f9317062910d6e772cca4ce93de8c8
> x86, hotplug: Use mwait to offline a processor, fix the legacy case
>
> Here included also some small follow-on patches to the same code:
[...]
> https://bugzilla.kernel.org/show_bug.cgi?id=5471
>
> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
> Signed-off-by: Len Brown <len.brown@intel.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sorry for the sloow response. Unfortunately this is reported to have
broken hibernation on two machines: an EeePC 1002HA and an Ideapad S10-3.
Frédéric writes:
| I've observed that when resuming from hibernation, sometimes my computer was
| returning to Grub2's menu (without any error message), and I had to do a
| "normal" boot on my Debian Squeeze system (with file systems corrections),
| loosing my hibernation's state.
| The fail isn't automatic, but seems to happen more frequently after a while
| my computer was disconnected from AC and battery.
Noticed on Debian squeeze (which is based on v2.6.32.y), confirmed
with unpatched v2.6.32.45 and v2.6.33.18. Backing out the patch
mentioned above avoids trouble. A newer kernel (based on v2.6.39.y)
does _not_ exhibit the same problem, so it looks like the problem was
introduced in backporting. http://bugs.debian.org/622259 has
details.
Ideas?
Thanks,
Jonathan
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [stable] [regression] Re: [213/474] x86, hotplug: Use mwait to offline a processor, fix the legacy case
[not found] ` <20110828184004.GA7690@elie.gateway.2wire.net>
@ 2011-08-30 22:34 ` Greg KH
0 siblings, 0 replies; 16+ messages in thread
From: Greg KH @ 2011-08-30 22:34 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Len Brown, x86, Robert Scott, Greg KH,
Frédéric Boiteux, stable-review, Venkatesh Pallipadi,
linux-pm, H. Peter Anvin, stable
On Sun, Aug 28, 2011 at 01:40:04PM -0500, Jonathan Nieder wrote:
> Hi,
>
> On 2011-03-17, Greg KH wrote:
>
> > 2.6.33-longterm review patch. If anyone has any objections, please let us know.
> [...]
> > From: H. Peter Anvin <hpa@linux.intel.com>
> >
> > upstream ea53069231f9317062910d6e772cca4ce93de8c8
> > x86, hotplug: Use mwait to offline a processor, fix the legacy case
> >
> > Here included also some small follow-on patches to the same code:
> [...]
> > https://bugzilla.kernel.org/show_bug.cgi?id=5471
> >
> > Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
> > Signed-off-by: Len Brown <len.brown@intel.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
> Sorry for the sloow response. Unfortunately this is reported to have
> broken hibernation on two machines: an EeePC 1002HA and an Ideapad S10-3.
> Frédéric writes:
>
> | I've observed that when resuming from hibernation, sometimes my computer was
> | returning to Grub2's menu (without any error message), and I had to do a
> | "normal" boot on my Debian Squeeze system (with file systems corrections),
> | loosing my hibernation's state.
> | The fail isn't automatic, but seems to happen more frequently after a while
> | my computer was disconnected from AC and battery.
>
> Noticed on Debian squeeze (which is based on v2.6.32.y), confirmed
> with unpatched v2.6.32.45 and v2.6.33.18. Backing out the patch
> mentioned above avoids trouble. A newer kernel (based on v2.6.39.y)
> does _not_ exhibit the same problem, so it looks like the problem was
> introduced in backporting. http://bugs.debian.org/622259 has
> details.
Thanks for letting me know, I'll go revert that patch for the next .32
and .33 longterm releases and let everyone else work out exactly what
the problem is, if they want to.
greg k-h
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-08-30 22:34 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-17 21:38 [000/474] 2.6.33.8-longterm review Greg KH
2011-03-17 21:22 ` [072/474] mm, x86: Saving vmcore with non-lazy freeing of vmas Greg KH
2011-03-17 21:22 ` [078/474] x86, kdump: Change copy_oldmem_page() to use cached addressing Greg KH
2011-03-17 21:24 ` [213/474] x86, hotplug: Use mwait to offline a processor, fix the legacy case Greg KH
2011-03-17 21:27 ` [421/474] powerpc/kexec: Fix orphaned offline CPUs across kexec Greg KH
2011-03-17 21:28 ` [430/474] MIPS: MTX-1: Make au1000_eth probe all PHY addresses Greg KH
2011-03-18 5:26 ` [000/474] 2.6.33.8-longterm review Mike Galbraith
2011-03-18 8:44 ` Thomas Gleixner
2011-03-19 14:47 ` Remy Bohmer
2011-03-20 12:52 ` Thomas Gleixner
2011-03-20 14:06 ` Niccolò Belli
2011-03-18 9:21 ` John Kacur
2011-03-18 19:36 ` Greg KH
2011-03-19 10:08 ` [stable] " John Kacur
[not found] ` <20110317212903.394948496@clark.kroah.org>
2011-08-28 18:40 ` [regression] Re: [213/474] x86, hotplug: Use mwait to offline a processor, fix the legacy case Jonathan Nieder
[not found] ` <20110828184004.GA7690@elie.gateway.2wire.net>
2011-08-30 22:34 ` [stable] " Greg KH
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.