* 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
* 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: 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: 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: [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: 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: 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: [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: [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
* [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
* 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
* 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
* 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
* 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: 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
* 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: 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 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: [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
* [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 2/2] powerpc: Switch to generic WARN_ON()/BUG_ON()
From: Kyle McMartin @ 2007-10-12 2:04 UTC (permalink / raw)
To: Paul Mackerras
Cc: grundler, linux-kernel, kyle, linuxppc-dev, lethal,
Olof Johansson, akpm
In-Reply-To: <18190.52379.97647.468384@cargo.ozlabs.ibm.com>
On Fri, Oct 12, 2007 at 11:23:39AM +1000, Paul Mackerras wrote:
> 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?
>
I really hope WARN_ON/BUG_ON aren't hotpaths on powerpc. ;-)
Cheers,
Kyle
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Switch to generic WARN_ON()/BUG_ON()
From: Olof Johansson @ 2007-10-12 2:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: grundler, linux-kernel, kyle, linuxppc-dev, lethal, akpm
In-Reply-To: <18190.52379.97647.468384@cargo.ozlabs.ibm.com>
On Fri, Oct 12, 2007 at 11:23:39AM +1000, Paul Mackerras wrote:
> 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?
Sure. Just looking at a couple of cases:
On range comparisons such as (a < CONST):
* without this patch, you end up with a comparison, then a cr-to-cr op +
mfcr + mask operation + tdnei.
* with the patch, you get a comparison and a conditional branch with
twi out of line.
On multiple comparisons like WARN_ON( a || b), it seems that there's an
added li to make the tdnei always hit for the first case. There it uses
a regular conditional branch, so no real difference in generated code
besides that.
Code examples. This was with a ppc64_defconfig, so CONFIG_POWER4_ONLY
wasn't enabled. It uses mfocrf when it is, which is alot cheaper. Still,
the rest of the code sequence is the same:
void irq_free_virt(unsigned int virq, unsigned int count)
{
unsigned long flags;
unsigned int i;
WARN_ON (virq < NUM_ISA_INTERRUPTS);
WARN_ON (count == 0 || (virq + count) > irq_virq_count);
spin_lock_irqsave(&irq_big_lock, flags);
Without the patch:
c00000000000b33c <.irq_free_virt>:
c00000000000b33c: 7c 08 02 a6 mflr r0
c00000000000b340: 2b 83 00 0f cmplwi cr7,r3,15
c00000000000b344: fb c1 ff f0 std r30,-16(r1)
c00000000000b348: fb e1 ff f8 std r31,-8(r1)
c00000000000b34c: 7c 9e 23 78 mr r30,r4
c00000000000b350: 7c 7f 1b 78 mr r31,r3
c00000000000b354: 4f dd e8 42 crnot 4*cr7+eq,4*cr7+gt
c00000000000b358: f8 01 00 10 std r0,16(r1)
c00000000000b35c: f8 21 ff 81 stdu r1,-128(r1)
c00000000000b360: 7c 00 00 26 mfcr r0
c00000000000b364: 54 00 ff fe rlwinm r0,r0,31,31,31
c00000000000b368: 0b 00 00 00 tdnei r0,0
c00000000000b36c: 2f a4 00 00 cmpdi cr7,r4,0
c00000000000b370: 38 00 00 01 li r0,1
c00000000000b374: 41 9e 00 1c beq cr7,c00000000000b390 <.irq_free_virt+0x54>
c00000000000b378: e9 22 80 d8 ld r9,-32552(r2)
c00000000000b37c: 7d 63 22 14 add r11,r3,r4
c00000000000b380: 80 09 00 00 lwz r0,0(r9)
c00000000000b384: 7f 8b 00 40 cmplw cr7,r11,r0
c00000000000b388: 7c 00 00 26 mfcr r0
c00000000000b38c: 54 00 f7 fe rlwinm r0,r0,30,31,31
c00000000000b390: 0b 00 00 00 tdnei r0,0
c00000000000b394: e8 62 80 f8 ld r3,-32520(r2)
c00000000000b398: 48 54 4c b1 bl c000000000550048 <._spin_lock_irqsave>
c00000000000b39c: 60 00 00 00 nop
With the patch:
c00000000000b0b0 <.irq_free_virt>:
c00000000000b0b0: 7c 08 02 a6 mflr r0
c00000000000b0b4: 2b 83 00 0f cmplwi cr7,r3,15
c00000000000b0b8: fb c1 ff f0 std r30,-16(r1)
c00000000000b0bc: fb e1 ff f8 std r31,-8(r1)
c00000000000b0c0: 7c 9e 23 78 mr r30,r4
c00000000000b0c4: 7c 7f 1b 78 mr r31,r3
c00000000000b0c8: f8 01 00 10 std r0,16(r1)
c00000000000b0cc: f8 21 ff 81 stdu r1,-128(r1)
c00000000000b0d0: 41 bd 00 08 bgt cr7,c00000000000b0d8 <.irq_free_virt+0x28>
c00000000000b0d4: 0f e0 00 00 twi 31,r0,0
c00000000000b0d8: 2f be 00 00 cmpdi cr7,r30,0
c00000000000b0dc: 41 9e 00 18 beq cr7,c00000000000b0f4 <.irq_free_virt+0x44>
c00000000000b0e0: e9 22 80 d8 ld r9,-32552(r2)
c00000000000b0e4: 7d 7f f2 14 add r11,r31,r30
c00000000000b0e8: 80 09 00 00 lwz r0,0(r9)
c00000000000b0ec: 7f 8b 00 40 cmplw cr7,r11,r0
c00000000000b0f0: 40 bd 00 08 ble cr7,c00000000000b0f8 <.irq_free_virt+0x48>
c00000000000b0f4: 0f e0 00 00 twi 31,r0,0
c00000000000b0f8: e8 62 80 f8 ld r3,-32520(r2)
c00000000000b0fc: 48 54 3f 75 bl c00000000054f070 <._spin_lock_irqsave>
c00000000000b100: 60 00 00 00 nop
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Switch to generic WARN_ON()/BUG_ON()
From: Olof Johansson @ 2007-10-12 2:41 UTC (permalink / raw)
To: Kyle McMartin
Cc: grundler, linux-kernel, kyle, linuxppc-dev, lethal,
Paul Mackerras, akpm
In-Reply-To: <20071012020419.GB19268@fattire.cabal.ca>
On Thu, Oct 11, 2007 at 10:04:19PM -0400, Kyle McMartin wrote:
> On Fri, Oct 12, 2007 at 11:23:39AM +1000, Paul Mackerras wrote:
> > 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?
> >
>
> I really hope WARN_ON/BUG_ON aren't hotpaths on powerpc. ;-)
Not the taken branch of them, no. :) But making it past them as fast
as possible when they're not tripping is always good.
-Olof
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: David Gibson @ 2007-10-12 2:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18190.5965.836544.396721@cargo.ozlabs.ibm.com>
One more for you. This is preparation for the libfdt merge.
Add memchr() to the bootwrapper
This patch adds a memchr() implementation to the bootwrapper. libfdt
will need this.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/arch/powerpc/boot/string.S
===================================================================
--- working-2.6.orig/arch/powerpc/boot/string.S 2007-09-27 18:36:21.000000000 +1000
+++ working-2.6/arch/powerpc/boot/string.S 2007-09-27 18:40:24.000000000 +1000
@@ -219,6 +219,19 @@ backwards_memcpy:
mtctr r7
b 1b
+ .globl memchr
+memchr:
+ cmpwi 0,r5,0
+ blelr
+ mtctr r5
+ addi r3,r3,-1
+1: lbzu r0,1(r3)
+ cmpw r0,r4
+ beqlr
+ bdnz 1b
+ li r3,0
+ blr
+
.globl memcmp
memcmp:
cmpwi 0,r5,0
Index: working-2.6/arch/powerpc/boot/string.h
===================================================================
--- working-2.6.orig/arch/powerpc/boot/string.h 2007-09-27 18:40:27.000000000 +1000
+++ working-2.6/arch/powerpc/boot/string.h 2007-09-27 18:40:58.000000000 +1000
@@ -14,6 +14,7 @@ extern size_t strnlen(const char *s, siz
extern void *memset(void *s, int c, size_t n);
extern void *memmove(void *dest, const void *src, unsigned long n);
extern void *memcpy(void *dest, const void *src, unsigned long n);
+extern void *memchr(const void *s, int c, size_t n);
extern int memcmp(const void *s1, const void *s2, size_t n);
#endif /* _PPC_BOOT_STRING_H_ */
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] PowerPC: Fix find_legacy_serial_ports on OPB.
From: David Gibson @ 2007-10-12 2:31 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <1192127513.5534.127.camel@localhost.localdomain>
On Thu, Oct 11, 2007 at 01:31:53PM -0500, Josh Boyer wrote:
> On Thu, 2007-10-11 at 21:26 +0400, Valentine Barshak wrote:
> > Josh Boyer wrote:
> > > On Thu, 2007-10-11 at 17:50 +0200, Arnd Bergmann wrote:
> > >> On Thursday 11 October 2007, Valentine Barshak wrote:
> > >>> Currently find_legacy_serial_ports() can find no serial ports on the OPB.
> > >>> Thus no legacy boot console can be initialized. Just the early udbg console
> > >>> works, which is initialized with udbg_init_44x_as1() on the UART's physical
> > >>> address specified in kernel config. This happens because we look for ns16750
> > >>> and higher serial devices only and expect opb node to have a device type
> > >>> property. This patch makes it look for ns16550 compatible devices and use
> > >>> of_device_is_compatible() for opb instead of checking device type.
> > >>> Lack of legacy serial ports found causes problems for KGDB over serial.
> > >>>
> > >>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> > >> The patch would make sense if we were only dealing with flattened device
> > >> tree systems at this point. Unfortunately, IBM is shipping hardware that
> > >> encodes the serial port in exactly the way that find_legacy_serial_ports
> > >> is looking for (parent->type == "opb", compatible = "ns16750" "ns16550"
> > >> "ns16450" i8250").
> > >>
> > >> Changing the search for ns16750 to ns16550 should be fine, but unnecessary
> > >> because AFAIK, all OPB serial imlpementations are actually ns16750 and
> > >> should have that in the device tree as well.
> > >>
> > >> For the device type of the bus, please check for both compatible and
> > >> type, so that it still works on machines that are missing the compatible
> > >> property.
> > >
> > > Wait, no. We already had this discussion months ago when David was
> > > working on the original Ebony port. It was declared that legacy_serial
> > > is not how serial should be done on 4xx and the serial_of driver was
> > > supposed to be used instead.
> > >
> > > Have we changed our stance on that? If not, then perhaps KGDB should be
> > > fixed to work with serial_of.
> >
> > Actually I don't see any reason not to use legacy_serial stuff for early
> > console. We could split the kernel configured very early debug output,
> > which uses PPC_EARLY_DEBUG_44x_PHYSLOW/PHYSHIGH (since it's really
> > dangerous) and early console things by using legacy serial. We could use
> > early boot console without PPC_EARLY_DEBUG_44x.
>
> That was exactly my thinking when this first came up. I'd like to hear
> David's opinion on it.
Yeah, I think I misinterpreted BenH way back when. This looks ok, and
means serial will be initialized earlier than of_serial, which would
be nice.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ 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