* next BUG: using smp_processor_id() in preemptible
@ 2011-12-05 23:51 Hugh Dickins
2011-12-22 12:07 ` Hugh Dickins
0 siblings, 1 reply; 7+ messages in thread
From: Hugh Dickins @ 2011-12-05 23:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
Dec 4 20:03:19 thorn kernel: Call Trace:
Dec 4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
Dec 4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
Dec 4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
Dec 4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
Dec 4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed
from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
in decrementer_check_overflow(): I've no idea whether it's safe
just to use get_cpu_var then put_cpu_var there instead,
but no hurry, I can survive with DEBUG_PREEMPT off.
Hugh
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: next BUG: using smp_processor_id() in preemptible
2011-12-05 23:51 next BUG: using smp_processor_id() in preemptible Hugh Dickins
@ 2011-12-22 12:07 ` Hugh Dickins
2011-12-22 21:17 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 7+ messages in thread
From: Hugh Dickins @ 2011-12-22 12:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
On Mon, 5 Dec 2011, Hugh Dickins wrote:
> 3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
>
> Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
> Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
> Dec 4 20:03:19 thorn kernel: Call Trace:
> Dec 4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
> Dec 4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
> Dec 4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
> Dec 4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
> Dec 4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed
>
> from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
> in decrementer_check_overflow(): I've no idea whether it's safe
> just to use get_cpu_var then put_cpu_var there instead,
> but no hurry, I can survive with DEBUG_PREEMPT off.
Still a problem in 3.2.0-rc6-next-20111222
Hugh
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: next BUG: using smp_processor_id() in preemptible
2011-12-22 12:07 ` Hugh Dickins
@ 2011-12-22 21:17 ` Benjamin Herrenschmidt
2012-01-14 22:21 ` Hugh Dickins
0 siblings, 1 reply; 7+ messages in thread
From: Benjamin Herrenschmidt @ 2011-12-22 21:17 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linuxppc-dev
On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
> On Mon, 5 Dec 2011, Hugh Dickins wrote:
>
> > 3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
> >
> > Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
> > Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
> > Dec 4 20:03:19 thorn kernel: Call Trace:
> > Dec 4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
> > Dec 4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
> > Dec 4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
> > Dec 4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
> > Dec 4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed
> >
> > from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
> > in decrementer_check_overflow(): I've no idea whether it's safe
> > just to use get_cpu_var then put_cpu_var there instead,
> > but no hurry, I can survive with DEBUG_PREEMPT off.
>
> Still a problem in 3.2.0-rc6-next-20111222
Ah forgot about that, I'll have a look. Thanks for the reminder.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: next BUG: using smp_processor_id() in preemptible
2011-12-22 21:17 ` Benjamin Herrenschmidt
@ 2012-01-14 22:21 ` Hugh Dickins
2012-01-15 5:05 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 7+ messages in thread
From: Hugh Dickins @ 2012-01-14 22:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
On Fri, 23 Dec 2011, Benjamin Herrenschmidt wrote:
> On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
> > On Mon, 5 Dec 2011, Hugh Dickins wrote:
> >
> > > 3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
> > >
> > > Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
> > > Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
> > > Dec 4 20:03:19 thorn kernel: Call Trace:
> > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
> > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
> > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
> > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
> > > Dec 4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed
> > >
> > > from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
> > > in decrementer_check_overflow(): I've no idea whether it's safe
> > > just to use get_cpu_var then put_cpu_var there instead,
> > > but no hurry, I can survive with DEBUG_PREEMPT off.
> >
> > Still a problem in 3.2.0-rc6-next-20111222
>
> Ah forgot about that, I'll have a look. Thanks for the reminder.
I'm afraid it's now blighting Linus's tree for 3.3.
Hugh
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: next BUG: using smp_processor_id() in preemptible
2012-01-14 22:21 ` Hugh Dickins
@ 2012-01-15 5:05 ` Benjamin Herrenschmidt
2012-02-01 6:12 ` Hugh Dickins
0 siblings, 1 reply; 7+ messages in thread
From: Benjamin Herrenschmidt @ 2012-01-15 5:05 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linuxppc-dev
On Sat, 2012-01-14 at 14:21 -0800, Hugh Dickins wrote:
> On Fri, 23 Dec 2011, Benjamin Herrenschmidt wrote:
> > On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
> > > On Mon, 5 Dec 2011, Hugh Dickins wrote:
> > >
> > > > 3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
> > > >
> > > > Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
> > > > Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
> > > > Dec 4 20:03:19 thorn kernel: Call Trace:
> > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
> > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
> > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
> > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
> > > > Dec 4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed
> > > >
> > > > from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
> > > > in decrementer_check_overflow(): I've no idea whether it's safe
> > > > just to use get_cpu_var then put_cpu_var there instead,
> > > > but no hurry, I can survive with DEBUG_PREEMPT off.
> > >
> > > Still a problem in 3.2.0-rc6-next-20111222
> >
> > Ah forgot about that, I'll have a look. Thanks for the reminder.
>
> I'm afraid it's now blighting Linus's tree for 3.3.
Grrr, my memory is a colander... And now am in Ballarat for the week
with a semi working 3g connection. I'll see what I can do.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: next BUG: using smp_processor_id() in preemptible
2012-01-15 5:05 ` Benjamin Herrenschmidt
@ 2012-02-01 6:12 ` Hugh Dickins
2012-02-01 10:48 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 7+ messages in thread
From: Hugh Dickins @ 2012-02-01 6:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
On Sun, 15 Jan 2012, Benjamin Herrenschmidt wrote:
> On Sat, 2012-01-14 at 14:21 -0800, Hugh Dickins wrote:
> > On Fri, 23 Dec 2011, Benjamin Herrenschmidt wrote:
> > > On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
> > > > On Mon, 5 Dec 2011, Hugh Dickins wrote:
> > > >
> > > > > 3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
> > > > >
> > > > > Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
> > > > > Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
> > > > > Dec 4 20:03:19 thorn kernel: Call Trace:
> > > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
> > > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
> > > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
> > > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
> > > > > Dec 4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed
> > > > >
> > > > > from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
> > > > > in decrementer_check_overflow(): I've no idea whether it's safe
> > > > > just to use get_cpu_var then put_cpu_var there instead,
> > > > > but no hurry, I can survive with DEBUG_PREEMPT off.
> > > >
> > > > Still a problem in 3.2.0-rc6-next-20111222
> > >
> > > Ah forgot about that, I'll have a look. Thanks for the reminder.
> >
> > I'm afraid it's now blighting Linus's tree for 3.3.
>
> Grrr, my memory is a colander... And now am in Ballarat for the week
> with a semi working 3g connection. I'll see what I can do.
Sorry to be such a bore - you can guess what I have to say about 3.3-rc2 :()
Hugh
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: next BUG: using smp_processor_id() in preemptible
2012-02-01 6:12 ` Hugh Dickins
@ 2012-02-01 10:48 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 7+ messages in thread
From: Benjamin Herrenschmidt @ 2012-02-01 10:48 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linuxppc-dev
On Tue, 2012-01-31 at 22:12 -0800, Hugh Dickins wrote:
> > Grrr, my memory is a colander... And now am in Ballarat for the week
> > with a semi working 3g connection. I'll see what I can do.
>
> Sorry to be such a bore - you can guess what I have to say about
> 3.3-rc2 :()
Yeah, I'm looking at reworking the whole thing, I think we have another
deeper problem with lazy interrupt disable and implicit re-enable from
an exception exit too... stay tuned.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-02-01 10:48 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-05 23:51 next BUG: using smp_processor_id() in preemptible Hugh Dickins
2011-12-22 12:07 ` Hugh Dickins
2011-12-22 21:17 ` Benjamin Herrenschmidt
2012-01-14 22:21 ` Hugh Dickins
2012-01-15 5:05 ` Benjamin Herrenschmidt
2012-02-01 6:12 ` Hugh Dickins
2012-02-01 10:48 ` Benjamin Herrenschmidt
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.