Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, May 07, 2007 at 10:31:32PM -0700, William Lee Irwin III wrote:
>> I think Andi's handling the mergework on those patches, but I'll check
>> in to see if I should rediff vs. -mm or what if you want them.
>> Andi, what's the verdict on those stack patches?
On Tue, May 08, 2007 at 10:59:50AM +0200, Andi Kleen wrote:
> I planned to merge them partially. Add the separate 4/8/irqstack options,
> add the vmalloc support, but not support the > 8K stacks. Haven't yet.
I respun things to incorporate some of hch's suggestions and to fix
an issue Jeremy Fitzhardinge had with CPU hotplug, and some suggestion
from someone else, too.
Basically what changed was:
( 1) drop the large stack config option patch entirely
( 2) fold the __pa() check into the vmalloc stack patch under #ifdef
( 3) rename CONFIG_VMALLOC_STACK to CONFIG_DEBUG_STACK
( 4) fold guarding CPU 0's IRQ stack into the vmalloc stack patch
( 5) make IRQ stacks unconditional instead of independently configurable
( 6) check slab_is_available() for CPU 0's bootmem vs. get_free_pages()
( 7) mark various things __cpuinit that needed to be
( 8) handle and propagate allocation errors up to __cpu_up()
( 9) redo CPU 0's IRQ stack allocation to normalize it for hotplug
(10) use a struct for IRQ stack state instead of 3 per_cpu vars
The current patch series needs the two fixup patches at the end folded
back into the patches it fixes up, but follows in its entirety as a
series of MIME attachments. I've no idea what it applies against.
-- wli
Subject: dynamically allocate IRQ stacks
Dynamically allocate IRQ stacks in order to conserve memory when using
IRQ stacks. cpu_possible_map is not now initialized in such a manner as
to provide a meaningful indication of how many CPU's might be in the
system, and features to appear in the sequel also require indirection,
so they themselves are not allocatable as per_cpu variables, but rather
only pointers to them.
Signed-off-by: William Irwin <[EMAIL PROTECTED]>
Index: stack-paranoia/arch/i386/kernel/irq.c
===
--- stack-paranoia.orig/arch/i386/kernel/irq.c 2007-04-30 14:18:25.645682879 -0700
+++ stack-paranoia/arch/i386/kernel/irq.c 2007-05-01 10:19:38.028853928 -0700
@@ -17,9 +17,11 @@
#include
#include
#include
+#include
#include
#include
+#include
DEFINE_PER_CPU(irq_cpustat_t, irq_stat) cacheline_internodealigned_in_smp;
EXPORT_PER_CPU_SYMBOL(irq_stat);
@@ -56,8 +58,8 @@
u32 stack[THREAD_SIZE/sizeof(u32)];
};
-static union irq_ctx *hardirq_ctx[NR_CPUS] __read_mostly;
-static union irq_ctx *softirq_ctx[NR_CPUS] __read_mostly;
+static DEFINE_PER_CPU(union irq_ctx *, hardirq_ctx);
+static DEFINE_PER_CPU(union irq_ctx *, softirq_ctx);
#endif
/*
@@ -102,7 +104,7 @@
#ifdef CONFIG_4KSTACKS
curctx = (union irq_ctx *) current_thread_info();
- irqctx = hardirq_ctx[smp_processor_id()];
+ irqctx = per_cpu(hardirq_ctx, smp_processor_id());
/*
* this is where we switch to the IRQ stack. However, if we are
@@ -150,11 +152,24 @@
* These should really be __section__(".bss.page_aligned") as well, but
* gcc's 3.0 and earlier don't handle that correctly.
*/
-static char softirq_stack[NR_CPUS * THREAD_SIZE]
- __attribute__((__aligned__(THREAD_SIZE)));
+static DEFINE_PER_CPU(char *, softirq_stack);
+static DEFINE_PER_CPU(char *, hardirq_stack);
-static char hardirq_stack[NR_CPUS * THREAD_SIZE]
- __attribute__((__aligned__(THREAD_SIZE)));
+static void * __init __alloc_irqstack(int cpu)
+{
+ if (!slab_is_available())
+ return __alloc_bootmem(THREAD_SIZE, THREAD_SIZE,
+ __pa(MAX_DMA_ADDRESS));
+
+ return (void *)__get_free_pages(GFP_KERNEL,
+ ilog2(THREAD_SIZE/PAGE_SIZE));
+}
+
+static void __init alloc_irqstacks(int cpu)
+{
+ per_cpu(softirq_stack, cpu) = __alloc_irqstack(cpu);
+ per_cpu(hardirq_stack, cpu) = __alloc_irqstack(cpu);
+}
/*
* allocate per-cpu stacks for hardirq and for softirq processing
@@ -163,34 +178,36 @@
{
union irq_ctx *irqctx;
- if (hardirq_ctx[cpu])
+ if (per_cpu(hardirq_ctx, cpu))
return;
- irqctx = (union irq_ctx*) _stack[cpu*THREAD_SIZE];
+ alloc_irqstacks(cpu);
+
+ irqctx = (union irq_ctx*)per_cpu(hardirq_stack, cpu);
irqctx->tinfo.task = NULL;
irqctx->tinfo.exec_domain = NULL;
irqctx->tinfo.cpu = cpu;
irqctx->tinfo.preempt_count = HARDIRQ_OFFSET;
irqctx->tinfo.addr_limit= MAKE_MM_SEG(0);
- hardirq_ctx[cpu] = irqctx;
+ per_cpu(hardirq_ctx, cpu) = irqctx;
- irqctx = (union irq_ctx*) _stack[cpu*THREAD_SIZE];
+ irqctx = (union irq_ctx*)per_cpu(softirq_stack, cpu);
irqctx->tinfo.task = NULL;
irqctx->tinfo.exec_domain = NULL;
irqctx->tinfo.cpu = cpu;
irqctx->tinfo.preempt_count = 0;
irqctx->tinfo.addr_limit= MAKE_MM_SEG(0);
- softirq_ctx[cpu] = irqctx;
+ per_cpu(softirq_ctx, cpu) = irqctx;
printk("CPU %u irqstacks, hard=%p soft=%p\n",
-
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, May 07, 2007 at 10:31:32PM -0700, William Lee Irwin III wrote: > On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> > wrote: > >> I'm using wli's 8k > >> stack + irq stack patches with good success though. > > On Mon, May 07, 2007 at 10:24:09PM -0700, Andrew Morton wrote: > > wlis are handy. > > I think Andi's handling the mergework on those patches, but I'll check > in to see if I should rediff vs. -mm or what if you want them. > > Andi, what's the verdict on those stack patches? I planned to merge them partially. Add the separate 4/8/irqstack options, add the vmalloc support, but not support the > 8K stacks. Haven't yet. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On May 8 2007 16:18, David Chinner wrote: > >On Mon, May 07, 2007 at 10:38:24PM -0700, Jeremy Fitzhardinge wrote: >> Andrew Morton wrote: >> > On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> >> > wrote: >> > >> >> I've found that XFS+lvm+4k stacks is completely unusable with current >> >> kernels. I get hangs/oopes after ~10mins of work. >> > >> > Sounds like this is new behaviour? >> > I wonder why. Same compiler version? >> >> I've only recently started using xfs, so I couldn't say if its new >> behaviour. I did notice that it took a week or so for problems to set >> in; my theory is that as the filesystem got a bit aged, its >> datastructures got a bit more complex, and cause the kernel code to use >> more stack. But that's just a guess. FWIW, I run dm-crypt+xfs on one machine, of course with 8k since that's suse default. No issues. dm-crypt and lvm got something in common, don't they? Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, May 07, 2007 at 10:38:24PM -0700, Jeremy Fitzhardinge wrote: > Andrew Morton wrote: > > On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> > > wrote: > > > >> I've found that XFS+lvm+4k stacks is completely unusable with current > >> kernels. I get hangs/oopes after ~10mins of work. > >> > > > > Sounds like this is new behaviour? > > > > I wonder why. Same compiler version? > > I've only recently started using xfs, so I couldn't say if its new > behaviour. I did notice that it took a week or so for problems to set > in; my theory is that as the filesystem got a bit aged, its > datastructures got a bit more complex, and cause the kernel code to use > more stack. But that's just a guess. The worst case stack usage through XFS occurs when it has to read metadata blocks in the writeback path when doing an allocation transaction. This happens when walking the freespace btrees looking for an extent matching the allocation requirements. As the fileystem fills up, these btrees will grow and you are more likely not to have a block inthe btree cached in memory. So yes, this is a possible reason you hadn't seen any problems early on. FWIW, there's also been recent reports of both ext3 and reiser on LVM blowing 4k stacks, so if you use LVM it probably advisable to go back to 8k stacks Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, 7 May 2007 22:31:32 -0700 William Lee Irwin III <[EMAIL PROTECTED]> wrote: >> I think Andi's handling the mergework on those patches, but I'll check >> in to see if I should rediff vs. -mm or what if you want them. >> Andi, what's the verdict on those stack patches? On Mon, May 07, 2007 at 10:37:38PM -0700, Andrew Morton wrote: > Whoa. The verdict is usually "don't use so much stack". > Do we know what has gone wrong here? > Last week Jens said he was picking up the ancient > md-dm-reduce-stack-usage-with-stacked-block-devices.patch, but he doesn't > seem to have done so yet. > XFS is frequently implicated. Well, the culmination of those patches is a patch to use vmallocspace to establish guard pages for stacks so overflows are immediately trapped and the potential for silent corruption greatly reduced. That would be where I suspect it's most relevant, as that's the focal point of the series. The bit about unconditional IRQ stacks arose as part of review. It started life as a set of patches intended to help with debugging stack overflows, which is how the only tangentially-related unconditional IRQ stacks came about: originally they were optional as a debug option for differential diagnosis of interrupt-time overflows. For mainline, hch suggested that they should rather be made unconditional. The third part of the series that survived review was dynamic boot-time allocation of IRQ stacks, which was originally motivated by the need for indirection when remapping IRQ stacks into vmallocspace, but also served the purpose of mitigating space overhead when using IRQ stacks because cpu_possible_map is not set up as it should be to avoid the allocation via per_cpu array variables' dynamic boot-time allocation on i386 and (AFAIK) x86-64. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, 7 May 2007 22:31:32 -0700 William Lee Irwin III [EMAIL PROTECTED] wrote: I think Andi's handling the mergework on those patches, but I'll check in to see if I should rediff vs. -mm or what if you want them. Andi, what's the verdict on those stack patches? On Mon, May 07, 2007 at 10:37:38PM -0700, Andrew Morton wrote: Whoa. The verdict is usually don't use so much stack. Do we know what has gone wrong here? Last week Jens said he was picking up the ancient md-dm-reduce-stack-usage-with-stacked-block-devices.patch, but he doesn't seem to have done so yet. XFS is frequently implicated. Well, the culmination of those patches is a patch to use vmallocspace to establish guard pages for stacks so overflows are immediately trapped and the potential for silent corruption greatly reduced. That would be where I suspect it's most relevant, as that's the focal point of the series. The bit about unconditional IRQ stacks arose as part of review. It started life as a set of patches intended to help with debugging stack overflows, which is how the only tangentially-related unconditional IRQ stacks came about: originally they were optional as a debug option for differential diagnosis of interrupt-time overflows. For mainline, hch suggested that they should rather be made unconditional. The third part of the series that survived review was dynamic boot-time allocation of IRQ stacks, which was originally motivated by the need for indirection when remapping IRQ stacks into vmallocspace, but also served the purpose of mitigating space overhead when using IRQ stacks because cpu_possible_map is not set up as it should be to avoid the allocation via per_cpu array variables' dynamic boot-time allocation on i386 and (AFAIK) x86-64. -- wli - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, May 07, 2007 at 10:38:24PM -0700, Jeremy Fitzhardinge wrote: Andrew Morton wrote: On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: I've found that XFS+lvm+4k stacks is completely unusable with current kernels. I get hangs/oopes after ~10mins of work. Sounds like this is new behaviour? I wonder why. Same compiler version? I've only recently started using xfs, so I couldn't say if its new behaviour. I did notice that it took a week or so for problems to set in; my theory is that as the filesystem got a bit aged, its datastructures got a bit more complex, and cause the kernel code to use more stack. But that's just a guess. The worst case stack usage through XFS occurs when it has to read metadata blocks in the writeback path when doing an allocation transaction. This happens when walking the freespace btrees looking for an extent matching the allocation requirements. As the fileystem fills up, these btrees will grow and you are more likely not to have a block inthe btree cached in memory. So yes, this is a possible reason you hadn't seen any problems early on. FWIW, there's also been recent reports of both ext3 and reiser on LVM blowing 4k stacks, so if you use LVM it probably advisable to go back to 8k stacks Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On May 8 2007 16:18, David Chinner wrote: On Mon, May 07, 2007 at 10:38:24PM -0700, Jeremy Fitzhardinge wrote: Andrew Morton wrote: On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: I've found that XFS+lvm+4k stacks is completely unusable with current kernels. I get hangs/oopes after ~10mins of work. Sounds like this is new behaviour? I wonder why. Same compiler version? I've only recently started using xfs, so I couldn't say if its new behaviour. I did notice that it took a week or so for problems to set in; my theory is that as the filesystem got a bit aged, its datastructures got a bit more complex, and cause the kernel code to use more stack. But that's just a guess. FWIW, I run dm-crypt+xfs on one machine, of course with 8k since that's suse default. No issues. dm-crypt and lvm got something in common, don't they? Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, May 07, 2007 at 10:31:32PM -0700, William Lee Irwin III wrote: On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: I'm using wli's 8k stack + irq stack patches with good success though. On Mon, May 07, 2007 at 10:24:09PM -0700, Andrew Morton wrote: wlis are handy. I think Andi's handling the mergework on those patches, but I'll check in to see if I should rediff vs. -mm or what if you want them. Andi, what's the verdict on those stack patches? I planned to merge them partially. Add the separate 4/8/irqstack options, add the vmalloc support, but not support the 8K stacks. Haven't yet. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, May 07, 2007 at 10:31:32PM -0700, William Lee Irwin III wrote:
I think Andi's handling the mergework on those patches, but I'll check
in to see if I should rediff vs. -mm or what if you want them.
Andi, what's the verdict on those stack patches?
On Tue, May 08, 2007 at 10:59:50AM +0200, Andi Kleen wrote:
I planned to merge them partially. Add the separate 4/8/irqstack options,
add the vmalloc support, but not support the 8K stacks. Haven't yet.
I respun things to incorporate some of hch's suggestions and to fix
an issue Jeremy Fitzhardinge had with CPU hotplug, and some suggestion
from someone else, too.
Basically what changed was:
( 1) drop the large stack config option patch entirely
( 2) fold the __pa() check into the vmalloc stack patch under #ifdef
( 3) rename CONFIG_VMALLOC_STACK to CONFIG_DEBUG_STACK
( 4) fold guarding CPU 0's IRQ stack into the vmalloc stack patch
( 5) make IRQ stacks unconditional instead of independently configurable
( 6) check slab_is_available() for CPU 0's bootmem vs. get_free_pages()
( 7) mark various things __cpuinit that needed to be
( 8) handle and propagate allocation errors up to __cpu_up()
( 9) redo CPU 0's IRQ stack allocation to normalize it for hotplug
(10) use a struct for IRQ stack state instead of 3 per_cpu vars
The current patch series needs the two fixup patches at the end folded
back into the patches it fixes up, but follows in its entirety as a
series of MIME attachments. I've no idea what it applies against.
-- wli
Subject: dynamically allocate IRQ stacks
Dynamically allocate IRQ stacks in order to conserve memory when using
IRQ stacks. cpu_possible_map is not now initialized in such a manner as
to provide a meaningful indication of how many CPU's might be in the
system, and features to appear in the sequel also require indirection,
so they themselves are not allocatable as per_cpu variables, but rather
only pointers to them.
Signed-off-by: William Irwin [EMAIL PROTECTED]
Index: stack-paranoia/arch/i386/kernel/irq.c
===
--- stack-paranoia.orig/arch/i386/kernel/irq.c 2007-04-30 14:18:25.645682879 -0700
+++ stack-paranoia/arch/i386/kernel/irq.c 2007-05-01 10:19:38.028853928 -0700
@@ -17,9 +17,11 @@
#include linux/notifier.h
#include linux/cpu.h
#include linux/delay.h
+#include linux/bootmem.h
#include asm/apic.h
#include asm/uaccess.h
+#include asm/pgtable.h
DEFINE_PER_CPU(irq_cpustat_t, irq_stat) cacheline_internodealigned_in_smp;
EXPORT_PER_CPU_SYMBOL(irq_stat);
@@ -56,8 +58,8 @@
u32 stack[THREAD_SIZE/sizeof(u32)];
};
-static union irq_ctx *hardirq_ctx[NR_CPUS] __read_mostly;
-static union irq_ctx *softirq_ctx[NR_CPUS] __read_mostly;
+static DEFINE_PER_CPU(union irq_ctx *, hardirq_ctx);
+static DEFINE_PER_CPU(union irq_ctx *, softirq_ctx);
#endif
/*
@@ -102,7 +104,7 @@
#ifdef CONFIG_4KSTACKS
curctx = (union irq_ctx *) current_thread_info();
- irqctx = hardirq_ctx[smp_processor_id()];
+ irqctx = per_cpu(hardirq_ctx, smp_processor_id());
/*
* this is where we switch to the IRQ stack. However, if we are
@@ -150,11 +152,24 @@
* These should really be __section__(.bss.page_aligned) as well, but
* gcc's 3.0 and earlier don't handle that correctly.
*/
-static char softirq_stack[NR_CPUS * THREAD_SIZE]
- __attribute__((__aligned__(THREAD_SIZE)));
+static DEFINE_PER_CPU(char *, softirq_stack);
+static DEFINE_PER_CPU(char *, hardirq_stack);
-static char hardirq_stack[NR_CPUS * THREAD_SIZE]
- __attribute__((__aligned__(THREAD_SIZE)));
+static void * __init __alloc_irqstack(int cpu)
+{
+ if (!slab_is_available())
+ return __alloc_bootmem(THREAD_SIZE, THREAD_SIZE,
+ __pa(MAX_DMA_ADDRESS));
+
+ return (void *)__get_free_pages(GFP_KERNEL,
+ ilog2(THREAD_SIZE/PAGE_SIZE));
+}
+
+static void __init alloc_irqstacks(int cpu)
+{
+ per_cpu(softirq_stack, cpu) = __alloc_irqstack(cpu);
+ per_cpu(hardirq_stack, cpu) = __alloc_irqstack(cpu);
+}
/*
* allocate per-cpu stacks for hardirq and for softirq processing
@@ -163,34 +178,36 @@
{
union irq_ctx *irqctx;
- if (hardirq_ctx[cpu])
+ if (per_cpu(hardirq_ctx, cpu))
return;
- irqctx = (union irq_ctx*) hardirq_stack[cpu*THREAD_SIZE];
+ alloc_irqstacks(cpu);
+
+ irqctx = (union irq_ctx*)per_cpu(hardirq_stack, cpu);
irqctx-tinfo.task = NULL;
irqctx-tinfo.exec_domain = NULL;
irqctx-tinfo.cpu = cpu;
irqctx-tinfo.preempt_count = HARDIRQ_OFFSET;
irqctx-tinfo.addr_limit= MAKE_MM_SEG(0);
- hardirq_ctx[cpu] = irqctx;
+ per_cpu(hardirq_ctx, cpu) = irqctx;
- irqctx = (union irq_ctx*) softirq_stack[cpu*THREAD_SIZE];
+ irqctx = (union irq_ctx*)per_cpu(softirq_stack, cpu);
irqctx-tinfo.task = NULL;
irqctx-tinfo.exec_domain = NULL;
irqctx-tinfo.cpu = cpu;
irqctx-tinfo.preempt_count = 0;
irqctx-tinfo.addr_limit= MAKE_MM_SEG(0);
- softirq_ctx[cpu] = irqctx;
+
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
Andrew Morton wrote: > On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> > wrote: > >> I've found that XFS+lvm+4k stacks is completely unusable with current >> kernels. I get hangs/oopes after ~10mins of work. >> > > Sounds like this is new behaviour? > > I wonder why. Same compiler version? > I've only recently started using xfs, so I couldn't say if its new behaviour. I did notice that it took a week or so for problems to set in; my theory is that as the filesystem got a bit aged, its datastructures got a bit more complex, and cause the kernel code to use more stack. But that's just a guess. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, 7 May 2007 22:31:32 -0700 William Lee Irwin III <[EMAIL PROTECTED]> wrote: > On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> > wrote: > >> I'm using wli's 8k > >> stack + irq stack patches with good success though. > > On Mon, May 07, 2007 at 10:24:09PM -0700, Andrew Morton wrote: > > wlis are handy. > > I think Andi's handling the mergework on those patches, but I'll check > in to see if I should rediff vs. -mm or what if you want them. > > Andi, what's the verdict on those stack patches? > Whoa. The verdict is usually "don't use so much stack". Do we know what has gone wrong here? Last week Jens said he was picking up the ancient md-dm-reduce-stack-usage-with-stacked-block-devices.patch, but he doesn't seem to have done so yet. XFS is frequently implicated. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: >> I'm using wli's 8k >> stack + irq stack patches with good success though. On Mon, May 07, 2007 at 10:24:09PM -0700, Andrew Morton wrote: > wlis are handy. I think Andi's handling the mergework on those patches, but I'll check in to see if I should rediff vs. -mm or what if you want them. Andi, what's the verdict on those stack patches? -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > Please enable 8k stacks before doing any other debugging things, see if > > that fixes it. > > I've found that XFS+lvm+4k stacks is completely unusable with current > kernels. I get hangs/oopes after ~10mins of work. Sounds like this is new behaviour? I wonder why. Same compiler version? > I'm using wli's 8k > stack + irq stack patches with good success though. > wlis are handy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
Andrew Morton wrote: > Please enable 8k stacks before doing any other debugging things, see if > that fixes it. I've found that XFS+lvm+4k stacks is completely unusable with current kernels. I get hangs/oopes after ~10mins of work. I'm using wli's 8k stack + irq stack patches with good success though. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Tue, 08 May 2007 00:30:31 +0100 Simon Arlott <[EMAIL PROTECTED]> wrote: > On 08/05/07 00:23, Andrew Morton wrote: > > On Mon, 07 May 2007 23:58:36 +0100 > > Simon Arlott <[EMAIL PROTECTED]> wrote: > > > >> I've just got this under mainline too now > >> (0ec54aa8af5e6faa346aa55a1ad15ee6c25bb42d 2007-05-05 22:08:06): > >> > >> [84567.084000] BUG: scheduling while atomic: pdflush/0xeff84acf/186 > >> [84567.084000] INFO: lockdep is turned off. > >> [84567.084000] do_IRQ: stack overflow: 440 > >> [84567.084000] [] show_trace_log_lvl+0x1a/0x30 > >> [84567.084000] [] show_trace+0x12/0x20 > >> [84567.084000] [] dump_stack+0x15/0x20 > >> [84567.084000] [] do_IRQ+0xd8/0xe0 > >> [84567.084000] [] common_interrupt+0x2e/0x34 > >> [84567.084000] [] printk+0x18/0x20 > >> [84567.084000] [] debug_show_held_locks+0x23/0x30 > >> [84567.084000] [] schedule+0x52a/0x680 > >> [84567.084000] [] schedule_timeout+0x8a/0x90 > >> [84567.084000] [] xlog_state_sync+0x21e/0x260 > >> [84567.084000] [] _xfs_log_force+0x44/0x70 > >> [84567.084000] [] xfs_alloc_search_busy+0xd2/0xe0 > >> [84567.084000] [] xfs_alloc_get_freelist+0xe6/0x100 > >> [84567.084000] [] xfs_alloc_split+0x1f/0x4c0 > >> [84567.084000] [] xfs_alloc_insrec+0x35d/0x3b0 > >> [84567.084000] [] xfs_alloc_insert+0x59/0xd0 > >> [84567.084000] [] xfs_free_ag_extent+0x297/0x640 > >> [84567.084000] [] xfs_alloc_fix_freelist+0x1d1/0x4c0 > >> [84567.084000] [] xfs_alloc_vextent+0x1eb/0x4b0 > >> [84567.084000] [] xfs_bmap_btalloc+0x3bb/0x8f0 > >> [84567.084000] [] xfs_bmap_alloc+0x21/0x40 > >> [84567.084000] [] xfs_bmapi+0xdbf/0x1450 > >> [84567.084000] [] xfs_iomap_write_allocate+0x2ba/0x520 > >> [84567.084000] [] xfs_iomap+0x45b/0x470 > >> [84567.084000] [] xfs_bmap+0x2c/0x40 > >> [84567.084000] [] xfs_map_blocks+0x3c/0x80 > >> [84567.084000] [] xfs_page_state_convert+0x2f3/0x670 > >> [84567.084000] [] xfs_vm_writepage+0x5a/0xf0 > >> [84567.084000] [] generic_writepages+0x226/0x360 > >> [84567.084000] [] xfs_vm_writepages+0x24/0x60 > >> [84567.084000] [] do_writepages+0x2c/0x50 > >> [84567.084000] [] __sync_single_inode+0x59/0x1f0 > >> [84567.084000] [] __writeback_single_inode+0x44/0x1d0 > >> [84567.084000] [] sync_sb_inodes+0x1c9/0x2e0 > >> [84567.084000] [] writeback_inodes+0xce/0xe0 > >> [84567.084000] [] wb_kupdate+0x73/0xf0 > >> [84567.084000] [] __pdflush+0xce/0x1a0 > >> [84567.084000] [] pdflush+0x25/0x30 > >> [84567.084000] [] kthread+0x94/0xd0 > >> [84567.084000] [] kernel_thread_helper+0x7/0x1c > >> [84567.084000] === > >> [84567.087000] [] show_trace_log_lvl+0x1a/0x30 > >> [84567.087000] [] do_IRQ: stack overflow: 328 > >> [84567.087000] [] show_trace_log_lvl+0x1a/0x30 > >> [84567.087000] [] show_trace+0x12/0x20 > >> [84567.087000] [] dump_stack+0x15/0x20 > >> [84567.087000] [] do_IRQ+0xd8/0xe0 > >> [84567.087000] [] common_interrupt+0x2e/0x34 > >> [84567.087000] [] printk+0x18/0x20 > >> [84567.087000] [] print_trace_address+0x1d/0x30 > >> [84567.087000] [] dump_trace+0x48/0xb0 > >> [84567.087000] [] show_trace_log_lvl+0x1a/0x30 > >> [84567.087000] [] show_trace+0x12/0x20 > >> [84567.087000] [] dump_stack+0x15/0x20 > >> [84567.087000] [] schedule+0x53a/0x680 > >> [84567.087000] [] schedule_timeout+0x8a/0x90 > >> [84567.087000] [] xlog_state_sync+0x21e/0x260 > >> [84567.087000] [] _xfs_log_force+0x44/0x70 > >> [84567.087000] [] xfs_alloc_search_busy+0xd2/0xe0 > >> [84567.087000] [] xfs_alloc_get_freelist+0xe6/0x100 > >> [84567.087000] [] xfs_alloc_split+0x1f/0x4c0 > >> [84567.087000] [] xfs_alloc_insrec+0x35d/0x3b0 > >> [84567.087000] [] xfs_alloc_insert+0x59/0xd0 > >> [84567.087000] [] xfs_free_ag_extent+0x297/0x640 > >> [84567.087000] [] xfs_alloc_fix_freelist+0x1d1/0x4c0 > >> [84567.087000] [] xfs_alloc_vextent+0x1eb/0x4b0 > >> [84567.087000] [] xfs_bmap_btalloc+0x3bb/0x8f0 > >> [84567.087000] [] xfs_bmap_alloc+0x21/0x40 > >> [84567.087000] [] xfs_bmapi+0xdbf/0x1450 > >> [84567.087000] [] xfs_iomap_write_allocate+0x2ba/0x520 > >> [84567.087000] [] xfs_iomap+0x45b/0x470 > >> [84567.087000] [] xfs_bmap+0x2c/0x40 > >> [84567.087000] [] xfs_map_blocks+0x3c/0x80 > >> [84567.087000] [] xfs_page_state_convert+0x2f3/0x670 > >> [84567.087000] [] xfs_vm_writepage+0x5a/0xf0 > >> [84567.087000] [] generic_writepages+0x226/0x360 > >> [84567.087000] [] xfs_vm_writepages+0x24/0x60 > >> [84567.087000] [] do_writepages+0x2c/0x50 > >> [84567.087000] [] __sync_single_inode+0x59/0x1f0 > >> [84567.087000] [] __writeback_single_inode+0x44/0x1d0 > >> [84567.087000] [] sync_sb_inodes+0x1c9/0x2e0 > >> [84567.087000] [] writeback_inodes+0xce/0xe0 > >> [84567.087000] [] wb_kupdate+0x73/0xf0 > >> [84567.087000] [] __pdflush+0xce/0x1a0 > >> [84567.087000] [] pdflush+0x25/0x30 > >> [84567.087000] [] kthread+0x94/0xd0 > >> [84567.087000] [] kernel_thread_helper+0x7/0x1c > >> [84567.087000] BUG: unable to handle kernel paging request at virtual > >> address 8034 > >>
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On 08/05/07 00:23, Andrew Morton wrote: On Mon, 07 May 2007 23:58:36 +0100 Simon Arlott <[EMAIL PROTECTED]> wrote: I've just got this under mainline too now (0ec54aa8af5e6faa346aa55a1ad15ee6c25bb42d 2007-05-05 22:08:06): [84567.084000] BUG: scheduling while atomic: pdflush/0xeff84acf/186 [84567.084000] INFO: lockdep is turned off. [84567.084000] do_IRQ: stack overflow: 440 [84567.084000] [] show_trace_log_lvl+0x1a/0x30 [84567.084000] [] show_trace+0x12/0x20 [84567.084000] [] dump_stack+0x15/0x20 [84567.084000] [] do_IRQ+0xd8/0xe0 [84567.084000] [] common_interrupt+0x2e/0x34 [84567.084000] [] printk+0x18/0x20 [84567.084000] [] debug_show_held_locks+0x23/0x30 [84567.084000] [] schedule+0x52a/0x680 [84567.084000] [] schedule_timeout+0x8a/0x90 [84567.084000] [] xlog_state_sync+0x21e/0x260 [84567.084000] [] _xfs_log_force+0x44/0x70 [84567.084000] [] xfs_alloc_search_busy+0xd2/0xe0 [84567.084000] [] xfs_alloc_get_freelist+0xe6/0x100 [84567.084000] [] xfs_alloc_split+0x1f/0x4c0 [84567.084000] [] xfs_alloc_insrec+0x35d/0x3b0 [84567.084000] [] xfs_alloc_insert+0x59/0xd0 [84567.084000] [] xfs_free_ag_extent+0x297/0x640 [84567.084000] [] xfs_alloc_fix_freelist+0x1d1/0x4c0 [84567.084000] [] xfs_alloc_vextent+0x1eb/0x4b0 [84567.084000] [] xfs_bmap_btalloc+0x3bb/0x8f0 [84567.084000] [] xfs_bmap_alloc+0x21/0x40 [84567.084000] [] xfs_bmapi+0xdbf/0x1450 [84567.084000] [] xfs_iomap_write_allocate+0x2ba/0x520 [84567.084000] [] xfs_iomap+0x45b/0x470 [84567.084000] [] xfs_bmap+0x2c/0x40 [84567.084000] [] xfs_map_blocks+0x3c/0x80 [84567.084000] [] xfs_page_state_convert+0x2f3/0x670 [84567.084000] [] xfs_vm_writepage+0x5a/0xf0 [84567.084000] [] generic_writepages+0x226/0x360 [84567.084000] [] xfs_vm_writepages+0x24/0x60 [84567.084000] [] do_writepages+0x2c/0x50 [84567.084000] [] __sync_single_inode+0x59/0x1f0 [84567.084000] [] __writeback_single_inode+0x44/0x1d0 [84567.084000] [] sync_sb_inodes+0x1c9/0x2e0 [84567.084000] [] writeback_inodes+0xce/0xe0 [84567.084000] [] wb_kupdate+0x73/0xf0 [84567.084000] [] __pdflush+0xce/0x1a0 [84567.084000] [] pdflush+0x25/0x30 [84567.084000] [] kthread+0x94/0xd0 [84567.084000] [] kernel_thread_helper+0x7/0x1c [84567.084000] === [84567.087000] [] show_trace_log_lvl+0x1a/0x30 [84567.087000] [] do_IRQ: stack overflow: 328 [84567.087000] [] show_trace_log_lvl+0x1a/0x30 [84567.087000] [] show_trace+0x12/0x20 [84567.087000] [] dump_stack+0x15/0x20 [84567.087000] [] do_IRQ+0xd8/0xe0 [84567.087000] [] common_interrupt+0x2e/0x34 [84567.087000] [] printk+0x18/0x20 [84567.087000] [] print_trace_address+0x1d/0x30 [84567.087000] [] dump_trace+0x48/0xb0 [84567.087000] [] show_trace_log_lvl+0x1a/0x30 [84567.087000] [] show_trace+0x12/0x20 [84567.087000] [] dump_stack+0x15/0x20 [84567.087000] [] schedule+0x53a/0x680 [84567.087000] [] schedule_timeout+0x8a/0x90 [84567.087000] [] xlog_state_sync+0x21e/0x260 [84567.087000] [] _xfs_log_force+0x44/0x70 [84567.087000] [] xfs_alloc_search_busy+0xd2/0xe0 [84567.087000] [] xfs_alloc_get_freelist+0xe6/0x100 [84567.087000] [] xfs_alloc_split+0x1f/0x4c0 [84567.087000] [] xfs_alloc_insrec+0x35d/0x3b0 [84567.087000] [] xfs_alloc_insert+0x59/0xd0 [84567.087000] [] xfs_free_ag_extent+0x297/0x640 [84567.087000] [] xfs_alloc_fix_freelist+0x1d1/0x4c0 [84567.087000] [] xfs_alloc_vextent+0x1eb/0x4b0 [84567.087000] [] xfs_bmap_btalloc+0x3bb/0x8f0 [84567.087000] [] xfs_bmap_alloc+0x21/0x40 [84567.087000] [] xfs_bmapi+0xdbf/0x1450 [84567.087000] [] xfs_iomap_write_allocate+0x2ba/0x520 [84567.087000] [] xfs_iomap+0x45b/0x470 [84567.087000] [] xfs_bmap+0x2c/0x40 [84567.087000] [] xfs_map_blocks+0x3c/0x80 [84567.087000] [] xfs_page_state_convert+0x2f3/0x670 [84567.087000] [] xfs_vm_writepage+0x5a/0xf0 [84567.087000] [] generic_writepages+0x226/0x360 [84567.087000] [] xfs_vm_writepages+0x24/0x60 [84567.087000] [] do_writepages+0x2c/0x50 [84567.087000] [] __sync_single_inode+0x59/0x1f0 [84567.087000] [] __writeback_single_inode+0x44/0x1d0 [84567.087000] [] sync_sb_inodes+0x1c9/0x2e0 [84567.087000] [] writeback_inodes+0xce/0xe0 [84567.087000] [] wb_kupdate+0x73/0xf0 [84567.087000] [] __pdflush+0xce/0x1a0 [84567.087000] [] pdflush+0x25/0x30 [84567.087000] [] kthread+0x94/0xd0 [84567.087000] [] kernel_thread_helper+0x7/0x1c [84567.087000] BUG: unable to handle kernel paging request at virtual address 8034 [84567.087000] printing eip: [84567.087000] b0104e36 [84567.087000] *pde = [84567.087000] Oops: [#1] [84567.087000] PREEMPT [84567.087000] Modules linked in: drbd mt352 saa7134_dvb dvb_pll video_buf_dvb dvb_core [84567.087000] CPU:0 [84567.087000] EIP:0060:[]Not tainted VLI [84567.087000] EFLAGS: 00010046 (2.6.21-git #197) [84567.087000] EIP is at dump_trace+0x66/0xb0 [84567.087000] eax: ebx: b18f6fe0 ecx: b06323ec edx: b05afc71 [84567.087000] esi: 8000 edi: 8ffd ebp: b18f6138 esp: b18f6120 [84567.087000] ds: 007b
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, 07 May 2007 23:58:36 +0100 Simon Arlott <[EMAIL PROTECTED]> wrote: > > I've just got this under mainline too now > (0ec54aa8af5e6faa346aa55a1ad15ee6c25bb42d 2007-05-05 22:08:06): > > [84567.084000] BUG: scheduling while atomic: pdflush/0xeff84acf/186 > [84567.084000] INFO: lockdep is turned off. > [84567.084000] do_IRQ: stack overflow: 440 > [84567.084000] [] show_trace_log_lvl+0x1a/0x30 > [84567.084000] [] show_trace+0x12/0x20 > [84567.084000] [] dump_stack+0x15/0x20 > [84567.084000] [] do_IRQ+0xd8/0xe0 > [84567.084000] [] common_interrupt+0x2e/0x34 > [84567.084000] [] printk+0x18/0x20 > [84567.084000] [] debug_show_held_locks+0x23/0x30 > [84567.084000] [] schedule+0x52a/0x680 > [84567.084000] [] schedule_timeout+0x8a/0x90 > [84567.084000] [] xlog_state_sync+0x21e/0x260 > [84567.084000] [] _xfs_log_force+0x44/0x70 > [84567.084000] [] xfs_alloc_search_busy+0xd2/0xe0 > [84567.084000] [] xfs_alloc_get_freelist+0xe6/0x100 > [84567.084000] [] xfs_alloc_split+0x1f/0x4c0 > [84567.084000] [] xfs_alloc_insrec+0x35d/0x3b0 > [84567.084000] [] xfs_alloc_insert+0x59/0xd0 > [84567.084000] [] xfs_free_ag_extent+0x297/0x640 > [84567.084000] [] xfs_alloc_fix_freelist+0x1d1/0x4c0 > [84567.084000] [] xfs_alloc_vextent+0x1eb/0x4b0 > [84567.084000] [] xfs_bmap_btalloc+0x3bb/0x8f0 > [84567.084000] [] xfs_bmap_alloc+0x21/0x40 > [84567.084000] [] xfs_bmapi+0xdbf/0x1450 > [84567.084000] [] xfs_iomap_write_allocate+0x2ba/0x520 > [84567.084000] [] xfs_iomap+0x45b/0x470 > [84567.084000] [] xfs_bmap+0x2c/0x40 > [84567.084000] [] xfs_map_blocks+0x3c/0x80 > [84567.084000] [] xfs_page_state_convert+0x2f3/0x670 > [84567.084000] [] xfs_vm_writepage+0x5a/0xf0 > [84567.084000] [] generic_writepages+0x226/0x360 > [84567.084000] [] xfs_vm_writepages+0x24/0x60 > [84567.084000] [] do_writepages+0x2c/0x50 > [84567.084000] [] __sync_single_inode+0x59/0x1f0 > [84567.084000] [] __writeback_single_inode+0x44/0x1d0 > [84567.084000] [] sync_sb_inodes+0x1c9/0x2e0 > [84567.084000] [] writeback_inodes+0xce/0xe0 > [84567.084000] [] wb_kupdate+0x73/0xf0 > [84567.084000] [] __pdflush+0xce/0x1a0 > [84567.084000] [] pdflush+0x25/0x30 > [84567.084000] [] kthread+0x94/0xd0 > [84567.084000] [] kernel_thread_helper+0x7/0x1c > [84567.084000] === > [84567.087000] [] show_trace_log_lvl+0x1a/0x30 > [84567.087000] [] do_IRQ: stack overflow: 328 > [84567.087000] [] show_trace_log_lvl+0x1a/0x30 > [84567.087000] [] show_trace+0x12/0x20 > [84567.087000] [] dump_stack+0x15/0x20 > [84567.087000] [] do_IRQ+0xd8/0xe0 > [84567.087000] [] common_interrupt+0x2e/0x34 > [84567.087000] [] printk+0x18/0x20 > [84567.087000] [] print_trace_address+0x1d/0x30 > [84567.087000] [] dump_trace+0x48/0xb0 > [84567.087000] [] show_trace_log_lvl+0x1a/0x30 > [84567.087000] [] show_trace+0x12/0x20 > [84567.087000] [] dump_stack+0x15/0x20 > [84567.087000] [] schedule+0x53a/0x680 > [84567.087000] [] schedule_timeout+0x8a/0x90 > [84567.087000] [] xlog_state_sync+0x21e/0x260 > [84567.087000] [] _xfs_log_force+0x44/0x70 > [84567.087000] [] xfs_alloc_search_busy+0xd2/0xe0 > [84567.087000] [] xfs_alloc_get_freelist+0xe6/0x100 > [84567.087000] [] xfs_alloc_split+0x1f/0x4c0 > [84567.087000] [] xfs_alloc_insrec+0x35d/0x3b0 > [84567.087000] [] xfs_alloc_insert+0x59/0xd0 > [84567.087000] [] xfs_free_ag_extent+0x297/0x640 > [84567.087000] [] xfs_alloc_fix_freelist+0x1d1/0x4c0 > [84567.087000] [] xfs_alloc_vextent+0x1eb/0x4b0 > [84567.087000] [] xfs_bmap_btalloc+0x3bb/0x8f0 > [84567.087000] [] xfs_bmap_alloc+0x21/0x40 > [84567.087000] [] xfs_bmapi+0xdbf/0x1450 > [84567.087000] [] xfs_iomap_write_allocate+0x2ba/0x520 > [84567.087000] [] xfs_iomap+0x45b/0x470 > [84567.087000] [] xfs_bmap+0x2c/0x40 > [84567.087000] [] xfs_map_blocks+0x3c/0x80 > [84567.087000] [] xfs_page_state_convert+0x2f3/0x670 > [84567.087000] [] xfs_vm_writepage+0x5a/0xf0 > [84567.087000] [] generic_writepages+0x226/0x360 > [84567.087000] [] xfs_vm_writepages+0x24/0x60 > [84567.087000] [] do_writepages+0x2c/0x50 > [84567.087000] [] __sync_single_inode+0x59/0x1f0 > [84567.087000] [] __writeback_single_inode+0x44/0x1d0 > [84567.087000] [] sync_sb_inodes+0x1c9/0x2e0 > [84567.087000] [] writeback_inodes+0xce/0xe0 > [84567.087000] [] wb_kupdate+0x73/0xf0 > [84567.087000] [] __pdflush+0xce/0x1a0 > [84567.087000] [] pdflush+0x25/0x30 > [84567.087000] [] kthread+0x94/0xd0 > [84567.087000] [] kernel_thread_helper+0x7/0x1c > [84567.087000] BUG: unable to handle kernel paging request at virtual address > 8034 > [84567.087000] printing eip: > [84567.087000] b0104e36 > [84567.087000] *pde = > [84567.087000] Oops: [#1] > [84567.087000] PREEMPT > [84567.087000] Modules linked in: drbd mt352 saa7134_dvb dvb_pll > video_buf_dvb dvb_core > [84567.087000] CPU:0 > [84567.087000] EIP:0060:[]Not tainted VLI > [84567.087000] EFLAGS: 00010046 (2.6.21-git #197) > [84567.087000] EIP is at dump_trace+0x66/0xb0 >
sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On 06/05/07 21:54, Andrew Morton wrote: On Sun, 06 May 2007 21:36:32 +0100 Simon Arlott <[EMAIL PROTECTED]> wrote: On 05/05/07 09:49, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ Not sure exactly what's going on here, but it happened with a lock held on my (XFS) filesystem while compiling part of the kernel because I can't do anything with it now. [ 1128.122000] BUG: sleeping function called from invalid context at block/cfq-iosched.c:1895 [ 1128.122000] in_atomic():1, irqs_disabled():0 [ 1128.122000] INFO: lockdep is turned off. [ 1128.122000] BUG: unable to handle kernel paging request at virtual address 8b0c4034 [ 1128.122000] printing eip: [ 1128.122000] b0104e36 [ 1128.123000] *pde = [ 1128.123000] Oops: [#1] [ 1128.123000] PREEMPT [ 1128.123000] Modules linked in: drbd mt352 saa7134_dvb dvb_pll video_buf_dvb dvb_core [ 1128.123000] CPU:0 [ 1128.123000] EIP:0060:[]Not tainted VLI [ 1128.123000] EFLAGS: 00010246 (2.6.21-git #195) [ 1128.123000] EIP is at dump_trace+0x66/0xb0 [ 1128.123000] eax: ebx: b18f6fd0 ecx: b06323ec edx: b05afc71 [ 1128.123000] esi: 8b0c4000 edi: 8b0c4ffd ebp: b18f6fd0 esp: b18f6fb8 [ 1128.123000] ds: 007b es: 007b fs: gs: ss: 0068 [ 1128.123000] Process pdflush (pid: 186, ti=b18f6000 task=eff88b10 task.ti=b18f7000) [ 1128.123000] Stack: b000205d fffc b05b9937 efd1adb4 0010 b18f6ff0 b0104f3a [ 1128.123000]b06323ec b05b9937 b05d33e6 efd1adb4 b05d33e6 b18f7000 b0104f62 [ 1128.123000]b05b9937 b18f700c [ 1128.123000] Call Trace: [ 1128.123000] [] show_trace_log_lvl+0x1a/0x30 [ 1128.123000] [] show_stack_log_lvl+0x8b/0xb0 [ 1128.123000] [] show_registers+0x1c3/0x320 [ 1128.123000] [] die+0x105/0x230 [ 1128.123000] [] do_page_fault+0x2cf/0x5b0 [ 1128.123000] [] error_code+0x6a/0x70 [ 1128.123000] [] show_trace_log_lvl+0x1a/0x30 [ 1128.123000] [] show_trace+0x12/0x20 [ 1128.123000] === [ 1128.123000] Code: 18 8b 4d 08 8b 45 0c 8b 53 04 ff 51 08 8b 03 39 d8 76 06 89 c3 39 f3 77 e4 8b 4d 08 ba 71 fc 5a b0 8b 45 0c ff 51 0c 85 c0 78 38 <8b> 76 34 85 f6 74 31 8d 76 00 e8 bb d7 00 00 eb b3 89 eb eb af [ 1128.123000] EIP: [] dump_trace+0x66/0xb0 SS:ESP 0068:b18f6fb8 Mess. Someone incorrectly called the IO scheduler under a spinlock (or similar), CFQ tried to do a dump_stack(), but the dump_stack() code exploded. Usually this happens when the x86_64 tree contains stacktrace improvements, but the unwinder (at least) wasn't present in -mm1. How come those addresses are 0xb0.., btw? You're running a different vm split? I've just got this under mainline too now (0ec54aa8af5e6faa346aa55a1ad15ee6c25bb42d 2007-05-05 22:08:06): [84567.084000] BUG: scheduling while atomic: pdflush/0xeff84acf/186 [84567.084000] INFO: lockdep is turned off. [84567.084000] do_IRQ: stack overflow: 440 [84567.084000] [] show_trace_log_lvl+0x1a/0x30 [84567.084000] [] show_trace+0x12/0x20 [84567.084000] [] dump_stack+0x15/0x20 [84567.084000] [] do_IRQ+0xd8/0xe0 [84567.084000] [] common_interrupt+0x2e/0x34 [84567.084000] [] printk+0x18/0x20 [84567.084000] [] debug_show_held_locks+0x23/0x30 [84567.084000] [] schedule+0x52a/0x680 [84567.084000] [] schedule_timeout+0x8a/0x90 [84567.084000] [] xlog_state_sync+0x21e/0x260 [84567.084000] [] _xfs_log_force+0x44/0x70 [84567.084000] [] xfs_alloc_search_busy+0xd2/0xe0 [84567.084000] [] xfs_alloc_get_freelist+0xe6/0x100 [84567.084000] [] xfs_alloc_split+0x1f/0x4c0 [84567.084000] [] xfs_alloc_insrec+0x35d/0x3b0 [84567.084000] [] xfs_alloc_insert+0x59/0xd0 [84567.084000] [] xfs_free_ag_extent+0x297/0x640 [84567.084000] [] xfs_alloc_fix_freelist+0x1d1/0x4c0 [84567.084000] [] xfs_alloc_vextent+0x1eb/0x4b0 [84567.084000] [] xfs_bmap_btalloc+0x3bb/0x8f0 [84567.084000] [] xfs_bmap_alloc+0x21/0x40 [84567.084000] [] xfs_bmapi+0xdbf/0x1450 [84567.084000] [] xfs_iomap_write_allocate+0x2ba/0x520 [84567.084000] [] xfs_iomap+0x45b/0x470 [84567.084000] [] xfs_bmap+0x2c/0x40 [84567.084000] [] xfs_map_blocks+0x3c/0x80 [84567.084000] [] xfs_page_state_convert+0x2f3/0x670 [84567.084000] [] xfs_vm_writepage+0x5a/0xf0 [84567.084000] [] generic_writepages+0x226/0x360 [84567.084000] [] xfs_vm_writepages+0x24/0x60 [84567.084000] [] do_writepages+0x2c/0x50 [84567.084000] [] __sync_single_inode+0x59/0x1f0 [84567.084000] [] __writeback_single_inode+0x44/0x1d0 [84567.084000] [] sync_sb_inodes+0x1c9/0x2e0 [84567.084000] [] writeback_inodes+0xce/0xe0 [84567.084000] [] wb_kupdate+0x73/0xf0 [84567.084000] [] __pdflush+0xce/0x1a0 [84567.084000] [] pdflush+0x25/0x30 [84567.084000] [] kthread+0x94/0xd0 [84567.084000] [] kernel_thread_helper+0x7/0x1c [84567.084000] === [84567.087000] [] show_trace_log_lvl+0x1a/0x30 [84567.087000] [] do_IRQ: stack overflow: 328 [84567.087000] [] show_trace_log_lvl+0x1a/0x30 [84567.087000] []
sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On 06/05/07 21:54, Andrew Morton wrote: On Sun, 06 May 2007 21:36:32 +0100 Simon Arlott [EMAIL PROTECTED] wrote: On 05/05/07 09:49, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ Not sure exactly what's going on here, but it happened with a lock held on my (XFS) filesystem while compiling part of the kernel because I can't do anything with it now. [ 1128.122000] BUG: sleeping function called from invalid context at block/cfq-iosched.c:1895 [ 1128.122000] in_atomic():1, irqs_disabled():0 [ 1128.122000] INFO: lockdep is turned off. [ 1128.122000] BUG: unable to handle kernel paging request at virtual address 8b0c4034 [ 1128.122000] printing eip: [ 1128.122000] b0104e36 [ 1128.123000] *pde = [ 1128.123000] Oops: [#1] [ 1128.123000] PREEMPT [ 1128.123000] Modules linked in: drbd mt352 saa7134_dvb dvb_pll video_buf_dvb dvb_core [ 1128.123000] CPU:0 [ 1128.123000] EIP:0060:[b0104e36]Not tainted VLI [ 1128.123000] EFLAGS: 00010246 (2.6.21-git #195) [ 1128.123000] EIP is at dump_trace+0x66/0xb0 [ 1128.123000] eax: ebx: b18f6fd0 ecx: b06323ec edx: b05afc71 [ 1128.123000] esi: 8b0c4000 edi: 8b0c4ffd ebp: b18f6fd0 esp: b18f6fb8 [ 1128.123000] ds: 007b es: 007b fs: gs: ss: 0068 [ 1128.123000] Process pdflush (pid: 186, ti=b18f6000 task=eff88b10 task.ti=b18f7000) [ 1128.123000] Stack: b000205d fffc b05b9937 efd1adb4 0010 b18f6ff0 b0104f3a [ 1128.123000]b06323ec b05b9937 b05d33e6 efd1adb4 b05d33e6 b18f7000 b0104f62 [ 1128.123000]b05b9937 b18f700c [ 1128.123000] Call Trace: [ 1128.123000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [ 1128.123000] [b0104ffb] show_stack_log_lvl+0x8b/0xb0 [ 1128.123000] [b0105243] show_registers+0x1c3/0x320 [ 1128.123000] [b0105525] die+0x105/0x230 [ 1128.123000] [b011703f] do_page_fault+0x2cf/0x5b0 [ 1128.123000] [b04eae3a] error_code+0x6a/0x70 [ 1128.123000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [ 1128.123000] [b0104f62] show_trace+0x12/0x20 [ 1128.123000] === [ 1128.123000] Code: 18 8b 4d 08 8b 45 0c 8b 53 04 ff 51 08 8b 03 39 d8 76 06 89 c3 39 f3 77 e4 8b 4d 08 ba 71 fc 5a b0 8b 45 0c ff 51 0c 85 c0 78 38 8b 76 34 85 f6 74 31 8d 76 00 e8 bb d7 00 00 eb b3 89 eb eb af [ 1128.123000] EIP: [b0104e36] dump_trace+0x66/0xb0 SS:ESP 0068:b18f6fb8 Mess. Someone incorrectly called the IO scheduler under a spinlock (or similar), CFQ tried to do a dump_stack(), but the dump_stack() code exploded. Usually this happens when the x86_64 tree contains stacktrace improvements, but the unwinder (at least) wasn't present in -mm1. How come those addresses are 0xb0.., btw? You're running a different vm split? I've just got this under mainline too now (0ec54aa8af5e6faa346aa55a1ad15ee6c25bb42d 2007-05-05 22:08:06): [84567.084000] BUG: scheduling while atomic: pdflush/0xeff84acf/186 [84567.084000] INFO: lockdep is turned off. [84567.084000] do_IRQ: stack overflow: 440 [84567.084000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.084000] [b0104f62] show_trace+0x12/0x20 [84567.084000] [b0105075] dump_stack+0x15/0x20 [84567.084000] [b01069a8] do_IRQ+0xd8/0xe0 [84567.084000] [b0104bd6] common_interrupt+0x2e/0x34 [84567.084000] [b0120a28] printk+0x18/0x20 [84567.084000] [b0140b33] debug_show_held_locks+0x23/0x30 [84567.084000] [b04e7fea] schedule+0x52a/0x680 [84567.084000] [b04e8a0a] schedule_timeout+0x8a/0x90 [84567.084000] [b026c61e] xlog_state_sync+0x21e/0x260 [84567.084000] [b0269274] _xfs_log_force+0x44/0x70 [84567.084000] [b022dd22] xfs_alloc_search_busy+0xd2/0xe0 [84567.084000] [b022d1e6] xfs_alloc_get_freelist+0xe6/0x100 [84567.084000] [b022fb7f] xfs_alloc_split+0x1f/0x4c0 [84567.084000] [b022ec3d] xfs_alloc_insrec+0x35d/0x3b0 [84567.084000] [b02304f9] xfs_alloc_insert+0x59/0xd0 [84567.084000] [b022c847] xfs_free_ag_extent+0x297/0x640 [84567.084000] [b022ce11] xfs_alloc_fix_freelist+0x1d1/0x4c0 [84567.084000] [b022d73b] xfs_alloc_vextent+0x1eb/0x4b0 [84567.084000] [b023d4bb] xfs_bmap_btalloc+0x3bb/0x8f0 [84567.084000] [b023da11] xfs_bmap_alloc+0x21/0x40 [84567.084000] [b02411bf] xfs_bmapi+0xdbf/0x1450 [84567.084000] [b0266b4a] xfs_iomap_write_allocate+0x2ba/0x520 [84567.084000] [b026587b] xfs_iomap+0x45b/0x470 [84567.084000] [b028d85c] xfs_bmap+0x2c/0x40 [84567.084000] [b0284a0c] xfs_map_blocks+0x3c/0x80 [84567.084000] [b0285953] xfs_page_state_convert+0x2f3/0x670 [84567.084000] [b0285d2a] xfs_vm_writepage+0x5a/0xf0 [84567.084000] [b01539a6] generic_writepages+0x226/0x360 [84567.084000] [b0285de4] xfs_vm_writepages+0x24/0x60 [84567.084000] [b0153b0c] do_writepages+0x2c/0x50 [84567.084000] [b01887d9] __sync_single_inode+0x59/0x1f0 [84567.084000] [b01889b4] __writeback_single_inode+0x44/0x1d0 [84567.084000] [b0188d09] sync_sb_inodes+0x1c9/0x2e0 [84567.084000] [b0188eee] writeback_inodes+0xce/0xe0 [84567.084000] [b01535c3] wb_kupdate+0x73/0xf0 [84567.084000]
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, 07 May 2007 23:58:36 +0100 Simon Arlott [EMAIL PROTECTED] wrote: I've just got this under mainline too now (0ec54aa8af5e6faa346aa55a1ad15ee6c25bb42d 2007-05-05 22:08:06): [84567.084000] BUG: scheduling while atomic: pdflush/0xeff84acf/186 [84567.084000] INFO: lockdep is turned off. [84567.084000] do_IRQ: stack overflow: 440 [84567.084000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.084000] [b0104f62] show_trace+0x12/0x20 [84567.084000] [b0105075] dump_stack+0x15/0x20 [84567.084000] [b01069a8] do_IRQ+0xd8/0xe0 [84567.084000] [b0104bd6] common_interrupt+0x2e/0x34 [84567.084000] [b0120a28] printk+0x18/0x20 [84567.084000] [b0140b33] debug_show_held_locks+0x23/0x30 [84567.084000] [b04e7fea] schedule+0x52a/0x680 [84567.084000] [b04e8a0a] schedule_timeout+0x8a/0x90 [84567.084000] [b026c61e] xlog_state_sync+0x21e/0x260 [84567.084000] [b0269274] _xfs_log_force+0x44/0x70 [84567.084000] [b022dd22] xfs_alloc_search_busy+0xd2/0xe0 [84567.084000] [b022d1e6] xfs_alloc_get_freelist+0xe6/0x100 [84567.084000] [b022fb7f] xfs_alloc_split+0x1f/0x4c0 [84567.084000] [b022ec3d] xfs_alloc_insrec+0x35d/0x3b0 [84567.084000] [b02304f9] xfs_alloc_insert+0x59/0xd0 [84567.084000] [b022c847] xfs_free_ag_extent+0x297/0x640 [84567.084000] [b022ce11] xfs_alloc_fix_freelist+0x1d1/0x4c0 [84567.084000] [b022d73b] xfs_alloc_vextent+0x1eb/0x4b0 [84567.084000] [b023d4bb] xfs_bmap_btalloc+0x3bb/0x8f0 [84567.084000] [b023da11] xfs_bmap_alloc+0x21/0x40 [84567.084000] [b02411bf] xfs_bmapi+0xdbf/0x1450 [84567.084000] [b0266b4a] xfs_iomap_write_allocate+0x2ba/0x520 [84567.084000] [b026587b] xfs_iomap+0x45b/0x470 [84567.084000] [b028d85c] xfs_bmap+0x2c/0x40 [84567.084000] [b0284a0c] xfs_map_blocks+0x3c/0x80 [84567.084000] [b0285953] xfs_page_state_convert+0x2f3/0x670 [84567.084000] [b0285d2a] xfs_vm_writepage+0x5a/0xf0 [84567.084000] [b01539a6] generic_writepages+0x226/0x360 [84567.084000] [b0285de4] xfs_vm_writepages+0x24/0x60 [84567.084000] [b0153b0c] do_writepages+0x2c/0x50 [84567.084000] [b01887d9] __sync_single_inode+0x59/0x1f0 [84567.084000] [b01889b4] __writeback_single_inode+0x44/0x1d0 [84567.084000] [b0188d09] sync_sb_inodes+0x1c9/0x2e0 [84567.084000] [b0188eee] writeback_inodes+0xce/0xe0 [84567.084000] [b01535c3] wb_kupdate+0x73/0xf0 [84567.084000] [b015419e] __pdflush+0xce/0x1a0 [84567.084000] [b0154295] pdflush+0x25/0x30 [84567.084000] [b01342b4] kthread+0x94/0xd0 [84567.084000] [b0104d7b] kernel_thread_helper+0x7/0x1c [84567.084000] === [84567.087000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.087000] [b0104f62] do_IRQ: stack overflow: 328 [84567.087000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.087000] [b0104f62] show_trace+0x12/0x20 [84567.087000] [b0105075] dump_stack+0x15/0x20 [84567.087000] [b01069a8] do_IRQ+0xd8/0xe0 [84567.087000] [b0104bd6] common_interrupt+0x2e/0x34 [84567.087000] [b0120a28] printk+0x18/0x20 [84567.087000] [b0104f0d] print_trace_address+0x1d/0x30 [84567.087000] [b0104e18] dump_trace+0x48/0xb0 [84567.087000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.087000] [b0104f62] show_trace+0x12/0x20 [84567.087000] [b0105075] dump_stack+0x15/0x20 [84567.087000] [b04e7ffa] schedule+0x53a/0x680 [84567.087000] [b04e8a0a] schedule_timeout+0x8a/0x90 [84567.087000] [b026c61e] xlog_state_sync+0x21e/0x260 [84567.087000] [b0269274] _xfs_log_force+0x44/0x70 [84567.087000] [b022dd22] xfs_alloc_search_busy+0xd2/0xe0 [84567.087000] [b022d1e6] xfs_alloc_get_freelist+0xe6/0x100 [84567.087000] [b022fb7f] xfs_alloc_split+0x1f/0x4c0 [84567.087000] [b022ec3d] xfs_alloc_insrec+0x35d/0x3b0 [84567.087000] [b02304f9] xfs_alloc_insert+0x59/0xd0 [84567.087000] [b022c847] xfs_free_ag_extent+0x297/0x640 [84567.087000] [b022ce11] xfs_alloc_fix_freelist+0x1d1/0x4c0 [84567.087000] [b022d73b] xfs_alloc_vextent+0x1eb/0x4b0 [84567.087000] [b023d4bb] xfs_bmap_btalloc+0x3bb/0x8f0 [84567.087000] [b023da11] xfs_bmap_alloc+0x21/0x40 [84567.087000] [b02411bf] xfs_bmapi+0xdbf/0x1450 [84567.087000] [b0266b4a] xfs_iomap_write_allocate+0x2ba/0x520 [84567.087000] [b026587b] xfs_iomap+0x45b/0x470 [84567.087000] [b028d85c] xfs_bmap+0x2c/0x40 [84567.087000] [b0284a0c] xfs_map_blocks+0x3c/0x80 [84567.087000] [b0285953] xfs_page_state_convert+0x2f3/0x670 [84567.087000] [b0285d2a] xfs_vm_writepage+0x5a/0xf0 [84567.087000] [b01539a6] generic_writepages+0x226/0x360 [84567.087000] [b0285de4] xfs_vm_writepages+0x24/0x60 [84567.087000] [b0153b0c] do_writepages+0x2c/0x50 [84567.087000] [b01887d9] __sync_single_inode+0x59/0x1f0 [84567.087000] [b01889b4] __writeback_single_inode+0x44/0x1d0 [84567.087000] [b0188d09] sync_sb_inodes+0x1c9/0x2e0 [84567.087000] [b0188eee] writeback_inodes+0xce/0xe0 [84567.087000] [b01535c3] wb_kupdate+0x73/0xf0 [84567.087000] [b015419e] __pdflush+0xce/0x1a0 [84567.087000] [b0154295] pdflush+0x25/0x30 [84567.087000] [b01342b4]
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On 08/05/07 00:23, Andrew Morton wrote: On Mon, 07 May 2007 23:58:36 +0100 Simon Arlott [EMAIL PROTECTED] wrote: I've just got this under mainline too now (0ec54aa8af5e6faa346aa55a1ad15ee6c25bb42d 2007-05-05 22:08:06): [84567.084000] BUG: scheduling while atomic: pdflush/0xeff84acf/186 [84567.084000] INFO: lockdep is turned off. [84567.084000] do_IRQ: stack overflow: 440 [84567.084000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.084000] [b0104f62] show_trace+0x12/0x20 [84567.084000] [b0105075] dump_stack+0x15/0x20 [84567.084000] [b01069a8] do_IRQ+0xd8/0xe0 [84567.084000] [b0104bd6] common_interrupt+0x2e/0x34 [84567.084000] [b0120a28] printk+0x18/0x20 [84567.084000] [b0140b33] debug_show_held_locks+0x23/0x30 [84567.084000] [b04e7fea] schedule+0x52a/0x680 [84567.084000] [b04e8a0a] schedule_timeout+0x8a/0x90 [84567.084000] [b026c61e] xlog_state_sync+0x21e/0x260 [84567.084000] [b0269274] _xfs_log_force+0x44/0x70 [84567.084000] [b022dd22] xfs_alloc_search_busy+0xd2/0xe0 [84567.084000] [b022d1e6] xfs_alloc_get_freelist+0xe6/0x100 [84567.084000] [b022fb7f] xfs_alloc_split+0x1f/0x4c0 [84567.084000] [b022ec3d] xfs_alloc_insrec+0x35d/0x3b0 [84567.084000] [b02304f9] xfs_alloc_insert+0x59/0xd0 [84567.084000] [b022c847] xfs_free_ag_extent+0x297/0x640 [84567.084000] [b022ce11] xfs_alloc_fix_freelist+0x1d1/0x4c0 [84567.084000] [b022d73b] xfs_alloc_vextent+0x1eb/0x4b0 [84567.084000] [b023d4bb] xfs_bmap_btalloc+0x3bb/0x8f0 [84567.084000] [b023da11] xfs_bmap_alloc+0x21/0x40 [84567.084000] [b02411bf] xfs_bmapi+0xdbf/0x1450 [84567.084000] [b0266b4a] xfs_iomap_write_allocate+0x2ba/0x520 [84567.084000] [b026587b] xfs_iomap+0x45b/0x470 [84567.084000] [b028d85c] xfs_bmap+0x2c/0x40 [84567.084000] [b0284a0c] xfs_map_blocks+0x3c/0x80 [84567.084000] [b0285953] xfs_page_state_convert+0x2f3/0x670 [84567.084000] [b0285d2a] xfs_vm_writepage+0x5a/0xf0 [84567.084000] [b01539a6] generic_writepages+0x226/0x360 [84567.084000] [b0285de4] xfs_vm_writepages+0x24/0x60 [84567.084000] [b0153b0c] do_writepages+0x2c/0x50 [84567.084000] [b01887d9] __sync_single_inode+0x59/0x1f0 [84567.084000] [b01889b4] __writeback_single_inode+0x44/0x1d0 [84567.084000] [b0188d09] sync_sb_inodes+0x1c9/0x2e0 [84567.084000] [b0188eee] writeback_inodes+0xce/0xe0 [84567.084000] [b01535c3] wb_kupdate+0x73/0xf0 [84567.084000] [b015419e] __pdflush+0xce/0x1a0 [84567.084000] [b0154295] pdflush+0x25/0x30 [84567.084000] [b01342b4] kthread+0x94/0xd0 [84567.084000] [b0104d7b] kernel_thread_helper+0x7/0x1c [84567.084000] === [84567.087000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.087000] [b0104f62] do_IRQ: stack overflow: 328 [84567.087000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.087000] [b0104f62] show_trace+0x12/0x20 [84567.087000] [b0105075] dump_stack+0x15/0x20 [84567.087000] [b01069a8] do_IRQ+0xd8/0xe0 [84567.087000] [b0104bd6] common_interrupt+0x2e/0x34 [84567.087000] [b0120a28] printk+0x18/0x20 [84567.087000] [b0104f0d] print_trace_address+0x1d/0x30 [84567.087000] [b0104e18] dump_trace+0x48/0xb0 [84567.087000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.087000] [b0104f62] show_trace+0x12/0x20 [84567.087000] [b0105075] dump_stack+0x15/0x20 [84567.087000] [b04e7ffa] schedule+0x53a/0x680 [84567.087000] [b04e8a0a] schedule_timeout+0x8a/0x90 [84567.087000] [b026c61e] xlog_state_sync+0x21e/0x260 [84567.087000] [b0269274] _xfs_log_force+0x44/0x70 [84567.087000] [b022dd22] xfs_alloc_search_busy+0xd2/0xe0 [84567.087000] [b022d1e6] xfs_alloc_get_freelist+0xe6/0x100 [84567.087000] [b022fb7f] xfs_alloc_split+0x1f/0x4c0 [84567.087000] [b022ec3d] xfs_alloc_insrec+0x35d/0x3b0 [84567.087000] [b02304f9] xfs_alloc_insert+0x59/0xd0 [84567.087000] [b022c847] xfs_free_ag_extent+0x297/0x640 [84567.087000] [b022ce11] xfs_alloc_fix_freelist+0x1d1/0x4c0 [84567.087000] [b022d73b] xfs_alloc_vextent+0x1eb/0x4b0 [84567.087000] [b023d4bb] xfs_bmap_btalloc+0x3bb/0x8f0 [84567.087000] [b023da11] xfs_bmap_alloc+0x21/0x40 [84567.087000] [b02411bf] xfs_bmapi+0xdbf/0x1450 [84567.087000] [b0266b4a] xfs_iomap_write_allocate+0x2ba/0x520 [84567.087000] [b026587b] xfs_iomap+0x45b/0x470 [84567.087000] [b028d85c] xfs_bmap+0x2c/0x40 [84567.087000] [b0284a0c] xfs_map_blocks+0x3c/0x80 [84567.087000] [b0285953] xfs_page_state_convert+0x2f3/0x670 [84567.087000] [b0285d2a] xfs_vm_writepage+0x5a/0xf0 [84567.087000] [b01539a6] generic_writepages+0x226/0x360 [84567.087000] [b0285de4] xfs_vm_writepages+0x24/0x60 [84567.087000] [b0153b0c] do_writepages+0x2c/0x50 [84567.087000] [b01887d9] __sync_single_inode+0x59/0x1f0 [84567.087000] [b01889b4] __writeback_single_inode+0x44/0x1d0 [84567.087000] [b0188d09] sync_sb_inodes+0x1c9/0x2e0 [84567.087000] [b0188eee] writeback_inodes+0xce/0xe0 [84567.087000] [b01535c3] wb_kupdate+0x73/0xf0 [84567.087000] [b015419e] __pdflush+0xce/0x1a0 [84567.087000] [b0154295] pdflush+0x25/0x30 [84567.087000] [b01342b4] kthread+0x94/0xd0 [84567.087000] [b0104d7b]
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Tue, 08 May 2007 00:30:31 +0100 Simon Arlott [EMAIL PROTECTED] wrote: On 08/05/07 00:23, Andrew Morton wrote: On Mon, 07 May 2007 23:58:36 +0100 Simon Arlott [EMAIL PROTECTED] wrote: I've just got this under mainline too now (0ec54aa8af5e6faa346aa55a1ad15ee6c25bb42d 2007-05-05 22:08:06): [84567.084000] BUG: scheduling while atomic: pdflush/0xeff84acf/186 [84567.084000] INFO: lockdep is turned off. [84567.084000] do_IRQ: stack overflow: 440 [84567.084000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.084000] [b0104f62] show_trace+0x12/0x20 [84567.084000] [b0105075] dump_stack+0x15/0x20 [84567.084000] [b01069a8] do_IRQ+0xd8/0xe0 [84567.084000] [b0104bd6] common_interrupt+0x2e/0x34 [84567.084000] [b0120a28] printk+0x18/0x20 [84567.084000] [b0140b33] debug_show_held_locks+0x23/0x30 [84567.084000] [b04e7fea] schedule+0x52a/0x680 [84567.084000] [b04e8a0a] schedule_timeout+0x8a/0x90 [84567.084000] [b026c61e] xlog_state_sync+0x21e/0x260 [84567.084000] [b0269274] _xfs_log_force+0x44/0x70 [84567.084000] [b022dd22] xfs_alloc_search_busy+0xd2/0xe0 [84567.084000] [b022d1e6] xfs_alloc_get_freelist+0xe6/0x100 [84567.084000] [b022fb7f] xfs_alloc_split+0x1f/0x4c0 [84567.084000] [b022ec3d] xfs_alloc_insrec+0x35d/0x3b0 [84567.084000] [b02304f9] xfs_alloc_insert+0x59/0xd0 [84567.084000] [b022c847] xfs_free_ag_extent+0x297/0x640 [84567.084000] [b022ce11] xfs_alloc_fix_freelist+0x1d1/0x4c0 [84567.084000] [b022d73b] xfs_alloc_vextent+0x1eb/0x4b0 [84567.084000] [b023d4bb] xfs_bmap_btalloc+0x3bb/0x8f0 [84567.084000] [b023da11] xfs_bmap_alloc+0x21/0x40 [84567.084000] [b02411bf] xfs_bmapi+0xdbf/0x1450 [84567.084000] [b0266b4a] xfs_iomap_write_allocate+0x2ba/0x520 [84567.084000] [b026587b] xfs_iomap+0x45b/0x470 [84567.084000] [b028d85c] xfs_bmap+0x2c/0x40 [84567.084000] [b0284a0c] xfs_map_blocks+0x3c/0x80 [84567.084000] [b0285953] xfs_page_state_convert+0x2f3/0x670 [84567.084000] [b0285d2a] xfs_vm_writepage+0x5a/0xf0 [84567.084000] [b01539a6] generic_writepages+0x226/0x360 [84567.084000] [b0285de4] xfs_vm_writepages+0x24/0x60 [84567.084000] [b0153b0c] do_writepages+0x2c/0x50 [84567.084000] [b01887d9] __sync_single_inode+0x59/0x1f0 [84567.084000] [b01889b4] __writeback_single_inode+0x44/0x1d0 [84567.084000] [b0188d09] sync_sb_inodes+0x1c9/0x2e0 [84567.084000] [b0188eee] writeback_inodes+0xce/0xe0 [84567.084000] [b01535c3] wb_kupdate+0x73/0xf0 [84567.084000] [b015419e] __pdflush+0xce/0x1a0 [84567.084000] [b0154295] pdflush+0x25/0x30 [84567.084000] [b01342b4] kthread+0x94/0xd0 [84567.084000] [b0104d7b] kernel_thread_helper+0x7/0x1c [84567.084000] === [84567.087000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.087000] [b0104f62] do_IRQ: stack overflow: 328 [84567.087000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.087000] [b0104f62] show_trace+0x12/0x20 [84567.087000] [b0105075] dump_stack+0x15/0x20 [84567.087000] [b01069a8] do_IRQ+0xd8/0xe0 [84567.087000] [b0104bd6] common_interrupt+0x2e/0x34 [84567.087000] [b0120a28] printk+0x18/0x20 [84567.087000] [b0104f0d] print_trace_address+0x1d/0x30 [84567.087000] [b0104e18] dump_trace+0x48/0xb0 [84567.087000] [b0104f3a] show_trace_log_lvl+0x1a/0x30 [84567.087000] [b0104f62] show_trace+0x12/0x20 [84567.087000] [b0105075] dump_stack+0x15/0x20 [84567.087000] [b04e7ffa] schedule+0x53a/0x680 [84567.087000] [b04e8a0a] schedule_timeout+0x8a/0x90 [84567.087000] [b026c61e] xlog_state_sync+0x21e/0x260 [84567.087000] [b0269274] _xfs_log_force+0x44/0x70 [84567.087000] [b022dd22] xfs_alloc_search_busy+0xd2/0xe0 [84567.087000] [b022d1e6] xfs_alloc_get_freelist+0xe6/0x100 [84567.087000] [b022fb7f] xfs_alloc_split+0x1f/0x4c0 [84567.087000] [b022ec3d] xfs_alloc_insrec+0x35d/0x3b0 [84567.087000] [b02304f9] xfs_alloc_insert+0x59/0xd0 [84567.087000] [b022c847] xfs_free_ag_extent+0x297/0x640 [84567.087000] [b022ce11] xfs_alloc_fix_freelist+0x1d1/0x4c0 [84567.087000] [b022d73b] xfs_alloc_vextent+0x1eb/0x4b0 [84567.087000] [b023d4bb] xfs_bmap_btalloc+0x3bb/0x8f0 [84567.087000] [b023da11] xfs_bmap_alloc+0x21/0x40 [84567.087000] [b02411bf] xfs_bmapi+0xdbf/0x1450 [84567.087000] [b0266b4a] xfs_iomap_write_allocate+0x2ba/0x520 [84567.087000] [b026587b] xfs_iomap+0x45b/0x470 [84567.087000] [b028d85c] xfs_bmap+0x2c/0x40 [84567.087000] [b0284a0c] xfs_map_blocks+0x3c/0x80 [84567.087000] [b0285953] xfs_page_state_convert+0x2f3/0x670 [84567.087000] [b0285d2a] xfs_vm_writepage+0x5a/0xf0 [84567.087000] [b01539a6] generic_writepages+0x226/0x360 [84567.087000] [b0285de4] xfs_vm_writepages+0x24/0x60 [84567.087000] [b0153b0c] do_writepages+0x2c/0x50 [84567.087000] [b01887d9] __sync_single_inode+0x59/0x1f0 [84567.087000] [b01889b4] __writeback_single_inode+0x44/0x1d0 [84567.087000] [b0188d09] sync_sb_inodes+0x1c9/0x2e0 [84567.087000]
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
Andrew Morton wrote: Please enable 8k stacks before doing any other debugging things, see if that fixes it. I've found that XFS+lvm+4k stacks is completely unusable with current kernels. I get hangs/oopes after ~10mins of work. I'm using wli's 8k stack + irq stack patches with good success though. J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Andrew Morton wrote: Please enable 8k stacks before doing any other debugging things, see if that fixes it. I've found that XFS+lvm+4k stacks is completely unusable with current kernels. I get hangs/oopes after ~10mins of work. Sounds like this is new behaviour? I wonder why. Same compiler version? I'm using wli's 8k stack + irq stack patches with good success though. wlis are handy. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: I'm using wli's 8k stack + irq stack patches with good success though. On Mon, May 07, 2007 at 10:24:09PM -0700, Andrew Morton wrote: wlis are handy. I think Andi's handling the mergework on those patches, but I'll check in to see if I should rediff vs. -mm or what if you want them. Andi, what's the verdict on those stack patches? -- wli - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
Andrew Morton wrote: On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: I've found that XFS+lvm+4k stacks is completely unusable with current kernels. I get hangs/oopes after ~10mins of work. Sounds like this is new behaviour? I wonder why. Same compiler version? I've only recently started using xfs, so I couldn't say if its new behaviour. I did notice that it took a week or so for problems to set in; my theory is that as the filesystem got a bit aged, its datastructures got a bit more complex, and cause the kernel code to use more stack. But that's just a guess. J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, 7 May 2007 22:31:32 -0700 William Lee Irwin III [EMAIL PROTECTED] wrote: On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: I'm using wli's 8k stack + irq stack patches with good success though. On Mon, May 07, 2007 at 10:24:09PM -0700, Andrew Morton wrote: wlis are handy. I think Andi's handling the mergework on those patches, but I'll check in to see if I should rediff vs. -mm or what if you want them. Andi, what's the verdict on those stack patches? Whoa. The verdict is usually don't use so much stack. Do we know what has gone wrong here? Last week Jens said he was picking up the ancient md-dm-reduce-stack-usage-with-stacked-block-devices.patch, but he doesn't seem to have done so yet. XFS is frequently implicated. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
