* Re: Build failure on treeboot-walnut.cg
From: Scott Wood @ 2007-10-11 20:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Timur Tabi, David Gibson
In-Reply-To: <18189.27251.48582.614106@cargo.ozlabs.ibm.com>
On Thu, Oct 11, 2007 at 10:12:35AM +1000, Paul Mackerras wrote:
> Timur Tabi writes:
>
> > Is this a new policy? Modules in the kernel are not built unless you want
> > them. Even in arch/powerpc/platforms, only the specific platform file I'm
> > targeting is built. So I don't really understand why you claim it's normal
> > for platform-specific files to be built, regardless of the actual platform.
>
> The wrapper script is intended to be a standalone tool which is
> independent of the kernel configuration, and can be used separately
> from the kernel build process.
Is it ever actually used that way? I wonder if this "intent" is worth the
pain...
-Scott
^ permalink raw reply
* Re: [PATCH 3/9 v2] add Freescale SerDes PHY support
From: Scott Wood @ 2007-10-11 20:09 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, paulus
In-Reply-To: <1192096425-30192-1-git-send-email-leoli@freescale.com>
On Thu, Oct 11, 2007 at 05:53:45PM +0800, Li Yang wrote:
> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
> index 19d4628..e89f803 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -291,4 +291,8 @@ config FSL_ULI1575
> Freescale reference boards. The boards all use the ULI in pretty
> much the same way.
>
> +config FSL_SERDES
> + bool
> + default n
"default n" is the default -- no need to specify it explicitly.
> + /* Configure SRDSCR1 */
> + tmp = in_be32(regs + FSL_SRDSCR1_OFFS);
> + tmp &= ~FSL_SRDSCR1_PLLBW;
> + out_be32(regs + FSL_SRDSCR1_OFFS, tmp);
clrbits32?
> + /* Configure SRDSCR2 */
> + tmp = in_be32(regs + FSL_SRDSCR2_OFFS);
> + tmp &= ~FSL_SRDSCR2_SEIC_MASK;
> + tmp |= FSL_SRDSCR2_SEIC_SATA;
> + out_be32(regs + FSL_SRDSCR2_OFFS, tmp);
clrsetbits_be32?
-Scott
^ permalink raw reply
* Re: [PATCH 4/4 v2] [POWERPC] Kilauea defconfig file
From: Scott Wood @ 2007-10-11 20:12 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200710111531.13022.sr@denx.de>
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.
In any case, you can just set DEVICE_TREE to an empty string if you only
want the regular uImage.
-Scott
^ permalink raw reply
* Re: Hard hang in hypervisor!?
From: Linas Vepstas @ 2007-10-11 20:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <18189.26776.326248.278431@cargo.ozlabs.ibm.com>
On Thu, Oct 11, 2007 at 10:04:40AM +1000, 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.
>
> So in your case it's quite possible that all interrupts were directed
> to cpu 0.
Thanks,
I'll give this a whirl if I don't get distracted by other tasks.
A simple cat /proc/interrupts shows them evenly distributed on
my "usual" box, and all glommed up on cpu 0 on the one thats
giving me fits.
Also, I noticed years ago that "BAD" was non-zero and large.
Vowed to look into it someday ...
--linas
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Benjamin Herrenschmidt @ 2007-10-11 20:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Paul Mackerras
In-Reply-To: <91E54A0A-EFD6-46C8-A703-7892731FA3F8@kernel.crashing.org>
On Thu, 2007-10-11 at 07:52 -0500, Kumar Gala wrote:
> > Benjamin Herrenschmidt (3):
> > [POWERPC] Fix platinumfb framebuffer
> > [POWERPC] cell: Move cbe_regs.h to include/asm-powerpc/cell-
> > regs.h
> > [POWERPC] cell: Add Cell memory controller register defs and
> > expose it
>
> Ben, your slacking :)
?
Ben.
^ permalink raw reply
* Re: [PATCH] Make clockevents work on PPC601 processors
From: Benjamin Herrenschmidt @ 2007-10-11 20:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <96C1AFB8-784F-445E-A3F2-5D68494541CD@kernel.crashing.org>
On Thu, 2007-10-11 at 09:12 -0500, Kumar Gala wrote:
> On Oct 11, 2007, at 6:46 AM, Paul Mackerras wrote:
>
> > In testing the new clocksource and clockevent code on a PPC601
> > processor, I discovered that the clockevent multiplier value for the
> > decrementer clockevent was overflowing. Because the RTCL register in
> > the 601 effectively counts at 1GHz (it doesn't actually, but it
> > increases by 128 every 128ns), and the shift value was 32, that meant
> > the multiplier value had to be 2^32, which won't fit in an unsigned
> > long on 32-bit. The same problem would arise on any platform where
> > the timebase frequency was 1GHz or more (not that we actually have any
> > such machines today).
>
> do you still have a 601 running somewhere?
On my desk :-) (and he also has a 601 card for the 7500 iirc)
/me remembers to revive his dual 604 8500 one of these days.
Ben.
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Kumar Gala @ 2007-10-11 21:06 UTC (permalink / raw)
To: benh; +Cc: PowerPC dev list, Paul Mackerras
In-Reply-To: <1192136106.8476.56.camel@pasglop>
On Oct 11, 2007, at 3:55 PM, Benjamin Herrenschmidt wrote:
>
> On Thu, 2007-10-11 at 07:52 -0500, Kumar Gala wrote:
>>> Benjamin Herrenschmidt (3):
>>> [POWERPC] Fix platinumfb framebuffer
>>> [POWERPC] cell: Move cbe_regs.h to include/asm-powerpc/cell-
>>> regs.h
>>> [POWERPC] cell: Add Cell memory controller register defs and
>>> expose it
>>
>> Ben, your slacking :)
>
> ?
Just three patches for 2.6.24... :)
- k
^ permalink raw reply
* Re: [PATCH] PowerPC: Add legacy serial support for OPB with flattened device tree.
From: Arnd Bergmann @ 2007-10-11 21:10 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071011190925.GA22704@ru.mvista.com>
On Thursday 11 October 2007, Valentine Barshak wrote:
> Currently find_legacy_serial_ports() can find no serial ports on the OPB
> with flattened device. 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 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 in case device type is not
> specified.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Looks correct for QS21 now.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ 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
* 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 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: [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
* [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 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
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