* Re: 64-bit ppc rwsem
From: David Miller @ 2010-08-23 22:18 UTC (permalink / raw)
To: benh; +Cc: arnd, linuxppc-dev, paulus, linux-kernel, sparclinux, akpm,
torvalds
In-Reply-To: <1282600885.22370.453.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue, 24 Aug 2010 08:01:25 +1000
> On Mon, 2010-08-23 at 15:44 +0200, Arnd Bergmann wrote:
>>
>> * Alpha has an optimization for the uniprocessor case, where the atomic
>> instructions get turned into nonatomic additions. The spinlock based
>> version uses no locks on UP but disables interrupts for reasons I don't
>> understand (nothing running at interrupt time should try to access an rwsem).
>> Should the generic version do the same as Alpha?
>
> I've seen drivers in the past do trylocks at interrupt time ... tho I
> agree it sucks.
Recently there was a thread where this was declared absolutely illegal.
Maybe it was allowed, or sort-of worked before, and that's why it's
accounted for with IRQ disables in some implementations. I don't
know.
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Darren Hart @ 2010-08-23 22:20 UTC (permalink / raw)
To: Ankita Garg
Cc: Stephen Rothwell, Gautham R Shenoy, Steven Rostedt, linuxppc-dev,
Will Schmidt, Paul Mackerras, Thomas Gleixner
In-Reply-To: <20100819155824.GD2690@in.ibm.com>
On 08/19/2010 08:58 AM, Ankita Garg wrote:
> Hi Darren,
>
> On Thu, Jul 22, 2010 at 11:24:13AM -0700, Darren Hart wrote:
>>
>> With some instrumentation we were able to determine that the
>> preempt_count() appears to change across the extended_cede_processor()
>> call. Specifically across the plpar_hcall_norets(H_CEDE) call. On
>> PREEMPT_RT we call this with preempt_count=1 and return with
>> preempt_count=0xffffffff. On mainline with CONFIG_PREEMPT=y, the value
>> is different (0x65) but is still incorrect.
>
> I was trying to reproduce this issue on a 2.6.33.7-rt29 kernel. I could
> easily reproduce this on the RT kernel and not the non-RT kernel.
> However, I hit it every single time I did a cpu online operation. I also
> noticed that the issue persists even when I disable H_CEDE by passing
> the "cede_offline=0" kernel commandline parameter. Could you pl confirm
> if you observe the same in your setup ?
with the following patches:
[root@igoort1 linux-2.6-combined]# quilt applied
patches/0001-wms-fix01.patch
patches/powerpc-increase-pseries_cpu_die-delay.patch
patches/powerpc-enable-preemption-before-cpu_die.patch
patches/powerpc-silence-__cpu_up-under-normal-operation.patch
patches/powerpc-silence-xics_migrate_irqs_away-during-cpu-offline.patch
patches/powerpc-wait-for-cpu-to-go-inactive.patch
patches/powerpc-disable-decrementer-on-offline.patch
patches/powerpc-cpu_die-preempt-hack.patch
patches/powerpc-cede-processor-inst.patch
patches/irq-preempt-inst.patch
patches/disable-decrementer-in-cpu_die.patch
patches/powerpc-hard_irq_disable.patch
[root@igoort1 linux-2.6-combined]# quilt unapplied
patches/powerpc-debug-replace-cede-with-mdelay.patch
patches/powerpc-pad-thread_info.patch
applied to tip/rt/head (2.6.33-rt ish) I will see the following crash
after 3 or 4 runs:
<3>Badness at kernel/sched.c:3720
<4>NIP: c0000000006986f8 LR: c0000000006986dc CTR: c00000000006ec34
<4>REGS: c00000008e7a7e50 TRAP: 0700 Not tainted
(2.6.33-rt-dvhrt08-02358-g61223dd-dirty)
<4>MSR: 8000000000021032 <ME,CE,IR,DR> CR: 28000022 XER: 00000000
<4>TASK = c00000010e7080c0[0] 'swapper' THREAD: c00000008e7a8000 CPU: 3
<4>GPR00: 0000000000000000 c00000008e7a80d0 c000000000b54fa0
0000000000000001
<4>GPR04: 0000000000000000 0000000000000032 0000000000000000
000000000000000f
<4>GPR08: c00000008eb68d00 c000000000ca5420 0000000000000001
c000000000bc22e8
<4>GPR12: 8000000000009032 c000000000ba4a80 c00000008e7a8a70
0000000000000003
<4>GPR16: fffffffffffff9ba c00000010e7080c0 0000000000000000
7fffffffffffffff
<4>GPR20: 0000000000000000 0000000000000001 0000000000000003
c000000001042c80
<4>GPR24: 0000000000000000 c00000008eb686a0 0000000000000003
0000000000000001
<4>GPR28: 0000000000000000 0000000000000001 c000000000ad7628
c00000008e7a80d0
<4>NIP [c0000000006986f8] .sub_preempt_count+0x6c/0xdc
<4>LR [c0000000006986dc] .sub_preempt_count+0x50/0xdc
<4>Call Trace:
<4>Instruction dump:
<4>78290464 80090014 7f80e800 40fc002c 4bd08a99 60000000 2fa30000 419e0068
<4>e93e87e0 80090000 2f800000 409e0058 <0fe00000> 48000050 2b9d00fe 41fd0038
<1>Unable to handle kernel paging request for data at address
0xc000018000ba44c0
<1>Faulting instruction address: 0xc00000000006aae4
This occurs with or without the cede_offline=0 parameter.
Also, in a similar experiment which seems to corroborate your results,
suggesting the HCEDE call is not necessarily to blame here.
I had replaced the HCEDE call with a mdelay(2) and still ran into
issues. I didn't see the preempt count change, but I do see the
rtmutex.c:684 bug.
cpu 0x0: Vector: 300 (Data Access) at [c000000000b53ef0]
pc: c00000000006aa54: .resched_task+0x48/0xd8
lr: c00000000006ac44: .check_preempt_curr_idle+0x2c/0x44
sp: c000000000b54170
msr: 8000000000001032
dar: c000018000ba44c0
dsisr: 40000000
current = 0xc000000000aa1410
paca = 0xc000000000ba4480
pid = 0, comm = swapper
enter ? for help
[c000000000b54200] c00000000006ac44 .check_preempt_curr_idle+0x2c/0x44
[c000000000b54290] c00000000007b494 .try_to_wake_up+0x430/0x540
[c000000000b54360] c00000000007b754 .wake_up_process+0x34/0x48
[c000000000b543f0] c000000000089fa8 .wakeup_softirqd+0x78/0x9c
[c000000000b54480] c00000000008a2c4 .raise_softirq+0x7c/0xb8
[c000000000b54520] c0000000000977b0 .run_local_timers+0x2c/0x4c
[c000000000b545a0] c000000000097828 .update_process_times+0x58/0x9c
[c000000000b54640] c0000000000beb3c .tick_sched_timer+0xd0/0x120
[c000000000b546f0] c0000000000b08b8 .__run_hrtimer+0x1a0/0x29c
[c000000000b547a0] c0000000000b1258 .hrtimer_interrupt+0x21c/0x394
[c000000000b548d0] c0000000000304c4 .timer_interrupt+0x1ec/0x2f8
[c000000000b54980] c000000000003700 decrementer_common+0x100/0x180
--- Exception: 901 (Decrementer) at c0000000000100f8
.raw_local_irq_restore+0x74/0x8c
[c000000000b54d00] c000000000017d14 .cpu_idle+0x12c/0x220
[c000000000b54da0] c0000000006a1768 .start_secondary+0x3d8/0x418
[c000000000b54e60] c00000000005c1f0 .pseries_mach_cpu_die+0x244/0x318
[c000000000b54f10] c00000000001e7e0 .cpu_die+0x4c/0x68
[c000000000b54f90] c000000000017de0 .cpu_idle+0x1f8/0x220
... repeated multiple times ...
> However, the issue still remains. Will spend few cycles looking into
> this issue.
Appreciate it, the more eyes the better on this one.
--
Darren
>>
>> Also of interest is that this path
>> cpu_idle()->cpu_die()->pseries_mach_cpu_die() to start_secondary()
>> enters with a preempt_count=1 if it wasn't corrupted across the hcall.
>> The early boot path from _start however appears to call
>> start_secondary() with a preempt_count of 0.
>>
>> The following patch is most certainly not correct, but it does eliminate
>> the situation on mainline 100% of the time (there is still a 25%
>> reproduction rate on PREEMPT_RT). Can someone comment on:
>>
>> 1) How can the preempt_count() get mangled across the H_CEDE hcall?
>> 2) Should we call preempt_enable() in cpu_idle() prior to cpu_die() ?
>>
>> Hacked-up-by: Darren Hart<dvhltc@us.ibm.com>
>>
>> Index: linux-2.6.33.6/arch/powerpc/platforms/pseries/hotplug-cpu.c
>> ===================================================================
>> --- linux-2.6.33.6.orig/arch/powerpc/platforms/pseries/hotplug-cpu.c
>> +++ linux-2.6.33.6/arch/powerpc/platforms/pseries/hotplug-cpu.c
>> @@ -138,6 +138,7 @@ static void pseries_mach_cpu_die(void)
>> * Kernel stack will be reset and start_secondary()
>> * will be called to continue the online operation.
>> */
>> + preempt_count() = 0;
>> start_secondary_resume();
>> }
>> }
>>
>>
>
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
^ permalink raw reply
* Re: 64-bit ppc rwsem
From: Benjamin Herrenschmidt @ 2010-08-24 1:31 UTC (permalink / raw)
To: David Miller
Cc: arnd, linuxppc-dev, paulus, linux-kernel, sparclinux, akpm,
torvalds
In-Reply-To: <20100823.151853.108794567.davem@davemloft.net>
On Mon, 2010-08-23 at 15:18 -0700, David Miller wrote:
> > I've seen drivers in the past do trylocks at interrupt time ... tho
> I
> > agree it sucks.
>
> Recently there was a thread where this was declared absolutely
> illegal.
>
> Maybe it was allowed, or sort-of worked before, and that's why it's
> accounted for with IRQ disables in some implementations. I don't
> know.
Ok, I'm happy to say it's a big no-no then.
Arnd, do you want to take over the moving to asm-generic and take care
of the spinlock case as well ? I can send Linus the first patch that
changes powerpc to use atomic_long now along with a few other things I
have pending, then you can pickup from there. Or do you want me to
continue pushing my patch as-is and we can look at cleaning up the
spinlock case separately ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Make rwsem use "long" type
From: Timur Tabi @ 2010-08-24 1:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: torvalds, paulus, linux-kernel, sparclinux, akpm, linuxppc-dev,
David Miller
In-Reply-To: <1282281295.22370.400.camel@pasglop>
On Fri, Aug 20, 2010 at 12:14 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> =A0static inline int rwsem_is_locked(struct rw_semaphore *sem)
> =A0{
> - =A0 =A0 =A0 return (sem->count !=3D 0);
> + =A0 =A0 =A0 return sem->count !=3D 0;
> =A0}
Does this change make the code do anything different?
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 2/2] rwsem: Move powerpc atomic-long based implementation to asm-generic
From: Benjamin Herrenschmidt @ 2010-08-24 1:32 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Linus Torvalds, paulus, linux-kernel, sparclinux, akpm,
linuxppc-dev, David Miller
In-Reply-To: <20100820064348.GA19989@merkur.ravnborg.org>
On Fri, 2010-08-20 at 08:43 +0200, Sam Ravnborg wrote:
> > diff --git a/include/asm-generic/rwsem-cmpxchg.h b/include/asm-generic/rwsem-cmpxchg.h
> > new file mode 100644
> > index 0000000..2b1c859
> > --- /dev/null
> > +++ b/include/asm-generic/rwsem-cmpxchg.h
> > @@ -0,0 +1,183 @@
> > +#ifndef _RWSEM_CMPXCHG_H
> > +#define _RWSEM_CMPXCHG_H
> > +
> > +#ifndef _LINUX_RWSEM_H
> > +#error "Please don't include <asm/rwsem.h> directly, use <linux/rwsem.h> instead."
> > +#endif
> > +
> > +#ifdef __KERNEL__
>
> #ifdef __KERNEL__ is only relevant for exported headers.
> For kernel only headers like this is does not make sense,
> but it does not harm.
Well, it was there in the first place, I think we've carried around
forever, but as you say, it doesn't really harm.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Benjamin Herrenschmidt @ 2010-08-24 5:11 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Andreas Schwab, kvm-ppc, Paul Mackerras
In-Reply-To: <27922.1282523025@neuling.org>
On Mon, 2010-08-23 at 10:23 +1000, Michael Neuling wrote:
> > Neither lfs nor stfs touch the fpscr, so remove the restore/save of it
> > around them.
>
> Do some 32 bit processors need this?
>
> In 32 bit before the merge, we use to have code that did:
>
> #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> #define cvt_fd without save/restore fpscr
> #else
> #define cvt_fd with save/restore fpscr
> #end if
>
> Kumar; does this ring any bells?
I don't see anything in the various 440 docs I have at hand that would
hint at lfd/stfs adffecting FPSCR.
Cheers,
Ben.
> (The addition of this predates even bitkeeper)
>
> Mikey
> >
> > Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
> > ---
> > arch/powerpc/include/asm/kvm_fpu.h | 4 +-
> > arch/powerpc/include/asm/system.h | 4 +-
> > arch/powerpc/kernel/align.c | 4 +-
> > arch/powerpc/kernel/fpu.S | 10 -------
> > arch/powerpc/kvm/book3s_paired_singles.c | 44 +++++++++++++---------------
> -
> > arch/powerpc/kvm/fpu.S | 8 -----
> > 6 files changed, 26 insertions(+), 48 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_fpu.h b/arch/powerpc/include/asm/kv
> m_fpu.h
> > index c3d4f05..92daae1 100644
> > --- a/arch/powerpc/include/asm/kvm_fpu.h
> > +++ b/arch/powerpc/include/asm/kvm_fpu.h
> > @@ -82,7 +82,7 @@ FPD_THREE_IN(fmadd)
> > FPD_THREE_IN(fnmsub)
> > FPD_THREE_IN(fnmadd)
> >
> > -extern void kvm_cvt_fd(u32 *from, u64 *to, u64 *fpscr);
> > -extern void kvm_cvt_df(u64 *from, u32 *to, u64 *fpscr);
> > +extern void kvm_cvt_fd(u32 *from, u64 *to);
> > +extern void kvm_cvt_df(u64 *from, u32 *to);
> >
> > #endif
> > diff --git a/arch/powerpc/include/asm/system.h b/arch/powerpc/include/asm/sys
> tem.h
> > index 6c294ac..0b3fe78 100644
> > --- a/arch/powerpc/include/asm/system.h
> > +++ b/arch/powerpc/include/asm/system.h
> > @@ -154,8 +154,8 @@ extern void enable_kernel_spe(void);
> > extern void giveup_spe(struct task_struct *);
> > extern void load_up_spe(struct task_struct *);
> > extern int fix_alignment(struct pt_regs *);
> > -extern void cvt_fd(float *from, double *to, struct thread_struct *thread);
> > -extern void cvt_df(double *from, float *to, struct thread_struct *thread);
> > +extern void cvt_fd(float *from, double *to);
> > +extern void cvt_df(double *from, float *to);
> >
> > #ifndef CONFIG_SMP
> > extern void discard_lazy_cpu_state(void);
> > diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
> > index b876e98..8184ee9 100644
> > --- a/arch/powerpc/kernel/align.c
> > +++ b/arch/powerpc/kernel/align.c
> > @@ -889,7 +889,7 @@ int fix_alignment(struct pt_regs *regs)
> > #ifdef CONFIG_PPC_FPU
> > preempt_disable();
> > enable_kernel_fp();
> > - cvt_df(&data.dd, (float *)&data.v[4], ¤t->thread)
> ;
> > + cvt_df(&data.dd, (float *)&data.v[4]);
> > preempt_enable();
> > #else
> > return 0;
> > @@ -933,7 +933,7 @@ int fix_alignment(struct pt_regs *regs)
> > #ifdef CONFIG_PPC_FPU
> > preempt_disable();
> > enable_kernel_fp();
> > - cvt_fd((float *)&data.v[4], &data.dd, ¤t->thread);
> > + cvt_fd((float *)&data.v[4], &data.dd);
> > preempt_enable();
> > #else
> > return 0;
> > diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
> > index fc8f5b1..e86c040 100644
> > --- a/arch/powerpc/kernel/fpu.S
> > +++ b/arch/powerpc/kernel/fpu.S
> > @@ -163,24 +163,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> > /*
> > * These are used in the alignment trap handler when emulating
> > * single-precision loads and stores.
> > - * We restore and save the fpscr so the task gets the same result
> > - * and exceptions as if the cpu had performed the load or store.
> > */
> >
> > _GLOBAL(cvt_fd)
> > - lfd 0,THREAD_FPSCR(r5) /* load up fpscr value */
> > - MTFSF_L(0)
> > lfs 0,0(r3)
> > stfd 0,0(r4)
> > - mffs 0
> > - stfd 0,THREAD_FPSCR(r5) /* save new fpscr value */
> > blr
> >
> > _GLOBAL(cvt_df)
> > - lfd 0,THREAD_FPSCR(r5) /* load up fpscr value */
> > - MTFSF_L(0)
> > lfd 0,0(r3)
> > stfs 0,0(r4)
> > - mffs 0
> > - stfd 0,THREAD_FPSCR(r5) /* save new fpscr value */
> > blr
> > diff --git a/arch/powerpc/kvm/book3s_paired_singles.c b/arch/powerpc/kvm/book
> 3s_paired_singles.c
> > index 474f2e2..35a701f 100644
> > --- a/arch/powerpc/kvm/book3s_paired_singles.c
> > +++ b/arch/powerpc/kvm/book3s_paired_singles.c
> > @@ -159,7 +159,7 @@
> >
> > static inline void kvmppc_sync_qpr(struct kvm_vcpu *vcpu, int rt)
> > {
> > - kvm_cvt_df(&vcpu->arch.fpr[rt], &vcpu->arch.qpr[rt], &vcpu->arch.fpscr)
> ;
> > + kvm_cvt_df(&vcpu->arch.fpr[rt], &vcpu->arch.qpr[rt]);
> > }
> >
> > static void kvmppc_inject_pf(struct kvm_vcpu *vcpu, ulong eaddr, bool is_sto
> re)
> > @@ -204,7 +204,7 @@ static int kvmppc_emulate_fpr_load(struct kvm_run *run, s
> truct kvm_vcpu *vcpu,
> > /* put in registers */
> > switch (ls_type) {
> > case FPU_LS_SINGLE:
> > - kvm_cvt_fd((u32*)tmp, &vcpu->arch.fpr[rs], &vcpu->arch.fpscr);
> > + kvm_cvt_fd((u32*)tmp, &vcpu->arch.fpr[rs]);
> > vcpu->arch.qpr[rs] = *((u32*)tmp);
> > break;
> > case FPU_LS_DOUBLE:
> > @@ -230,7 +230,7 @@ static int kvmppc_emulate_fpr_store(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> >
> > switch (ls_type) {
> > case FPU_LS_SINGLE:
> > - kvm_cvt_df(&vcpu->arch.fpr[rs], (u32*)tmp, &vcpu->arch.fpscr);
> > + kvm_cvt_df(&vcpu->arch.fpr[rs], (u32*)tmp);
> > val = *((u32*)tmp);
> > len = sizeof(u32);
> > break;
> > @@ -296,7 +296,7 @@ static int kvmppc_emulate_psq_load(struct kvm_run *run, s
> truct kvm_vcpu *vcpu,
> > emulated = EMULATE_DONE;
> >
> > /* put in registers */
> > - kvm_cvt_fd(&tmp[0], &vcpu->arch.fpr[rs], &vcpu->arch.fpscr);
> > + kvm_cvt_fd(&tmp[0], &vcpu->arch.fpr[rs]);
> > vcpu->arch.qpr[rs] = tmp[1];
> >
> > dprintk(KERN_INFO "KVM: PSQ_LD [0x%x, 0x%x] at 0x%lx (%d)\n", tmp[0],
> > @@ -314,7 +314,7 @@ static int kvmppc_emulate_psq_store(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> > u32 tmp[2];
> > int len = w ? sizeof(u32) : sizeof(u64);
> >
> > - kvm_cvt_df(&vcpu->arch.fpr[rs], &tmp[0], &vcpu->arch.fpscr);
> > + kvm_cvt_df(&vcpu->arch.fpr[rs], &tmp[0]);
> > tmp[1] = vcpu->arch.qpr[rs];
> >
> > r = kvmppc_st(vcpu, &addr, len, tmp, true);
> > @@ -516,9 +516,9 @@ static int kvmppc_ps_three_in(struct kvm_vcpu *vcpu, bool
> rc,
> > WARN_ON(rc);
> >
> > /* PS0 */
> > - kvm_cvt_df(&fpr[reg_in1], &ps0_in1, &vcpu->arch.fpscr);
> > - kvm_cvt_df(&fpr[reg_in2], &ps0_in2, &vcpu->arch.fpscr);
> > - kvm_cvt_df(&fpr[reg_in3], &ps0_in3, &vcpu->arch.fpscr);
> > + kvm_cvt_df(&fpr[reg_in1], &ps0_in1);
> > + kvm_cvt_df(&fpr[reg_in2], &ps0_in2);
> > + kvm_cvt_df(&fpr[reg_in3], &ps0_in3);
> >
> > if (scalar & SCALAR_LOW)
> > ps0_in2 = qpr[reg_in2];
> > @@ -529,7 +529,7 @@ static int kvmppc_ps_three_in(struct kvm_vcpu *vcpu, bool
> rc,
> > ps0_in1, ps0_in2, ps0_in3, ps0_out);
> >
> > if (!(scalar & SCALAR_NO_PS0))
> > - kvm_cvt_fd(&ps0_out, &fpr[reg_out], &vcpu->arch.fpscr);
> > + kvm_cvt_fd(&ps0_out, &fpr[reg_out]);
> >
> > /* PS1 */
> > ps1_in1 = qpr[reg_in1];
> > @@ -566,12 +566,12 @@ static int kvmppc_ps_two_in(struct kvm_vcpu *vcpu, bool
> rc,
> > WARN_ON(rc);
> >
> > /* PS0 */
> > - kvm_cvt_df(&fpr[reg_in1], &ps0_in1, &vcpu->arch.fpscr);
> > + kvm_cvt_df(&fpr[reg_in1], &ps0_in1);
> >
> > if (scalar & SCALAR_LOW)
> > ps0_in2 = qpr[reg_in2];
> > else
> > - kvm_cvt_df(&fpr[reg_in2], &ps0_in2, &vcpu->arch.fpscr);
> > + kvm_cvt_df(&fpr[reg_in2], &ps0_in2);
> >
> > func(&vcpu->arch.fpscr, &ps0_out, &ps0_in1, &ps0_in2);
> >
> > @@ -579,7 +579,7 @@ static int kvmppc_ps_two_in(struct kvm_vcpu *vcpu, bool r
> c,
> > dprintk(KERN_INFO "PS2 ps0 -> f(0x%x, 0x%x) = 0x%x\n",
> > ps0_in1, ps0_in2, ps0_out);
> >
> > - kvm_cvt_fd(&ps0_out, &fpr[reg_out], &vcpu->arch.fpscr);
> > + kvm_cvt_fd(&ps0_out, &fpr[reg_out]);
> > }
> >
> > /* PS1 */
> > @@ -615,13 +615,13 @@ static int kvmppc_ps_one_in(struct kvm_vcpu *vcpu, bool
> rc,
> > WARN_ON(rc);
> >
> > /* PS0 */
> > - kvm_cvt_df(&fpr[reg_in], &ps0_in, &vcpu->arch.fpscr);
> > + kvm_cvt_df(&fpr[reg_in], &ps0_in);
> > func(&vcpu->arch.fpscr, &ps0_out, &ps0_in);
> >
> > dprintk(KERN_INFO "PS1 ps0 -> f(0x%x) = 0x%x\n",
> > ps0_in, ps0_out);
> >
> > - kvm_cvt_fd(&ps0_out, &fpr[reg_out], &vcpu->arch.fpscr);
> > + kvm_cvt_fd(&ps0_out, &fpr[reg_out]);
> >
> > /* PS1 */
> > ps1_in = qpr[reg_in];
> > @@ -671,7 +671,7 @@ int kvmppc_emulate_paired_single(struct kvm_run *run, str
> uct kvm_vcpu *vcpu)
> > #ifdef DEBUG
> > for (i = 0; i < ARRAY_SIZE(vcpu->arch.fpr); i++) {
> > u32 f;
> > - kvm_cvt_df(&vcpu->arch.fpr[i], &f, &vcpu->arch.fpscr);
> > + kvm_cvt_df(&vcpu->arch.fpr[i], &f);
> > dprintk(KERN_INFO "FPR[%d] = 0x%x / 0x%llx QPR[%d] = 0x%x\n"
> ,
> > i, f, vcpu->arch.fpr[i], i, vcpu->arch.qpr[i]);
> > }
> > @@ -796,8 +796,7 @@ int kvmppc_emulate_paired_single(struct kvm_run *run, str
> uct kvm_vcpu *vcpu)
> > vcpu->arch.fpr[ax_rd] = vcpu->arch.fpr[ax_ra];
> > /* vcpu->arch.qpr[ax_rd] = vcpu->arch.fpr[ax_rb]; */
> > kvm_cvt_df(&vcpu->arch.fpr[ax_rb],
> > - &vcpu->arch.qpr[ax_rd],
> > - &vcpu->arch.fpscr);
> > + &vcpu->arch.qpr[ax_rd]);
> > break;
> > case OP_4X_PS_MERGE01:
> > WARN_ON(rcomp);
> > @@ -808,19 +807,16 @@ int kvmppc_emulate_paired_single(struct kvm_run *run, s
> truct kvm_vcpu *vcpu)
> > WARN_ON(rcomp);
> > /* vcpu->arch.fpr[ax_rd] = vcpu->arch.qpr[ax_ra]; */
> > kvm_cvt_fd(&vcpu->arch.qpr[ax_ra],
> > - &vcpu->arch.fpr[ax_rd],
> > - &vcpu->arch.fpscr);
> > + &vcpu->arch.fpr[ax_rd]);
> > /* vcpu->arch.qpr[ax_rd] = vcpu->arch.fpr[ax_rb]; */
> > kvm_cvt_df(&vcpu->arch.fpr[ax_rb],
> > - &vcpu->arch.qpr[ax_rd],
> > - &vcpu->arch.fpscr);
> > + &vcpu->arch.qpr[ax_rd]);
> > break;
> > case OP_4X_PS_MERGE11:
> > WARN_ON(rcomp);
> > /* vcpu->arch.fpr[ax_rd] = vcpu->arch.qpr[ax_ra]; */
> > kvm_cvt_fd(&vcpu->arch.qpr[ax_ra],
> > - &vcpu->arch.fpr[ax_rd],
> > - &vcpu->arch.fpscr);
> > + &vcpu->arch.fpr[ax_rd]);
> > vcpu->arch.qpr[ax_rd] = vcpu->arch.qpr[ax_rb];
> > break;
> > }
> > @@ -1255,7 +1251,7 @@ int kvmppc_emulate_paired_single(struct kvm_run *run, s
> truct kvm_vcpu *vcpu)
> > #ifdef DEBUG
> > for (i = 0; i < ARRAY_SIZE(vcpu->arch.fpr); i++) {
> > u32 f;
> > - kvm_cvt_df(&vcpu->arch.fpr[i], &f, &vcpu->arch.fpscr);
> > + kvm_cvt_df(&vcpu->arch.fpr[i], &f);
> > dprintk(KERN_INFO "FPR[%d] = 0x%x\n", i, f);
> > }
> > #endif
> > diff --git a/arch/powerpc/kvm/fpu.S b/arch/powerpc/kvm/fpu.S
> > index cb34bbe..bf68d59 100644
> > --- a/arch/powerpc/kvm/fpu.S
> > +++ b/arch/powerpc/kvm/fpu.S
> > @@ -273,19 +273,11 @@ FPD_THREE_IN(fnmsub)
> > FPD_THREE_IN(fnmadd)
> >
> > _GLOBAL(kvm_cvt_fd)
> > - lfd 0,0(r5) /* load up fpscr value */
> > - MTFSF_L(0)
> > lfs 0,0(r3)
> > stfd 0,0(r4)
> > - mffs 0
> > - stfd 0,0(r5) /* save new fpscr value */
> > blr
> >
> > _GLOBAL(kvm_cvt_df)
> > - lfd 0,0(r5) /* load up fpscr value */
> > - MTFSF_L(0)
> > lfd 0,0(r3)
> > stfs 0,0(r4)
> > - mffs 0
> > - stfd 0,0(r5) /* save new fpscr value */
> > blr
> > --
> > 1.7.2.2
> >
> >
> > --
> > Andreas Schwab, schwab@linux-m68k.org
> > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> > "And now for something completely different."
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Michael Neuling @ 2010-08-24 5:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andreas Schwab, kvm-ppc, Paul Mackerras
In-Reply-To: <1282626718.22370.505.camel@pasglop>
> > Do some 32 bit processors need this?
> >
> > In 32 bit before the merge, we use to have code that did:
> >
> > #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> > #define cvt_fd without save/restore fpscr
> > #else
> > #define cvt_fd with save/restore fpscr
> > #end if
> >
> > Kumar; does this ring any bells?
>
> I don't see anything in the various 440 docs I have at hand that would
> hint at lfd/stfs adffecting FPSCR.
The way the ifdefs are, it's the other way around. 4xx procs don't need
to save/restore fpscr and others do.
Mikey
^ permalink raw reply
* Re: [PATCH 1/1] powerpc: Clear cpu_sibling_map in cpu_die
From: Benjamin Herrenschmidt @ 2010-08-24 5:24 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev
In-Reply-To: <201008112034.o7BKYvEJ013392@d03av04.boulder.ibm.com>
On Wed, 2010-08-11 at 15:34 -0500, Brian King wrote:
> While testing CPU DLPAR, the following problem was discovered.
> We were DLPAR removing the first CPU, which in this case was
> logical CPUs 0-3. CPUs 0-2 were already marked offline and
> we were in the process of offlining CPU 3. After marking
> the CPU inactive and offline in cpu_disable, but before the
> cpu was completely idle (cpu_die), we ended up in __make_request
> on CPU 3. There we looked at the topology map to see which CPU
> to complete the I/O on and found no CPUs in the cpu_sibling_map.
> This resulted in the block layer setting the completion cpu
> to be NR_CPUS, which then caused an oops when we tried to
> complete the I/O.
>
> Fix this by delaying clearing the sibling map of the cpu we
> are offlining for the cpu we are offlining until cpu_die.
So I'm not getting a clear mental picture of the situation, sorry about
that.
We are offlining CPU 3, and we have already marked it inactive and
online, so how come we end up in __make_request() on it at this stage
and shouldn't it be the block layer that notices that it's targeting an
offlined CPU ?
IE. I have doubts about leaving a CPU in the sibling map which isn't
online... Wouldn't we end up "scheduling" things to it after it's
supposed to have freed itself of everything (timers, workqueues,
etc...) ?
As I said, I'm probably missing a part of the puzzle ..
Ben.
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> ---
>
> arch/powerpc/kernel/smp.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff -puN arch/powerpc/kernel/smp.c~powerpc_sibling_map_offline arch/powerpc/kernel/smp.c
> --- linux-2.6/arch/powerpc/kernel/smp.c~powerpc_sibling_map_offline 2010-08-09 16:49:47.000000000 -0500
> +++ linux-2.6-bjking1/arch/powerpc/kernel/smp.c 2010-08-09 16:49:47.000000000 -0500
> @@ -598,8 +598,11 @@ int __cpu_disable(void)
> /* Update sibling maps */
> base = cpu_first_thread_in_core(cpu);
> for (i = 0; i < threads_per_core; i++) {
> - cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
> - cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
> + if ((base + i) != cpu) {
> + cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
> + cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
> + }
> +
> cpumask_clear_cpu(cpu, cpu_core_mask(base + i));
> cpumask_clear_cpu(base + i, cpu_core_mask(cpu));
> }
> @@ -641,6 +644,8 @@ void cpu_hotplug_driver_unlock()
>
> void cpu_die(void)
> {
> + cpumask_clear_cpu(smp_processor_id(), cpu_sibling_mask(smp_processor_id()));
> +
> if (ppc_md.cpu_die)
> ppc_md.cpu_die();
> }
> _
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Benjamin Herrenschmidt @ 2010-08-24 5:39 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Andreas Schwab, kvm-ppc, Paul Mackerras
In-Reply-To: <32250.1282626925@neuling.org>
> The way the ifdefs are, it's the other way around. 4xx procs don't need
> to save/restore fpscr and others do.
Hrm, oh well, 601 manual says FPSCR is unaffected too :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Kumar Gala @ 2010-08-24 5:47 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Paul Mackerras, Andreas Schwab, kvm-ppc
In-Reply-To: <27922.1282523025@neuling.org>
On Aug 22, 2010, at 7:23 PM, Michael Neuling wrote:
>> Neither lfs nor stfs touch the fpscr, so remove the restore/save of =
it
>> around them.
>=20
> Do some 32 bit processors need this?=20
>=20
> In 32 bit before the merge, we use to have code that did:
>=20
> #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> #define cvt_fd without save/restore fpscr
> #else
> #define cvt_fd with save/restore fpscr
> #end if
>=20
> Kumar; does this ring any bells?
>=20
> (The addition of this predates even bitkeeper)
>=20
> Mikey
Not really. However if the ifdef is as you say that seems wrong to me. =
We should be using CONFIG_PPC_FPU or !CONFIG_PPC_FPU. As both 4xx and =
E500 have variants w/FPUs.
- k=
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Michael Neuling @ 2010-08-24 5:51 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Andreas Schwab, kvm-ppc
In-Reply-To: <DCE42647-5931-41EF-BBE8-F09FDC700143@kernel.crashing.org>
> >> Neither lfs nor stfs touch the fpscr, so remove the restore/save of =
> it
> >> around them.
> >=20
> > Do some 32 bit processors need this?=20
> >=20
> > In 32 bit before the merge, we use to have code that did:
> >=20
> > #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> > #define cvt_fd without save/restore fpscr
> > #else
> > #define cvt_fd with save/restore fpscr
> > #end if
> >=20
> > Kumar; does this ring any bells?
> >=20
> > (The addition of this predates even bitkeeper)
> >=20
> > Mikey
>
> Not really. However if the ifdef is as you say that seems wrong to
> me. We should be using CONFIG_PPC_FPU or !CONFIG_PPC_FPU. As both
> 4xx and E500 have variants w/FPUs.
It actually got changed to CONFIG_PPC_FPU, then dwg merged it with some
other versions that were around.
Mikey
^ permalink raw reply
* 52xx build error
From: Benjamin Herrenschmidt @ 2010-08-24 6:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
I get that with my current stuff:
cc1: warnings being treated as errors
In file included from /home/benh/linux-powerpc-test/arch/powerpc/platforms/52xx/mpc52xx_common.c:19:
/home/benh/linux-powerpc-test/include/linux/of_gpio.h:74: error: ‘struct gpio_chip’ declared inside parameter list
/home/benh/linux-powerpc-test/include/linux/of_gpio.h:74: error: its scope is only this definition or declaration, which is probably not what you want
/home/benh/linux-powerpc-test/include/linux/of_gpio.h:75: error: ‘struct gpio_chip’ declared inside parameter list
CC mm/bootmem.o
make[3]: *** [arch/powerpc/platforms/52xx/mpc52xx_common.o] Error 1
make[3]: *** Waiting for unfinished jobs....
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] [powerpc] Wire up fanotify_init, fanotify_mark, prlimit64 syscalls
From: Benjamin Herrenschmidt @ 2010-08-24 6:33 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linuxppc-dev, Andreas Schwab, Arnd Bergmann, linuxppc-dev
In-Reply-To: <201008231552.07013.arnd@arndb.de>
On Mon, 2010-08-23 at 15:52 +0200, Arnd Bergmann wrote:
> On Friday 20 August 2010, Andreas Schwab wrote:
> > See arch/powerpc/platforms/cell/spu_callbacks.c.
> >
> > * 4. They are optional and we can't rely on them being
> > * linked into the kernel. Unfortunately, the cond_syscall
> > * helper does not work here as it does not add the necessary
> > * opd symbols:
>
> Right. I should blame the person that wrote this comment.
> If only I could remember who that was.
Regardless of the outcome of that, I'm merging Andreas patch. We can
always add SPU bindings if we feel like it later.
Cheers,
Ben.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2010-08-24 6:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's a few powerpc bits & fixes for 2.6.36, some of them for some of
the new stuff that went in, along with the powerpc rwsem update to
atomic_long_t (not yet moved to asm-generic) and wiring up of some new
syscalls.
Cheers,
Ben.
The following changes since commit d1b113bb028999e82a8528e1484be8c23fb5a7d9:
Linus Torvalds (1):
Merge git://git.kernel.org/.../davem/net-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git master
Anatolij Gustschin (1):
powerpc: Fix typo in uImage target
Andreas Schwab (3):
powerpc: Wire up fanotify_init, fanotify_mark, prlimit64 syscalls
via-pmu: Add compat_pmu_ioctl
powerpc: Fix config dependency problem with MPIC_U3_HT_IRQS
Anton Blanchard (4):
powerpc/mm: Fix vsid_scrample typo
powerpc/kdump: Stop all other CPUs before running crash handlers
powerpc: Inline ppc64_runlatch_off
powerpc: Fix bogus it_blocksize in VIO iommu code
Benjamin Herrenschmidt (2):
Merge remote branch 'jwb/merge' into merge
powerpc: Make rwsem use "long" type
Dave Kleikamp (4):
powerpc/47x: Make sure mcsr is cleared before enabling machine check interrupts
powerpc/47x: Remove redundant line from cputable.c
powerpc/4xx: Index interrupt stacks by physical cpu
powerpc/47x: Add an isync before the tlbivax instruction
Denis Kirjanov (1):
powerpc: Use is_32bit_task() helper to test 32 bit binary
Grant Likely (1):
powerpc/pci: Fix checking for child bridges in PCI code.
Julia Lawall (3):
powerpc/powermac: Drop unnecessary of_node_put
powerpc/powermac: Drop unnecessary null test
powerpc/pci: Drop unnecessary null test
Matt Evans (1):
powerpc: Initialise paca->kstack before early_setup_secondary
Nathan Fontenot (1):
powerpc: Correct smt_enabled=X boot option for > 2 threads per core
Rupjyoti Sarmah (1):
powerpc/4xx: Device tree update for the 460ex DWC SATA
Signed-off-by: Darren Hart (3):
powerpc: Re-enable preemption before cpu_die()
powerpc: Silence __cpu_up() under normal operation
powerpc: Silence xics_migrate_irqs_away() during cpu offline
Sonny Rao (1):
powerpc: Export memstart_addr and kernstart_addr on ppc64
arch/powerpc/Makefile | 2 +-
arch/powerpc/boot/dts/canyonlands.dts | 8 ++++
arch/powerpc/include/asm/mmu-hash64.h | 2 +-
arch/powerpc/include/asm/reg.h | 9 ++++-
arch/powerpc/include/asm/rwsem.h | 64 +++++++++++++++++------------
arch/powerpc/include/asm/systbl.h | 3 +
arch/powerpc/include/asm/unistd.h | 5 ++-
arch/powerpc/kernel/cputable.c | 1 -
arch/powerpc/kernel/crash.c | 24 ++++++-----
arch/powerpc/kernel/head_44x.S | 4 ++
arch/powerpc/kernel/head_64.S | 6 +-
arch/powerpc/kernel/idle.c | 2 +-
arch/powerpc/kernel/irq.c | 16 ++++---
arch/powerpc/kernel/pci_of_scan.c | 2 +-
arch/powerpc/kernel/process.c | 20 ++++-----
arch/powerpc/kernel/setup_32.c | 9 ++--
arch/powerpc/kernel/setup_64.c | 63 ++++++++++++++++------------
arch/powerpc/kernel/smp.c | 4 +-
arch/powerpc/kernel/sys_ppc32.c | 8 ++++
arch/powerpc/kernel/vio.c | 3 +-
arch/powerpc/mm/init_64.c | 2 +
arch/powerpc/mm/tlb_nohash_low.S | 1 +
arch/powerpc/platforms/Kconfig | 3 +-
arch/powerpc/platforms/cell/iommu.c | 2 +-
arch/powerpc/platforms/iseries/iommu.c | 2 +-
arch/powerpc/platforms/powermac/feature.c | 3 +-
arch/powerpc/platforms/powermac/pci.c | 2 -
arch/powerpc/platforms/pseries/iommu.c | 8 ++--
arch/powerpc/platforms/pseries/smp.c | 11 +++--
arch/powerpc/platforms/pseries/xics.c | 6 ++-
drivers/macintosh/via-pmu.c | 42 +++++++++++++++++++
31 files changed, 219 insertions(+), 118 deletions(-)
^ permalink raw reply
* Re: [PATCH] [powerpc] Wire up fanotify_init, fanotify_mark, prlimit64 syscalls
From: Arnd Bergmann @ 2010-08-24 7:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linuxppc-dev, Andreas Schwab, Arnd Bergmann, linuxppc-dev
In-Reply-To: <1282631584.22370.523.camel@pasglop>
On Tuesday 24 August 2010, Benjamin Herrenschmidt wrote:
> On Mon, 2010-08-23 at 15:52 +0200, Arnd Bergmann wrote:
> > On Friday 20 August 2010, Andreas Schwab wrote:
> > > See arch/powerpc/platforms/cell/spu_callbacks.c.
> > >
> > > * 4. They are optional and we can't rely on them being
> > > * linked into the kernel. Unfortunately, the cond_syscall
> > > * helper does not work here as it does not add the necessary
> > > * opd symbols:
> >
> > Right. I should blame the person that wrote this comment.
> > If only I could remember who that was.
>
> Regardless of the outcome of that, I'm merging Andreas patch. We can
> always add SPU bindings if we feel like it later.
Sorry, I should have added a ';-)' or been clearer. The patch is good,
I wrote the comment that Andreas quoted and it's probably my own fault
that we never found a way to handle syscalls like this correctly from
the SPU.
Arnd
^ permalink raw reply
* [PATCH] gpiolib: Add 'struct gpio_chip' forward declaration for !GPIOLIB case
From: Anton Vorontsov @ 2010-08-24 9:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Andrew Morton
Cc: David Brownell, linuxppc-dev, linux-kernel
In-Reply-To: <1282631168.22370.517.camel@pasglop>
With CONFIG_GPIOLIB=n, the 'struct gpio_chip' is not declared,
so the following pops up on PowerPC:
cc1: warnings being treated as errors
In file included from arch/powerpc/platforms/52xx/mpc52xx_common.c:19:
include/linux/of_gpio.h:74: warning: 'struct gpio_chip' declared
inside parameter list
include/linux/of_gpio.h:74: warning: its scope is only this definition
or declaration, which is probably not what
you want
include/linux/of_gpio.h:75: warning: 'struct gpio_chip' declared
inside parameter list
make[2]: *** [arch/powerpc/platforms/52xx/mpc52xx_common.o] Error 1
This patch fixes the issue by providing the proper forward declaration.
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---
On Tue, Aug 24, 2010 at 04:26:08PM +1000, Benjamin Herrenschmidt wrote:
> I get that with my current stuff:
>
> cc1: warnings being treated as errors
> In file included from [..]/mpc52xx_common.c:19:
> of_gpio.h:74: error: ‘struct gpio_chip’ declared inside parameter list
[...]
> make[3]: *** Waiting for unfinished jobs....
That's because with GPIOCHIP=n no one declares struct gpio_chip.
It should be either of_gpio.h or gpio.h. Let's make it gpio.h, as
this feels more generic, and we already have some !GPIOLIB handling
in there.
include/linux/gpio.h | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/gpio.h b/include/linux/gpio.h
index 03f616b..85207d2 100644
--- a/include/linux/gpio.h
+++ b/include/linux/gpio.h
@@ -15,6 +15,12 @@
struct device;
/*
+ * Some code might rely on the declaration. Still, it is illegal
+ * to dereference it for !GPIOLIB case.
+ */
+struct gpio_chip;
+
+/*
* Some platforms don't support the GPIO programming interface.
*
* In case some driver uses it anyway (it should normally have
--
1.7.0.5
^ permalink raw reply related
* Re: 64-bit ppc rwsem
From: Arnd Bergmann @ 2010-08-24 12:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, paulus, linux-kernel, sparclinux, akpm, torvalds,
David Miller
In-Reply-To: <1282613477.22370.485.camel@pasglop>
On Tuesday 24 August 2010, Benjamin Herrenschmidt wrote:
> On Mon, 2010-08-23 at 15:18 -0700, David Miller wrote:
> > > I've seen drivers in the past do trylocks at interrupt time ... tho
> > I
> > > agree it sucks.
> >
> > Recently there was a thread where this was declared absolutely
> > illegal.
> >
> > Maybe it was allowed, or sort-of worked before, and that's why it's
> > accounted for with IRQ disables in some implementations. I don't
> > know.
>
> Ok, I'm happy to say it's a big no-no then.
>
> Arnd, do you want to take over the moving to asm-generic and take care
> of the spinlock case as well ? I can send Linus the first patch that
> changes powerpc to use atomic_long now along with a few other things I
> have pending, then you can pickup from there. Or do you want me to
> continue pushing my patch as-is and we can look at cleaning up the
> spinlock case separately ?
I'm currently doing too many things at once, please push in your existing
patch for now, we can continue from there.
For the asm-generic patch:
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
From: Stephan Gatzka @ 2010-08-24 18:30 UTC (permalink / raw)
To: john stultz
Cc: Arnd Bergmann, netdev, Richard Cochran, linuxppc-dev,
linux-kernel, Rodolfo Giometti, devicetree-discuss,
linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <1282594125.3111.344.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 746 bytes --]
Hello!
> I'm curious if its possible to do the PTP hardware offset/adjustment
> calculation in a module internally to the kernel? That would allow the
> PPS interface to still be used to sync the system time, and not expose
> additional interfaces.
Just my 2 cents on this issue. PTP is very often used in embedded
systems, where the PTP timestamps will go into some dedicated hardware,
for instance an FPGA.
I'm currently working on a project where it is not necessary to adjust
the Linux system time via PTP (although it would be a nice to have), but
we only need the timestamps from the PHY to put them into our FPGA
device. So we need some kind of API to access the PTP timestamp registers.
Kind regards,
Stephan
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5136 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] powerpc: Clear cpu_sibling_map in cpu_die
From: Brian King @ 2010-08-24 21:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1282627487.22370.508.camel@pasglop>
On 08/24/2010 12:24 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2010-08-11 at 15:34 -0500, Brian King wrote:
>> While testing CPU DLPAR, the following problem was discovered.
>> We were DLPAR removing the first CPU, which in this case was
>> logical CPUs 0-3. CPUs 0-2 were already marked offline and
>> we were in the process of offlining CPU 3. After marking
>> the CPU inactive and offline in cpu_disable, but before the
>> cpu was completely idle (cpu_die), we ended up in __make_request
>> on CPU 3. There we looked at the topology map to see which CPU
>> to complete the I/O on and found no CPUs in the cpu_sibling_map.
>> This resulted in the block layer setting the completion cpu
>> to be NR_CPUS, which then caused an oops when we tried to
>> complete the I/O.
>>
>> Fix this by delaying clearing the sibling map of the cpu we
>> are offlining for the cpu we are offlining until cpu_die.
>
> So I'm not getting a clear mental picture of the situation, sorry about
> that.
>
> We are offlining CPU 3, and we have already marked it inactive and
> online, so how come we end up in __make_request() on it at this stage
I'm not sure about that. My thought was that until we get into cpu_die,
the cpu could still be executing code.
> and shouldn't it be the block layer that notices that it's targeting an
> offlined CPU ?
It could be easily fixed in blk_cpu_to_group as well. I'll look into
this.
> IE. I have doubts about leaving a CPU in the sibling map which isn't
> online... Wouldn't we end up "scheduling" things to it after it's
> supposed to have freed itself of everything (timers, workqueues,
> etc...) ?
I was assuming this wouldn't happen since the cpu is no longer online.
Thanks,
Brian
>
> As I said, I'm probably missing a part of the puzzle ..
>
> Ben.
>
>> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
>> ---
>>
>> arch/powerpc/kernel/smp.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff -puN arch/powerpc/kernel/smp.c~powerpc_sibling_map_offline arch/powerpc/kernel/smp.c
>> --- linux-2.6/arch/powerpc/kernel/smp.c~powerpc_sibling_map_offline 2010-08-09 16:49:47.000000000 -0500
>> +++ linux-2.6-bjking1/arch/powerpc/kernel/smp.c 2010-08-09 16:49:47.000000000 -0500
>> @@ -598,8 +598,11 @@ int __cpu_disable(void)
>> /* Update sibling maps */
>> base = cpu_first_thread_in_core(cpu);
>> for (i = 0; i < threads_per_core; i++) {
>> - cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
>> - cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
>> + if ((base + i) != cpu) {
>> + cpumask_clear_cpu(cpu, cpu_sibling_mask(base + i));
>> + cpumask_clear_cpu(base + i, cpu_sibling_mask(cpu));
>> + }
>> +
>> cpumask_clear_cpu(cpu, cpu_core_mask(base + i));
>> cpumask_clear_cpu(base + i, cpu_core_mask(cpu));
>> }
>> @@ -641,6 +644,8 @@ void cpu_hotplug_driver_unlock()
>>
>> void cpu_die(void)
>> {
>> + cpumask_clear_cpu(smp_processor_id(), cpu_sibling_mask(smp_processor_id()));
>> +
>> if (ppc_md.cpu_die)
>> ppc_md.cpu_die();
>> }
>> _
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] powerpc: Check end of stack canary at oops time
From: Anton Blanchard @ 2010-08-24 23:15 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Add a check for the stack canary when we oops, similar to x86. This should make
it clear that we overran our stack:
Unable to handle kernel paging request for data at address 0x24652f63700ac689
Faulting instruction address: 0xc000000000063d24
Thread overran stack, or stack corrupted
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/mm/fault.c
===================================================================
--- powerpc.git.orig/arch/powerpc/mm/fault.c 2010-08-25 08:41:08.230086186 +1000
+++ powerpc.git/arch/powerpc/mm/fault.c 2010-08-25 09:12:38.276553103 +1000
@@ -30,6 +30,7 @@
#include <linux/kprobes.h>
#include <linux/kdebug.h>
#include <linux/perf_event.h>
+#include <linux/magic.h>
#include <asm/firmware.h>
#include <asm/page.h>
@@ -385,6 +386,7 @@ do_sigbus:
void bad_page_fault(struct pt_regs *regs, unsigned long address, int sig)
{
const struct exception_table_entry *entry;
+ unsigned long *stackend;
/* Are we prepared to handle this fault? */
if ((entry = search_exception_tables(regs->nip)) != NULL) {
@@ -413,5 +415,9 @@ void bad_page_fault(struct pt_regs *regs
printk(KERN_ALERT "Faulting instruction address: 0x%08lx\n",
regs->nip);
+ stackend = end_of_stack(current);
+ if (current != &init_task && *stackend != STACK_END_MAGIC)
+ printk(KERN_ALERT "Thread overran stack, or stack corrupted\n");
+
die("Kernel access of bad area", regs, sig);
}
^ permalink raw reply
* [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
From: Anton Blanchard @ 2010-08-25 0:22 UTC (permalink / raw)
To: benh, ebiederm, akpm; +Cc: linuxppc-dev, kexec, linux-kernel
On ppc64 the crashkernel region almost always overlaps an area of firmware.
This works fine except when using the sysfs interface to reduce the kdump
region. If we free the firmware area we are guaranteed to crash.
Rename free_reserved_phys_range to crash_free_reserved_phys_range and make
it a weak function so we can override it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/kernel/kexec.c
===================================================================
--- powerpc.git.orig/kernel/kexec.c 2010-08-25 10:12:11.493863566 +1000
+++ powerpc.git/kernel/kexec.c 2010-08-25 10:12:35.907264327 +1000
@@ -1097,7 +1097,8 @@ size_t crash_get_memory_size(void)
return size;
}
-static void free_reserved_phys_range(unsigned long begin, unsigned long end)
+void __weak crash_free_reserved_phys_range(unsigned long begin,
+ unsigned long end)
{
unsigned long addr;
@@ -1133,7 +1134,7 @@ int crash_shrink_memory(unsigned long ne
start = roundup(start, PAGE_SIZE);
end = roundup(start + new_size, PAGE_SIZE);
- free_reserved_phys_range(end, crashk_res.end);
+ crash_free_reserved_phys_range(end, crashk_res.end);
if ((start == end) && (crashk_res.parent != NULL))
release_resource(&crashk_res);
Index: powerpc.git/include/linux/kexec.h
===================================================================
--- powerpc.git.orig/include/linux/kexec.h 2010-08-25 10:12:11.483862172 +1000
+++ powerpc.git/include/linux/kexec.h 2010-08-25 10:12:13.664166570 +1000
@@ -208,6 +208,7 @@ int __init parse_crashkernel(char *cmdli
unsigned long long *crash_size, unsigned long long *crash_base);
int crash_shrink_memory(unsigned long new_size);
size_t crash_get_memory_size(void);
+void crash_free_reserved_phys_range(unsigned long begin, unsigned long end);
#else /* !CONFIG_KEXEC */
struct pt_regs;
^ permalink raw reply
* [PATCH 2/2] powerpc: kdump: Override crash_free_reserved_phys_range to avoid freeing RTAS
From: Anton Blanchard @ 2010-08-25 0:23 UTC (permalink / raw)
To: benh, ebiederm, akpm; +Cc: linuxppc-dev, kexec, linux-kernel
In-Reply-To: <20100825002258.GD28360@kryten>
The crashkernel region will almost always overlap RTAS. If we free the
crashkernel region via "echo 0 > /sys/kernel/kexec_crash_size" then we will
free RTAS and the machine will crash in confusing and exciting ways.
Override crash_free_reserved_phys_range and check for overlap with RTAS.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/crash_dump.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/crash_dump.c 2010-08-24 09:24:32.219643256 +1000
+++ powerpc.git/arch/powerpc/kernel/crash_dump.c 2010-08-24 09:46:22.826868330 +1000
@@ -19,6 +19,7 @@
#include <asm/prom.h>
#include <asm/firmware.h>
#include <asm/uaccess.h>
+#include <asm/rtas.h>
#ifdef DEBUG
#include <asm/udbg.h>
@@ -141,3 +142,35 @@ ssize_t copy_oldmem_page(unsigned long p
return csize;
}
+
+#ifdef CONFIG_PPC_RTAS
+/*
+ * The crashkernel region will almost always overlap the RTAS region, so
+ * we have to be careful when shrinking the crashkernel region.
+ */
+void crash_free_reserved_phys_range(unsigned long begin, unsigned long end)
+{
+ unsigned long addr;
+ const u32 *basep, *sizep;
+ unsigned int rtas_start = 0, rtas_end = 0;
+
+ basep = of_get_property(rtas.dev, "linux,rtas-base", NULL);
+ sizep = of_get_property(rtas.dev, "rtas-size", NULL);
+
+ if (basep && sizep) {
+ rtas_start = *basep;
+ rtas_end = *basep + *sizep;
+ }
+
+ for (addr = begin; addr < end; addr += PAGE_SIZE) {
+ /* Does this page overlap with the RTAS region? */
+ if (addr <= rtas_end && ((addr + PAGE_SIZE) > rtas_start))
+ continue;
+
+ ClearPageReserved(pfn_to_page(addr >> PAGE_SHIFT));
+ init_page_count(pfn_to_page(addr >> PAGE_SHIFT));
+ free_page((unsigned long)__va(addr));
+ totalram_pages++;
+ }
+}
+#endif
^ permalink raw reply
* Re: [PATCH] powerpc: Check end of stack canary at oops time
From: Michael Ellerman @ 2010-08-25 1:29 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20100824231528.GC28360@kryten>
[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]
On Wed, 2010-08-25 at 09:15 +1000, Anton Blanchard wrote:
> Add a check for the stack canary when we oops, similar to x86. This should make
> it clear that we overran our stack:
>
> Unable to handle kernel paging request for data at address 0x24652f63700ac689
> Faulting instruction address: 0xc000000000063d24
> Thread overran stack, or stack corrupted
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> Index: powerpc.git/arch/powerpc/mm/fault.c
> ===================================================================
> --- powerpc.git.orig/arch/powerpc/mm/fault.c 2010-08-25 08:41:08.230086186 +1000
> +++ powerpc.git/arch/powerpc/mm/fault.c 2010-08-25 09:12:38.276553103 +1000
> @@ -30,6 +30,7 @@
> #include <linux/kprobes.h>
> #include <linux/kdebug.h>
> #include <linux/perf_event.h>
> +#include <linux/magic.h>
>
> #include <asm/firmware.h>
> #include <asm/page.h>
> @@ -385,6 +386,7 @@ do_sigbus:
> void bad_page_fault(struct pt_regs *regs, unsigned long address, int sig)
> {
> const struct exception_table_entry *entry;
> + unsigned long *stackend;
>
> /* Are we prepared to handle this fault? */
> if ((entry = search_exception_tables(regs->nip)) != NULL) {
> @@ -413,5 +415,9 @@ void bad_page_fault(struct pt_regs *regs
> printk(KERN_ALERT "Faulting instruction address: 0x%08lx\n",
> regs->nip);
>
> + stackend = end_of_stack(current);
> + if (current != &init_task && *stackend != STACK_END_MAGIC)
> + printk(KERN_ALERT "Thread overran stack, or stack corrupted\n");
The check for init is just because we haven't set the magic value for
init's stack right? But we could.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Benjamin Herrenschmidt @ 2010-08-25 1:30 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Andreas Schwab, kvm-ppc, Paul Mackerras
In-Reply-To: <32250.1282626925@neuling.org>
On Tue, 2010-08-24 at 15:15 +1000, Michael Neuling wrote:
> > > Do some 32 bit processors need this?
> > >
> > > In 32 bit before the merge, we use to have code that did:
> > >
> > > #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> > > #define cvt_fd without save/restore fpscr
> > > #else
> > > #define cvt_fd with save/restore fpscr
> > > #end if
> > >
> > > Kumar; does this ring any bells?
> >
> > I don't see anything in the various 440 docs I have at hand that would
> > hint at lfd/stfs adffecting FPSCR.
>
> The way the ifdefs are, it's the other way around. 4xx procs don't need
> to save/restore fpscr and others do.
Right, my bad. In any case, Paulus reckons it's all his mistake and we
really never need to save/restore fpscr.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Michael Neuling @ 2010-08-25 1:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andreas Schwab, kvm-ppc, Paul Mackerras
In-Reply-To: <1282699836.22370.566.camel@pasglop>
In message <1282699836.22370.566.camel@pasglop> you wrote:
> On Tue, 2010-08-24 at 15:15 +1000, Michael Neuling wrote:
> > > > Do some 32 bit processors need this?
> > > >
> > > > In 32 bit before the merge, we use to have code that did:
> > > >
> > > > #if defined(CONFIG_4xx) || defined(CONFIG_E500)
> > > > #define cvt_fd without save/restore fpscr
> > > > #else
> > > > #define cvt_fd with save/restore fpscr
> > > > #end if
> > > >
> > > > Kumar; does this ring any bells?
> > >
> > > I don't see anything in the various 440 docs I have at hand that would
> > > hint at lfd/stfs adffecting FPSCR.
> >
> > The way the ifdefs are, it's the other way around. 4xx procs don't need
> > to save/restore fpscr and others do.
>
> Right, my bad. In any case, Paulus reckons it's all his mistake and we
> really never need to save/restore fpscr.
ACK :-P
Mikey
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox