* [PATCH 1/2] [V2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
From: Mark Nelson @ 2007-10-12 2:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Paul Mackerras, Linux Kernel Mailing List
In-Reply-To: <470ECFF7.9040008@au1.ibm.com>
Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE in the coredump code which
allows for more flexibility in the note type for the state of 'extended
floating point' implementations in coredumps. New note types can now be
added with an appropriate #define.
This does #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all
current users so there's are no change in behaviour.
This will let us use different note types on powerpc for the
Altivec/VMX state that some PowerPC cpus have (G4, PPC970, POWER6) and
for the SPE (signal processing extension) state that some embedded
PowerPC cpus from Freescale have.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
arch/ia64/ia32/elfcore32.h | 1 +
arch/x86_64/ia32/ia32_binfmt.c | 1 +
fs/binfmt_elf.c | 8 ++++----
fs/binfmt_elf_fdpic.c | 6 +++---
include/asm-i386/elf.h | 1 +
5 files changed, 10 insertions(+), 7 deletions(-)
Index: linux/arch/ia64/ia32/elfcore32.h
===================================================================
--- linux.orig/arch/ia64/ia32/elfcore32.h
+++ linux/arch/ia64/ia32/elfcore32.h
@@ -117,6 +117,7 @@ elf_core_copy_task_fpregs(struct task_st
}
#define ELF_CORE_COPY_XFPREGS 1
+#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
static inline int
elf_core_copy_task_xfpregs(struct task_struct *tsk, elf_fpxregset_t *xfpu)
{
Index: linux/arch/x86_64/ia32/ia32_binfmt.c
===================================================================
--- linux.orig/arch/x86_64/ia32/ia32_binfmt.c
+++ linux/arch/x86_64/ia32/ia32_binfmt.c
@@ -188,6 +188,7 @@ elf_core_copy_task_fpregs(struct task_st
}
#define ELF_CORE_COPY_XFPREGS 1
+#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
static inline int
elf_core_copy_task_xfpregs(struct task_struct *t, elf_fpxregset_t *xfpu)
{
Index: linux/fs/binfmt_elf.c
===================================================================
--- linux.orig/fs/binfmt_elf.c
+++ linux/fs/binfmt_elf.c
@@ -1411,7 +1411,7 @@ struct elf_thread_status
elf_fpregset_t fpu; /* NT_PRFPREG */
struct task_struct *thread;
#ifdef ELF_CORE_COPY_XFPREGS
- elf_fpxregset_t xfpu; /* NT_PRXFPREG */
+ elf_fpxregset_t xfpu; /* ELF_CORE_XFPREG_TYPE */
#endif
struct memelfnote notes[3];
int num_notes;
@@ -1446,8 +1446,8 @@ static int elf_dump_thread_status(long s
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(p, &t->xfpu)) {
- fill_note(&t->notes[2], "LINUX", NT_PRXFPREG, sizeof(t->xfpu),
- &t->xfpu);
+ fill_note(&t->notes[2], "LINUX", ELF_CORE_XFPREG_TYPE,
+ sizeof(t->xfpu), &t->xfpu);
t->num_notes++;
sz += notesize(&t->notes[2]);
}
@@ -1624,7 +1624,7 @@ static int elf_core_dump(long signr, str
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(current, xfpu))
fill_note(notes + numnote++,
- "LINUX", NT_PRXFPREG, sizeof(*xfpu), xfpu);
+ "LINUX", ELF_CORE_XFPREG_TYPE, sizeof(*xfpu), xfpu);
#endif
fs = get_fs();
Index: linux/fs/binfmt_elf_fdpic.c
===================================================================
--- linux.orig/fs/binfmt_elf_fdpic.c
+++ linux/fs/binfmt_elf_fdpic.c
@@ -1417,7 +1417,7 @@ struct elf_thread_status
elf_fpregset_t fpu; /* NT_PRFPREG */
struct task_struct *thread;
#ifdef ELF_CORE_COPY_XFPREGS
- elf_fpxregset_t xfpu; /* NT_PRXFPREG */
+ elf_fpxregset_t xfpu; /* ELF_CORE_XFPREG_TYPE */
#endif
struct memelfnote notes[3];
int num_notes;
@@ -1453,7 +1453,7 @@ static int elf_dump_thread_status(long s
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(p, &t->xfpu)) {
- fill_note(&t->notes[2], "LINUX", NT_PRXFPREG, sizeof(t->xfpu),
+ fill_note(&t->notes[2], "LINUX", ELF_CORE_XFPREG_TYPE, sizeof(t->xfpu),
&t->xfpu);
t->num_notes++;
sz += notesize(&t->notes[2]);
@@ -1690,7 +1690,7 @@ static int elf_fdpic_core_dump(long sign
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(current, xfpu))
fill_note(notes + numnote++,
- "LINUX", NT_PRXFPREG, sizeof(*xfpu), xfpu);
+ "LINUX", ELF_CORE_XFPREG_TYPE, sizeof(*xfpu), xfpu);
#endif
fs = get_fs();
Index: linux/include/asm-i386/elf.h
===================================================================
--- linux.orig/include/asm-i386/elf.h
+++ linux/include/asm-i386/elf.h
@@ -129,6 +129,7 @@ extern int dump_task_extended_fpu (struc
#define ELF_CORE_COPY_TASK_REGS(tsk, elf_regs) dump_task_regs(tsk, elf_regs)
#define ELF_CORE_COPY_FPREGS(tsk, elf_fpregs) dump_task_fpu(tsk, elf_fpregs)
#define ELF_CORE_COPY_XFPREGS(tsk, elf_xfpregs) dump_task_extended_fpu(tsk, elf_xfpregs)
+#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
#define VDSO_HIGH_BASE (__fix_to_virt(FIX_VDSO))
#define VDSO_CURRENT_BASE ((unsigned long)current->mm->context.vdso)
^ permalink raw reply
* Re: [patch 1/2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
From: Mark Nelson @ 2007-10-12 1:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Linux Kernel Mailing List
In-Reply-To: <DFC6881D-E917-4EC5-B19C-8CE04E040B06@kernel.crashing.org>
Kumar Gala wrote:
>
> On Oct 11, 2007, at 2:15 AM, markn@au1.ibm.com wrote:
>
>> Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE in the coredump code which
>> allows for more flexibility in the note type for the state of 'extended
>> floating point' implementations in coredumps. New note types can now be
>> added with an appropriate #define.
>>
>> #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all current users so
>> there's are no change in behaviour.
>
> Can we make this ELF_CORE_VECREG_TYPE or something that is so coupled to
> the x86 specific name?
>
>>
>> Signed-off-by: Mark Nelson <markn@au1.ibm.com>
>> ---
>> arch/ia64/ia32/elfcore32.h | 1 +
>> arch/x86_64/ia32/ia32_binfmt.c | 1 +
>> fs/binfmt_elf.c | 4 ++--
>> include/asm-i386/elf.h | 1 +
>> 4 files changed, 5 insertions(+), 2 deletions(-)
>>
>> Index: linux/arch/ia64/ia32/elfcore32.h
>> ===================================================================
>> --- linux.orig/arch/ia64/ia32/elfcore32.h
>> +++ linux/arch/ia64/ia32/elfcore32.h
>> @@ -117,6 +117,7 @@ elf_core_copy_task_fpregs(struct task_st
>> }
>>
>> #define ELF_CORE_COPY_XFPREGS 1
>> +#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
>> static inline int
>> elf_core_copy_task_xfpregs(struct task_struct *tsk, elf_fpxregset_t
>> *xfpu)
>> {
>> Index: linux/arch/x86_64/ia32/ia32_binfmt.c
>> ===================================================================
>> --- linux.orig/arch/x86_64/ia32/ia32_binfmt.c
>> +++ linux/arch/x86_64/ia32/ia32_binfmt.c
>> @@ -188,6 +188,7 @@ elf_core_copy_task_fpregs(struct task_st
>> }
>>
>> #define ELF_CORE_COPY_XFPREGS 1
>> +#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
>> static inline int
>> elf_core_copy_task_xfpregs(struct task_struct *t, elf_fpxregset_t *xfpu)
>> {
>> Index: linux/fs/binfmt_elf.c
>> ===================================================================
>> --- linux.orig/fs/binfmt_elf.c
>> +++ linux/fs/binfmt_elf.c
>> @@ -1446,8 +1446,8 @@ static int elf_dump_thread_status(long s
>>
>> #ifdef ELF_CORE_COPY_XFPREGS
>> if (elf_core_copy_task_xfpregs(p, &t->xfpu)) {
>> - fill_note(&t->notes[2], "LINUX", NT_PRXFPREG, sizeof(t->xfpu),
>> - &t->xfpu);
>> + fill_note(&t->notes[2], "LINUX", ELF_CORE_XFPREG_TYPE,
>> + sizeof(t->xfpu), &t->xfpu);
>> t->num_notes++;
>> sz += notesize(&t->notes[2]);
>> }
>
> You've only fixed up one of 4 NT_PRXFPREG uses in the kernel.
Ooops... Right you are - very good pickup :) Fixed in a new version (will send promptly).
Thanks!
Mark.
>
> Also, I'm not a fan of your proposed mechanism to "overload" the
> elf_fpxregset_t. I'd rather see us introduce a new elf_vecregset_t and
> have it typedef'd to be elf_fpxregset_t on i386, x86_64, ia64
>
>> Index: linux/include/asm-i386/elf.h
>> ===================================================================
>> --- linux.orig/include/asm-i386/elf.h
>> +++ linux/include/asm-i386/elf.h
>> @@ -129,6 +129,7 @@ extern int dump_task_extended_fpu (struc
>> #define ELF_CORE_COPY_TASK_REGS(tsk, elf_regs) dump_task_regs(tsk,
>> elf_regs)
>> #define ELF_CORE_COPY_FPREGS(tsk, elf_fpregs) dump_task_fpu(tsk,
>> elf_fpregs)
>> #define ELF_CORE_COPY_XFPREGS(tsk, elf_xfpregs)
>> dump_task_extended_fpu(tsk, elf_xfpregs)
>> +#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
>>
>> #define VDSO_HIGH_BASE (__fix_to_virt(FIX_VDSO))
>> #define VDSO_CURRENT_BASE ((unsigned long)current->mm->context.vdso)
>>
>> --
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Switch to generic WARN_ON()/BUG_ON()
From: Paul Mackerras @ 2007-10-12 1:23 UTC (permalink / raw)
To: Olof Johansson; +Cc: grundler, linux-kernel, kyle, linuxppc-dev, lethal, akpm
In-Reply-To: <20071011171413.GC10877@lixom.net>
Olof Johansson writes:
> Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
> 4K text on a ppc64_defconfig. The main reason seems to be that prepping
> the arguments to the conditional trap instructions is more work than
> just doing a compare and branch.
It might be more instructions but it takes fewer cycles, I would
expect. Do you have the actual instruction sequences to compare?
Paul.
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Michael Ellerman @ 2007-10-12 0:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18190.49302.918402.952580@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 706 bytes --]
On Fri, 2007-10-12 at 10:32 +1000, Paul Mackerras wrote:
> Michael Ellerman writes:
>
> > Anything wrong with my patch "Fail early in lmb_remove_region()", it
> > generated no comment ..
>
> Just seems a little unnecessary given that the function in question is
> static, that's all...
Yeah true. I figured it was nice to have it spelled out in the code that
the routine is only valid for certain values of r - but I'm not fussed.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v3] powerpc: Implement logging of unhandled signals
From: Olof Johansson @ 2007-10-12 0:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1192148469.8476.64.camel@pasglop>
On Fri, Oct 12, 2007 at 10:21:09AM +1000, Benjamin Herrenschmidt wrote:
>
> On Thu, 2007-10-11 at 19:20 -0500, Olof Johansson wrote:
> > Implement show_unhandled_signals sysctl + support to print when a process
> > is killed due to unhandled signals just as i386 and x86_64 does.
> >
> > Default to having it off, unlike x86 that defaults on.
>
> Why ? I'd like it on by default :-)
Paulus mentioned on IRC that he preferred it that way. I'll leave it up
to the two of you to argue it out. I'd prefer on by default but I don't
really care all that much as long as I can enable it with bootargs.
-Olof
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Paul Mackerras @ 2007-10-12 0:32 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1192148887.6274.10.camel@concordia>
Michael Ellerman writes:
> Anything wrong with my patch "Fail early in lmb_remove_region()", it
> generated no comment ..
Just seems a little unnecessary given that the function in question is
static, that's all...
Paul.
^ permalink raw reply
* Tx Command of MPC8280 hangs the kernel
From: suresh suresh @ 2007-10-12 0:28 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 148 bytes --]
Hi,
I am facing kernel hang when ATM Tx command is issued. I am using SUSE
linux. Does anyone have any idea why it is happening?
Regards,
Suresh
[-- Attachment #2: Type: text/html, Size: 243 bytes --]
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Michael Ellerman @ 2007-10-12 0:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18190.5965.836544.396721@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
On Thu, 2007-10-11 at 22:30 +1000, Paul Mackerras wrote:
> Below is the list of commits that I plan to ask Linus to pull
> tomorrow. This is the last call for anything else or for objections
> to any of these commits going in. These commits are in powerpc.git on
> the master and for-2.6.24 branches.
Anything wrong with my patch "Fail early in lmb_remove_region()", it
generated no comment ..
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=13883
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v3] powerpc: Implement logging of unhandled signals
From: Benjamin Herrenschmidt @ 2007-10-12 0:21 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071012002007.GA18188@lixom.net>
On Thu, 2007-10-11 at 19:20 -0500, Olof Johansson wrote:
> Implement show_unhandled_signals sysctl + support to print when a process
> is killed due to unhandled signals just as i386 and x86_64 does.
>
> Default to having it off, unlike x86 that defaults on.
Why ? I'd like it on by default :-)
Ben.
^ permalink raw reply
* IMA microcode for MPC8280
From: suresh suresh @ 2007-10-12 0:19 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 330 bytes --]
Hi,
I am trying to bring up IMA on the MPC8280 hardware.
I think IMA microcode is creating some problem while configuring IMA. When I
do IMA link configuration kernel hangs and I have to reset the hardware.
I had downloaded the microcode at correct internal RAMlocation. Please help
me to resolve this issue.
Regards,
Suresh
[-- Attachment #2: Type: text/html, Size: 523 bytes --]
^ permalink raw reply
* [PATCH v3] powerpc: Implement logging of unhandled signals
From: Olof Johansson @ 2007-10-12 0:20 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071002053512.GA21414@lixom.net>
Implement show_unhandled_signals sysctl + support to print when a process
is killed due to unhandled signals just as i386 and x86_64 does.
Default to having it off, unlike x86 that defaults on.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: 2.6.23/arch/powerpc/kernel/traps.c
===================================================================
--- 2.6.23.orig/arch/powerpc/kernel/traps.c
+++ 2.6.23/arch/powerpc/kernel/traps.c
@@ -172,11 +172,21 @@ int die(const char *str, struct pt_regs
void _exception(int signr, struct pt_regs *regs, int code, unsigned long addr)
{
siginfo_t info;
+ const char fmt32[] = KERN_INFO "%s[%d]: unhandled signal %d " \
+ "at %08lx nip %08lx lr %08lx code %x\n";
+ const char fmt64[] = KERN_INFO "%s[%d]: unhandled signal %d " \
+ "at %016lx nip %016lx lr %016lx code %x\n";
if (!user_mode(regs)) {
if (die("Exception in kernel mode", regs, signr))
return;
- }
+ } else if (show_unhandled_signals &&
+ unhandled_signal(current, signr) &&
+ printk_ratelimit()) {
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, signr,
+ addr, regs->nip, regs->link, code);
+ }
memset(&info, 0, sizeof(info));
info.si_signo = signr;
Index: 2.6.23/arch/powerpc/kernel/signal_64.c
===================================================================
--- 2.6.23.orig/arch/powerpc/kernel/signal_64.c
+++ 2.6.23/arch/powerpc/kernel/signal_64.c
@@ -64,6 +64,11 @@ struct rt_sigframe {
char abigap[288];
} __attribute__ ((aligned (16)));
+static const char fmt32[] = KERN_INFO \
+ "%s[%d]: bad frame in %s: %08lx nip %08lx lr %08lx\n";
+static const char fmt64[] = KERN_INFO \
+ "%s[%d]: bad frame in %s: %016lx nip %016lx lr %016lx\n";
+
/*
* Set up the sigcontext for the signal frame.
*/
@@ -315,6 +320,11 @@ badframe:
printk("badframe in sys_rt_sigreturn, regs=%p uc=%p &uc->uc_mcontext=%p\n",
regs, uc, &uc->uc_mcontext);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, "rt_sigreturn",
+ (long)uc, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
return 0;
}
@@ -398,6 +408,11 @@ badframe:
printk("badframe in setup_rt_frame, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, "setup_rt_frame",
+ (long)frame, regs->nip, regs->link);
+
force_sigsegv(signr, current);
return 0;
}
Index: 2.6.23/kernel/sysctl.c
===================================================================
--- 2.6.23.orig/kernel/sysctl.c
+++ 2.6.23/kernel/sysctl.c
@@ -1221,7 +1221,7 @@ static ctl_table fs_table[] = {
};
static ctl_table debug_table[] = {
-#ifdef CONFIG_X86
+#if defined(CONFIG_X86) || defined(CONFIG_PPC)
{
.ctl_name = CTL_UNNUMBERED,
.procname = "exception-trace",
Index: 2.6.23/arch/powerpc/kernel/signal_32.c
===================================================================
--- 2.6.23.orig/arch/powerpc/kernel/signal_32.c
+++ 2.6.23/arch/powerpc/kernel/signal_32.c
@@ -705,11 +705,13 @@ int handle_rt_signal32(unsigned long sig
{
struct rt_sigframe __user *rt_sf;
struct mcontext __user *frame;
+ void __user *addr;
unsigned long newsp = 0;
/* Set up Signal Frame */
/* Put a Real Time Context onto stack */
rt_sf = get_sigframe(ka, regs, sizeof(*rt_sf));
+ addr = rt_sf;
if (unlikely(rt_sf == NULL))
goto badframe;
@@ -728,6 +730,7 @@ int handle_rt_signal32(unsigned long sig
/* Save user registers on the stack */
frame = &rt_sf->uc.uc_mcontext;
+ addr = frame;
if (vdso32_rt_sigtramp && current->mm->context.vdso_base) {
if (save_user_regs(regs, frame, 0))
goto badframe;
@@ -742,6 +745,7 @@ int handle_rt_signal32(unsigned long sig
/* create a stack frame for the caller of the handler */
newsp = ((unsigned long)rt_sf) - (__SIGNAL_FRAMESIZE + 16);
+ addr = (void __user *)regs->gpr[1];
if (put_user(regs->gpr[1], (u32 __user *)newsp))
goto badframe;
@@ -762,6 +766,12 @@ badframe:
printk("badframe in handle_rt_signal, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in handle_rt_signal32: "
+ "%p nip %08lx lr %08lx\n",
+ current->comm, current->pid,
+ addr, regs->nip, regs->link);
+
force_sigsegv(sig, current);
return 0;
}
@@ -886,6 +896,12 @@ long sys_rt_sigreturn(int r3, int r4, in
return 0;
bad:
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in sys_rt_sigreturn: "
+ "%p nip %08lx lr %08lx\n",
+ current->comm, current->pid,
+ rt_sf, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
return 0;
}
@@ -967,6 +983,13 @@ int sys_debug_setcontext(struct ucontext
* We kill the task with a SIGSEGV in this situation.
*/
if (do_setcontext(ctx, regs, 1)) {
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in "
+ "sys_debug_setcontext: %p nip %08lx "
+ "lr %08lx\n",
+ current->comm, current->pid,
+ ctx, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
goto out;
}
@@ -1048,6 +1071,12 @@ badframe:
printk("badframe in handle_signal, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in handle_signal32: "
+ "%p nip %08lx lr %08lx\n",
+ current->comm, current->pid,
+ frame, regs->nip, regs->link);
+
force_sigsegv(sig, current);
return 0;
}
@@ -1061,12 +1090,14 @@ long sys_sigreturn(int r3, int r4, int r
struct sigcontext __user *sc;
struct sigcontext sigctx;
struct mcontext __user *sr;
+ void __user *addr;
sigset_t set;
/* Always make any pending restarted system calls return -EINTR */
current_thread_info()->restart_block.fn = do_no_restart_syscall;
sc = (struct sigcontext __user *)(regs->gpr[1] + __SIGNAL_FRAMESIZE);
+ addr = sc;
if (copy_from_user(&sigctx, sc, sizeof(sigctx)))
goto badframe;
@@ -1083,6 +1114,7 @@ long sys_sigreturn(int r3, int r4, int r
restore_sigmask(&set);
sr = (struct mcontext __user *)from_user_ptr(sigctx.regs);
+ addr = sr;
if (!access_ok(VERIFY_READ, sr, sizeof(*sr))
|| restore_user_regs(regs, sr, 1))
goto badframe;
@@ -1091,6 +1123,12 @@ long sys_sigreturn(int r3, int r4, int r
return 0;
badframe:
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in sys_sigreturn: "
+ "%p nip %08lx lr %08lx\n",
+ current->comm, current->pid,
+ addr, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
return 0;
}
Index: 2.6.23/arch/powerpc/kernel/signal.c
===================================================================
--- 2.6.23.orig/arch/powerpc/kernel/signal.c
+++ 2.6.23/arch/powerpc/kernel/signal.c
@@ -16,6 +16,12 @@
#include "signal.h"
+/* Log an error when sending an unhandled signal to a process. Controlled
+ * through debug.exception-trace sysctl.
+ */
+
+int show_unhandled_signals = 0;
+
/*
* Allocate space for the signal frame
*/
^ permalink raw reply
* Re: [PATCH v2] Fix regression. Make hot unlplug of CPU0 work again.
From: Michael Ellerman @ 2007-10-11 23:33 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Paul Mackerras, Milton Miller
In-Reply-To: <20071011073040.GD9814@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]
On Thu, 2007-10-11 at 17:30 +1000, Tony Breeds wrote:
> Early in the 2.6.23 cycle we broke the ability to offline cpu0
> (7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by
> ensuring that the (xics) default irq server, will not be 0 when taking
> cpu0 offline.
>
> Also catches a use of irq, when virq should be used (I think that's the
> last one).
>
> This patch also include the fix from Milton which makes JS21 work
> aswell. In the commit message for that patch Milton writes:
> xics_set_affinity no longer looks at the cpu_mask arg, instead
> get_irq_server reads it from the irq descriptor.
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> Signed-off-by: Milton Miller <miltonm@bga.com>
>
> ---
> Milton also says in his patch:
> > A more complete fix might be to pass the cpu_mask struct to get_irq_server,
> > but kernel/irq/manage.c currently sets the descriptor first.
>
> arch/powerpc/platforms/pseries/xics.c | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
> index f0b5ff1..217ae5d 100644
> --- a/arch/powerpc/platforms/pseries/xics.c
> +++ b/arch/powerpc/platforms/pseries/xics.c
> @@ -837,6 +837,15 @@ void xics_migrate_irqs_away(void)
> /* Allow IPIs again... */
> xics_set_cpu_priority(cpu, DEFAULT_PRIORITY);
>
> + /* It would be bad to migrate any IRQs to the CPU we're taking down */
> + if (default_server == cpu) {
> + unsigned int new_server = first_cpu(cpu_online_map);
> +
> + default_server = get_hard_smp_processor_id(new_server);
> + printk(KERN_WARNING "%s: default server was %d, reset to %d\n",
> + __func__, cpu, default_server);
WARNING? It's not like the user can do anything about it.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 1/2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
From: Michael Ellerman @ 2007-10-11 23:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Linux Kernel Mailing List
In-Reply-To: <DFC6881D-E917-4EC5-B19C-8CE04E040B06@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]
On Thu, 2007-10-11 at 08:04 -0500, Kumar Gala wrote:
> On Oct 11, 2007, at 2:15 AM, markn@au1.ibm.com wrote:
>
> > Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE in the coredump code
> > which
> > allows for more flexibility in the note type for the state of
> > 'extended
> > floating point' implementations in coredumps. New note types can
> > now be
> > added with an appropriate #define.
> >
> > #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all current users so
> > there's are no change in behaviour.
>
> Can we make this ELF_CORE_VECREG_TYPE or something that is so coupled
> to the x86 specific name?
>
> >
> > Signed-off-by: Mark Nelson <markn@au1.ibm.com>
> > ---
> > arch/ia64/ia32/elfcore32.h | 1 +
> > arch/x86_64/ia32/ia32_binfmt.c | 1 +
> > fs/binfmt_elf.c | 4 ++--
> > include/asm-i386/elf.h | 1 +
> > 4 files changed, 5 insertions(+), 2 deletions(-)
> >
> > Index: linux/arch/ia64/ia32/elfcore32.h
> > ===================================================================
> > --- linux.orig/arch/ia64/ia32/elfcore32.h
> > +++ linux/arch/ia64/ia32/elfcore32.h
> > @@ -117,6 +117,7 @@ elf_core_copy_task_fpregs(struct task_st
> > }
> >
> > #define ELF_CORE_COPY_XFPREGS 1
> > +#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
> > static inline int
> > elf_core_copy_task_xfpregs(struct task_struct *tsk,
> > elf_fpxregset_t *xfpu)
> > {
> > Index: linux/arch/x86_64/ia32/ia32_binfmt.c
> > ===================================================================
> > --- linux.orig/arch/x86_64/ia32/ia32_binfmt.c
> > +++ linux/arch/x86_64/ia32/ia32_binfmt.c
> > @@ -188,6 +188,7 @@ elf_core_copy_task_fpregs(struct task_st
> > }
> >
> > #define ELF_CORE_COPY_XFPREGS 1
> > +#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
> > static inline int
> > elf_core_copy_task_xfpregs(struct task_struct *t, elf_fpxregset_t
> > *xfpu)
> > {
> > Index: linux/fs/binfmt_elf.c
> > ===================================================================
> > --- linux.orig/fs/binfmt_elf.c
> > +++ linux/fs/binfmt_elf.c
> > @@ -1446,8 +1446,8 @@ static int elf_dump_thread_status(long s
> >
> > #ifdef ELF_CORE_COPY_XFPREGS
> > if (elf_core_copy_task_xfpregs(p, &t->xfpu)) {
> > - fill_note(&t->notes[2], "LINUX", NT_PRXFPREG, sizeof(t->xfpu),
> > - &t->xfpu);
> > + fill_note(&t->notes[2], "LINUX", ELF_CORE_XFPREG_TYPE,
> > + sizeof(t->xfpu), &t->xfpu);
> > t->num_notes++;
> > sz += notesize(&t->notes[2]);
> > }
>
> You've only fixed up one of 4 NT_PRXFPREG uses in the kernel.
>
> Also, I'm not a fan of your proposed mechanism to "overload" the
> elf_fpxregset_t. I'd rather see us introduce a new elf_vecregset_t
> and have it typedef'd to be elf_fpxregset_t on i386, x86_64, ia64
He's not overloading it, there is no such thing as an elf_fpxregset_t,
unless it's typedef'd to something else by the arch code, eg:
include/asm-i386/elf.h:typedef struct user_fxsr_struct elf_fpxregset_t;
include/asm-ia64/elf.h:typedef unsigned long elf_fpxregset_t;
Introducing another typedef would just be another layer of obfuscation
IMO, and the elf code doesn't need any more of that.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Kumar Gala @ 2007-10-11 22:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18190.42074.495464.74585@cargo.ozlabs.ibm.com>
On Oct 11, 2007, at 5:31 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> I'm debugging one issue with MPC8560 that should get fixed today with
>> a new pull request after I find the issue.
>
> There's no particular hurry for bug fixes.
Already dealt with, mainly I was being stupid.
>> Just to clarify, are we closing 2.6.24 for new code after you send
>> Linus a pull request or are we still taking things during the two
>> week merge window?
>
> Basically, yes. We got a lecture at kernel summit from Linus and
> Andrew where we got told to get everything merged early in the merge
> window. I might make an exception for stuff that has already been
> posted for review but still needs some minor changes, but other than
> that, the window for new code has closed.
I was wondering about this case. I'll follow your lead here.
- k
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Paul Mackerras @ 2007-10-11 22:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <3A203D25-2CC1-4450-ADA1-752A99504108@kernel.crashing.org>
Kumar Gala writes:
> I'm debugging one issue with MPC8560 that should get fixed today with
> a new pull request after I find the issue.
There's no particular hurry for bug fixes.
> Just to clarify, are we closing 2.6.24 for new code after you send
> Linus a pull request or are we still taking things during the two
> week merge window?
Basically, yes. We got a lecture at kernel summit from Linus and
Andrew where we got told to get everything merged early in the merge
window. I might make an exception for stuff that has already been
posted for review but still needs some minor changes, but other than
that, the window for new code has closed.
Paul.
^ permalink raw reply
* Re: [PATCH] Make clockevents work on PPC601 processors
From: Paul Mackerras @ 2007-10-11 22:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <96C1AFB8-784F-445E-A3F2-5D68494541CD@kernel.crashing.org>
Kumar Gala writes:
> do you still have a 601 running somewhere?
Yes, I still have the original 601 cpu card for my PowerMac 7500. :)
Paul.
^ permalink raw reply
* Re: [patch 1/2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
From: Paul Mackerras @ 2007-10-11 22:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Linux Kernel Mailing List
In-Reply-To: <2C31F1C3-3337-483B-A463-767459305F1E@kernel.crashing.org>
Kumar Gala writes:
> > ELF_CORE_XFPREG_TYPE is a suitable name for something that's used in
> > conjunction with a function called elf_core_copy_task_xfpregs().
>
> agreed, I think the function name should change as well.
Maybe. Let's do one step at a time...
Paul.
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Josh Boyer @ 2007-10-11 22:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1192106826.5534.114.camel@localhost.localdomain>
On Thu, 2007-10-11 at 07:47 -0500, Josh Boyer wrote:
> On Thu, 2007-10-11 at 22:30 +1000, Paul Mackerras wrote:
> > Below is the list of commits that I plan to ask Linus to pull
> > tomorrow. This is the last call for anything else or for objections
> > to any of these commits going in. These commits are in powerpc.git on
> > the master and for-2.6.24 branches.
>
> Hi Paul,
>
> Could you pull from:
>
> master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.24
>
> to pick up some Xilinx changes from Grant? I'm also hoping to get
> Stefan's 405EX changes in soon.
I added Stefan's latest patch set to my tree as well. They look good.
josh
^ permalink raw reply
* Re: [patch 1/2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
From: Kumar Gala @ 2007-10-11 22:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: PowerPC dev list, Linux Kernel Mailing List
In-Reply-To: <18190.39864.4562.852292@cargo.ozlabs.ibm.com>
On Oct 11, 2007, at 4:55 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>>> #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all current
>>> users so
>>> there's are no change in behaviour.
>>
>> Can we make this ELF_CORE_VECREG_TYPE or something that is so coupled
>> to the x86 specific name?
>
> How is "extended floating point registers" x86-specific?
we'll I don't consider the altivec register file as 'extended fp'.
I'm assuming the name XFP came from IA32 land when MMX/SSE came into
existence.
> ELF_CORE_XFPREG_TYPE is a suitable name for something that's used in
> conjunction with a function called elf_core_copy_task_xfpregs().
agreed, I think the function name should change as well.
- k
^ permalink raw reply
* Re: [patch 1/2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
From: Paul Mackerras @ 2007-10-11 21:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Linux Kernel Mailing List
In-Reply-To: <DFC6881D-E917-4EC5-B19C-8CE04E040B06@kernel.crashing.org>
Kumar Gala writes:
> > #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all current users so
> > there's are no change in behaviour.
>
> Can we make this ELF_CORE_VECREG_TYPE or something that is so coupled
> to the x86 specific name?
How is "extended floating point registers" x86-specific?
ELF_CORE_XFPREG_TYPE is a suitable name for something that's used in
conjunction with a function called elf_core_copy_task_xfpregs().
Paul.
^ permalink raw reply
* [RFC] Fixup stfiwx decode bug
From: Kumar Gala @ 2007-10-11 21:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Paul,
Can you look over this fix and see if you have any style issues with it.
Its legal for stfiwx to have RA = 0, however we treated it as illegal
since it was in class "XE".
- k
diff --git a/arch/powerpc/math-emu/math.c b/arch/powerpc/math-emu/math.c
index 69058b2..381306b 100644
--- a/arch/powerpc/math-emu/math.c
+++ b/arch/powerpc/math-emu/math.c
@@ -407,11 +407,16 @@ do_mathemu(struct pt_regs *regs)
case XE:
idx = (insn >> 16) & 0x1f;
- if (!idx)
- goto illegal;
-
op0 = (void *)¤t->thread.fpr[(insn >> 21) & 0x1f];
- op1 = (void *)(regs->gpr[idx] + regs->gpr[(insn >> 11) & 0x1f]);
+ if (!idx) {
+ if (((insn >> 1) & 0x3ff) == STFIWX)
+ op1 = (void *)(regs->gpr[(insn >> 11) & 0x1f]);
+ else
+ goto illegal;
+ } else {
+ op1 = (void *)(regs->gpr[idx] + regs->gpr[(insn >> 11) & 0x1f]);
+ }
+
break;
case XEU:
^ permalink raw reply related
* Re: [PATCH v4 or so] Use 1TB segments
From: Paul Mackerras @ 2007-10-11 21:52 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Jon Tollefson, Will Schmidt
In-Reply-To: <20071011163358.GA4258@austin.ibm.com>
Linas Vepstas writes:
> Gack. A system dump might take a while on these machines ...
Why? Using 1TB segments doesn't mean they have 1TB of RAM ...
Paul.
^ permalink raw reply
* Re: [PATCH v2] powerpc: don't enable cpu hotplug on mpic-based pseries
From: Milton Miller @ 2007-10-11 21:42 UTC (permalink / raw)
Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <18189.47620.466515.645055@cargo.ozlabs.ibm.com>
Paul Mackerras writes:
> Olof Johansson writes:
>> Don't allow cpu hotplug on systems lacking XICS interrupt controller,
>> since current code is hardcoded for it.
> ...
>> + for (np = NULL; (np = of_find_node_by_name(np,
>> + "interrupt-controller"));) {
>
> Looks like for_each_node_by_name would be nicer here.
>
> If you agree, I'll hand-edit your patch to do that and apply it. Of
> course, ultimately we should implement the necessary mpic bits to
> support cpu hotplug.
>
While you are editing, can you please change the condition to finding
ppc-xicp instead of not finding open-pic?
thanks.
milton
^ permalink raw reply
* Re: Hard hang in hypervisor!?
From: Milton Miller @ 2007-10-11 21:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18189.26776.326248.278431@cargo.ozlabs.ibm.com>
On Thu Oct 11 10:04:40 EST 2007, Paul Mackerras wrote:
> Linas Vepstas writes:
>> Err .. it was cpu 0 that was spinlocked. Are interrupts not
>> distributed?
>
> We have some bogosities in the xics code that I noticed a couple of
> days ago. Basically we only set the xics to distribute interrupts to
> all cpus if (a) the affinity mask is equal to CPU_MASK_ALL (which has
> ones in every bit position from 0 to NR_CPUS-1) and (b) all present
> cpus are online (cpu_online_map == cpu_present_map). Otherwise we
> direct interrupts to the first cpu in the affinity map. So you can
> easily have the affinity mask containing all the online cpus and still
> not get distributed interrupts.
The second condition was just added to try fix some issues where a
vendor wants to always run the kdump kernel with maxcpus=1 on all
architectures, and the emulated xics on js20 was not working.
For a true xics, this should work because we (1) remove all but 1
cpu from the global server list and (2) raise the prioirity of the
cpu to disabled and the hardware will deliver to another cpu in the
parition.
http://ozlabs.org/pipermail/linuxppc-dev/2006-December/028941.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-January/029607.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-March/032621.html
However, my experience the other day on a js21 was that firmware
delivered either to all cpus (if we bound to the global server) or
the first online cpu in the partition, regardless of to which cpu
we bound the interrupt, so I don't know that the change will fix
the original problem.
It does mean that taking a cpu offline but not dlpar removing it from the
kernel will result in the inability to actually distribute interrupts
to all cpus.
I'd be happy to say remove the extra check and work with firmware to
property distribute the interrupts.
milton
^ permalink raw reply
* Re: [PATCH 4/4 v2] [POWERPC] Kilauea defconfig file
From: Josh Boyer @ 2007-10-11 21:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071011201232.GD4247@loki.buserror.net>
On Thu, 2007-10-11 at 15:12 -0500, Scott Wood wrote:
> On Thu, Oct 11, 2007 at 03:31:12PM +0200, Stefan Roese wrote:
> > Yes, good catch. Since I'm not using the bootwrapper, I should be able to get
> > rid of WANT_DEVICE_TREE too. But it seems to be autoselected in
> > arch/powerpc/platforms/Kconfig.cputype for 40x and most other "embedded"
> > CPU's. Any idea why this is the case?
>
> Probably copying from 83xx, 85xx, etc, which set it on the entire CPU family
> because there's a wrapper platform that covers the entire family. AFAICT,
> there are only board wrappers for 4xx, so individual boards should be
> selecting WANT_DEVICE_TREE.
Probably. Seems somewhat redundant at this point to move it into the
individual board options though.
> In any case, you can just set DEVICE_TREE to an empty string if you only
> want the regular uImage.
Well, he wants the raw uImage, and a separate DTB to be spit out as far
as I can tell. So we don't want an empty string here, but what's there
currently doesn't do the latter part either.
josh
^ 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