* RE: [PATCH -mm] RapidIO,powerpc/85xx: Fix configuration option
From: Bounine, Alexandre @ 2011-03-18 20:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-kernel, Thomas Moll, akpm, linuxppc-dev
In-Reply-To: <8E8332C6-1F17-4EC1-BD04-7B93D7B49640@kernel.crashing.org>
This patch has to be applied to -mm tree. Andrew already has set of
patches that change RapidIO configuration.
I think it will be better if it goes into -mm to keep things aligned
properly.
Alex.
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Friday, March 18, 2011 4:49 PM
To: Bounine, Alexandre
Cc: akpm@linux-foundation.org; linux-kernel@vger.kernel.org;
linuxppc-dev@lists.ozlabs.org; Matt Porter; Li Yang; Thomas Moll
Subject: Re: [PATCH -mm] RapidIO,powerpc/85xx: Fix configuration option
On Mar 18, 2011, at 12:18 PM, Alexandre Bounine wrote:
> Follows set of patches in -mm tree. Replaces configuration option
> missed in previous patches.
>=20
> Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
> ---
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Alex, I can push this via the powerpc.git tree route if you want.
- k
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2011-03-18 21:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
In-Reply-To: <AANLkTinLb0sg1H6GDbZiddqGQ4a0=GRLYFJbL0G1Kv62@mail.gmail.com>
On Fri, 2011-03-18 at 06:34 -0700, Linus Torvalds wrote:
> > Here are the changes for this merge window for powerpc. One highlight
> > is irq data conversion so we can get rid of the legacy stuff. The new
> > Dynamic DMA windows for pSeries should also improve performances for
> > some devices nicely on more recent machines/firmwares. Plus a little
> > pack of embedded things.
>
> Ok, I got a conflict with the of_platform_driver() removal which
> looked pretty trivial, but since I don't have a ppc cross-compile
> thing I couldn't even test-compile the end result. Please take a look
> to see that it went ok..
Ok, I'll have a look later today.
Thanks,
Ben.
^ permalink raw reply
* Re: [PATCH v2] gianfar: Fall back to software tcp/udp checksum on older controllers
From: David Miller @ 2011-03-18 22:15 UTC (permalink / raw)
To: oakad; +Cc: netdev, linux-kernel, linuxppc-dev, mlcreech
In-Reply-To: <598461.73809.qm@web37603.mail.mud.yahoo.com>
From: Alex Dubov <oakad@yahoo.com>
Date: Wed, 16 Mar 2011 20:57:13 -0700 (PDT)
> As specified by errata eTSEC49 of MPC8548 and errata eTSEC12 of MPC83xx,
> older revisions of gianfar controllers will be unable to calculate a TCP/UDP
> packet checksum for some alignments of the appropriate FCB. This patch checks
> for FCB alignment on such controllers and falls back to software checksumming
> if the alignment is known to be bad.
>
> Signed-off-by: Alex Dubov <oakad@yahoo.com>
Applied.
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Hollis Blanchard @ 2011-03-18 23:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: meador_inge, linuxppc-dev list
In-Reply-To: <1300427072.22236.1277.camel@pasglop>
On Thu, Mar 17, 2011 at 10:44 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Hi Linus !
>
> Here are the changes for this merge window for powerpc. One highlight
> is irq data conversion so we can get rid of the legacy stuff. The new
> Dynamic DMA windows for pSeries should also improve performances for
> some devices nicely on more recent machines/firmwares. Plus a little
> pack of embedded things.
Ben, you missed the patches from Meador:
http://patchwork.ozlabs.org/patch/86804/
http://patchwork.ozlabs.org/patch/86805/
http://patchwork.ozlabs.org/patch/86806/
Please commit.
-Hollis
^ permalink raw reply
* Re: [PATCH V12 0/4] ptp: IEEE 1588 hardware clock support
From: Richard Cochran @ 2011-03-19 10:14 UTC (permalink / raw)
To: linux-kernel
Cc: Thomas Gleixner, Rodolfo Giometti, Arnd Bergmann, Peter Zijlstra,
linux-api, devicetree-discuss, Russell King, Paul Mackerras,
John Stultz, linux-arm-kernel, netdev, Mike Frysinger,
Christoph Lameter, linuxppc-dev, David Miller, Alan Cox,
Krzysztof Halasa
In-Reply-To: <cover.1298878618.git.richard.cochran@omicron.at>
For all those interested in the user space aspect, I have posted some
patches to ptpd project showing how the API works.
https://sourceforge.net/tracker/?group_id=139814&atid=744634
3225599 [PATCH 1/3] Convert to POSIX clock API.
3225603 [PATCH 2/3] Adapted to use the Linux PTP Hardware Clock API.
3225607 [PATCH 3/3] Adapted to use the newer SO_TIMESTAMPING Linux API.
Enjoy,
Richard
^ permalink raw reply
* powerpc/pci sysdata batch hangs G5 boot
From: Hugh Dickins @ 2011-03-20 3:41 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
Hi Grant,
I've been unable to boot mmotm on the G5 for a few weeks; and now that
the problem has reached Linus, I've bisected and it converges on your:
commit b5d937de0367d26f65b9af1aef5f2c34c1939be0
powerpc/pci: Make both ppc32 and ppc64 use sysdata for pci_controller
Currently, ppc32 uses sysdata for the pci_controller pointer, and
ppc64 uses it to hold the device_node pointer. This patch moves the
of_node pointer into (struct pci_bus*)->dev.of_node and
(struct pci_dev*)->dev.of_node so that sysdata can be converted to always
use the pci_controller pointer instead. It also fixes up the
allocating of pci devices so that the of_node pointer gets assigned
consistently and increments the ref count.
The last message I see on screen when booting is
mpic: ISU size: 124, shift: 7, mask: 7f
Usually that would be followed by
mpic: Initializing for 124 sources
but with your commit it just hangs; revert that commit,
from mmotm or from Linus's current git, and all is fine.
Config available privately on request. Noticing that patch is a
PPC OF PCI thing, and that I have CONFIG_PPC_OF_PLATFORM_PCI off,
I did try switching that on, but it made no difference.
Thanks,
Hugh
^ permalink raw reply
* mmotm threatens ppc preemption again
From: Hugh Dickins @ 2011-03-20 4:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jeremy Fitzhardinge, linuxppc-dev, Andrew Morton, Peter Zijlstra
Hi Ben,
As I warned a few weeks ago, Jeremy has vmalloc apply_to_pte_range
patches in mmotm, which again assault PowerPC's expectations, and
cause lots of noise with CONFIG_PREEMPT=y CONFIG_PREEMPT_DEBUG=y.
This time in vmalloc as well as vfree; and Peter's fix to the last
lot, which went into 2.6.38, doesn't protect against these ones.
Here's what I now see when I swapon and swapoff:
BUG: using smp_processor_id() in preemptible [00000000] code: swapon/3230
caller is .apply_to_pte_range+0x118/0x1f0
Call Trace:
[c000000029c3b870] [c00000000000f38c] .show_stack+0x6c/0x16c (unreliable)
[c000000029c3b920] [c00000000022e024] .debug_smp_processor_id+0xe4/0x11c
[c000000029c3b9b0] [c0000000000de78c] .apply_to_pte_range+0x118/0x1f0
[c000000029c3ba70] [c0000000000de988] .apply_to_pud_range+0x124/0x188
[c000000029c3bb40] [c0000000000dea90] .apply_to_page_range_batch+0xa4/0xe8
[c000000029c3bc00] [c0000000000eb2c0] .map_vm_area+0x50/0x94
[c000000029c3bca0] [c0000000000ec368] .__vmalloc_area_node+0x144/0x190
[c000000029c3bd50] [c0000000000f1738] .SyS_swapon+0x270/0x704
[c000000029c3be30] [c0000000000075a8] syscall_exit+0x0/0x40
BUG: using smp_processor_id() in preemptible [00000000] code: swapon/3230
caller is .apply_to_pte_range+0x168/0x1f0
Call Trace:
[c000000029c3b870] [c00000000000f38c] .show_stack+0x6c/0x16c (unreliable)
[c000000029c3b920] [c00000000022e024] .debug_smp_processor_id+0xe4/0x11c
[c000000029c3b9b0] [c0000000000de7dc] .apply_to_pte_range+0x168/0x1f0
[c000000029c3ba70] [c0000000000de988] .apply_to_pud_range+0x124/0x188
[c000000029c3bb40] [c0000000000dea90] .apply_to_page_range_batch+0xa4/0xe8
[c000000029c3bc00] [c0000000000eb2c0] .map_vm_area+0x50/0x94
[c000000029c3bca0] [c0000000000ec368] .__vmalloc_area_node+0x144/0x190
[c000000029c3bd50] [c0000000000f1738] .SyS_swapon+0x270/0x704
[c000000029c3be30] [c0000000000075a8] syscall_exit+0x0/0x40
Adding 1572860k swap on /dev/sdb4. Priority:-1 extents:1 across:1572860k SS
BUG: using smp_processor_id() in preemptible [00000000] code: swapoff/3231
caller is .apply_to_pte_range+0x118/0x1f0
Call Trace:
[c0000000260d38b0] [c00000000000f38c] .show_stack+0x6c/0x16c (unreliable)
[c0000000260d3960] [c00000000022e024] .debug_smp_processor_id+0xe4/0x11c
[c0000000260d39f0] [c0000000000de78c] .apply_to_pte_range+0x118/0x1f0
[c0000000260d3ab0] [c0000000000de988] .apply_to_pud_range+0x124/0x188
[c0000000260d3b80] [c0000000000dea90] .apply_to_page_range_batch+0xa4/0xe8
[c0000000260d3c40] [c0000000000eb0d8] .remove_vm_area+0x90/0xd4
[c0000000260d3cd0] [c0000000000ec0a8] .__vunmap+0x50/0x104
[c0000000260d3d60] [c0000000000f32fc] .SyS_swapoff+0x4d8/0x5e8
[c0000000260d3e30] [c0000000000075a8] syscall_exit+0x0/0x40
BUG: using smp_processor_id() in preemptible [00000000] code: swapoff/3231
caller is .apply_to_pte_range+0x168/0x1f0
Call Trace:
[c0000000260d38b0] [c00000000000f38c] .show_stack+0x6c/0x16c (unreliable)
[c0000000260d3960] [c00000000022e024] .debug_smp_processor_id+0xe4/0x11c
[c0000000260d39f0] [c0000000000de7dc] .apply_to_pte_range+0x168/0x1f0
[c0000000260d3ab0] [c0000000000de988] .apply_to_pud_range+0x124/0x188
[c0000000260d3b80] [c0000000000dea90] .apply_to_page_range_batch+0xa4/0xe8
[c0000000260d3c40] [c0000000000eb0d8] .remove_vm_area+0x90/0xd4
[c0000000260d3cd0] [c0000000000ec0a8] .__vunmap+0x50/0x104
[c0000000260d3d60] [c0000000000f32fc] .SyS_swapoff+0x4d8/0x5e8
[c0000000260d3e30] [c0000000000075a8] syscall_exit+0x0/0x40
BUG: using smp_processor_id() in preemptible [00000000] code: swapoff/3231
caller is .__flush_tlb_pending+0x20/0xb4
Call Trace:
[c0000000260d3830] [c00000000000f38c] .show_stack+0x6c/0x16c (unreliable)
[c0000000260d38e0] [c00000000022e024] .debug_smp_processor_id+0xe4/0x11c
[c0000000260d3970] [c00000000002efbc] .__flush_tlb_pending+0x20/0xb4
[c0000000260d39f0] [c0000000000de7fc] .apply_to_pte_range+0x188/0x1f0
[c0000000260d3ab0] [c0000000000de988] .apply_to_pud_range+0x124/0x188
[c0000000260d3b80] [c0000000000dea90] .apply_to_page_range_batch+0xa4/0xe8
[c0000000260d3c40] [c0000000000eb0d8] .remove_vm_area+0x90/0xd4
[c0000000260d3cd0] [c0000000000ec0a8] .__vunmap+0x50/0x104
[c0000000260d3d60] [c0000000000f32fc] .SyS_swapoff+0x4d8/0x5e8
[c0000000260d3e30] [c0000000000075a8] syscall_exit+0x0/0x40
BUG: using smp_processor_id() in preemptible [00000000] code: swapoff/3231
caller is .native_flush_hash_range+0x3c/0x384
Call Trace:
[c0000000260d36f0] [c00000000000f38c] .show_stack+0x6c/0x16c (unreliable)
[c0000000260d37a0] [c00000000022e024] .debug_smp_processor_id+0xe4/0x11c
[c0000000260d3830] [c00000000002e2c8] .native_flush_hash_range+0x3c/0x384
[c0000000260d38e0] [c00000000002c370] .flush_hash_range+0x4c/0xc8
[c0000000260d3970] [c00000000002f02c] .__flush_tlb_pending+0x90/0xb4
[c0000000260d39f0] [c0000000000de7fc] .apply_to_pte_range+0x188/0x1f0
[c0000000260d3ab0] [c0000000000de988] .apply_to_pud_range+0x124/0x188
[c0000000260d3b80] [c0000000000dea90] .apply_to_page_range_batch+0xa4/0xe8
[c0000000260d3c40] [c0000000000eb0d8] .remove_vm_area+0x90/0xd4
[c0000000260d3cd0] [c0000000000ec0a8] .__vunmap+0x50/0x104
[c0000000260d3d60] [c0000000000f32fc] .SyS_swapoff+0x4d8/0x5e8
[c0000000260d3e30] [c0000000000075a8] syscall_exit+0x0/0x40
I work around them with the patch below, but would prefer not to disable
preemption on all architectures there. Though I'm not a huge fan of
apply_to_pte_range myself (I feel it glosses over differences, such as
how often one needs to let preemption in): I wouldn't mind if we left
vmalloc as is without it.
Hugh
--- mmotm/mm/memory.c
+++ fixed/mm/memory.c
@@ -2021,9 +2021,11 @@ static int apply_to_pte_range(struct mm_
int err;
spinlock_t *uninitialized_var(ptl);
- pte = (mm == &init_mm) ?
- pte_alloc_kernel(pmd, addr) :
- pte_alloc_map_lock(mm, pmd, addr, &ptl);
+ if (mm == &init_mm) {
+ pte = pte_alloc_kernel(pmd, addr);
+ preempt_disable();
+ } else
+ pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
if (!pte)
return -ENOMEM;
@@ -2033,7 +2035,9 @@ static int apply_to_pte_range(struct mm_
err = fn(pte, (end - addr) / PAGE_SIZE, addr, data);
arch_leave_lazy_mmu_mode();
- if (mm != &init_mm)
+ if (mm == &init_mm)
+ preempt_enable();
+ else
pte_unmap_unlock(pte, ptl);
return err;
}
^ permalink raw reply
* Re: powerpc/pci sysdata batch hangs G5 boot
From: Grant Likely @ 2011-03-20 6:25 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linuxppc-dev
In-Reply-To: <alpine.LSU.2.00.1103192023140.1592@sister.anvils>
On Sat, Mar 19, 2011 at 9:41 PM, Hugh Dickins <hughd@google.com> wrote:
> Hi Grant,
>
> I've been unable to boot mmotm on the G5 for a few weeks; and now that
> the problem has reached Linus, I've bisected and it converges on your:
>
> commit b5d937de0367d26f65b9af1aef5f2c34c1939be0
> =A0 =A0powerpc/pci: Make both ppc32 and ppc64 use sysdata for pci_control=
ler
Hi Hugh,
Thanks for the testing. I don't have access to a G5 unfortunately.
Are you able to capture the good/bad console output and send it to me?
A digital photo would be fine if you can't grab the raw text. Add
#define DEBUG to the top of arch/powerpc/kernel/pci-common.c above the
#includes too if you don't mind.
I'm investigating on my end. I suspect that I've messed up retrieval
of the hose pointer.
Thanks,
g.
^ permalink raw reply
* Re: powerpc/pci sysdata batch hangs G5 boot
From: Benjamin Herrenschmidt @ 2011-03-20 9:10 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Hugh Dickins
In-Reply-To: <AANLkTikMbMqSRpt9gCrHgzpJuRCGL7rfLAs6erJL0Qjc@mail.gmail.com>
On Sun, 2011-03-20 at 00:25 -0600, Grant Likely wrote:
> On Sat, Mar 19, 2011 at 9:41 PM, Hugh Dickins <hughd@google.com> wrote:
> > Hi Grant,
> >
> > I've been unable to boot mmotm on the G5 for a few weeks; and now that
> > the problem has reached Linus, I've bisected and it converges on your:
> >
> > commit b5d937de0367d26f65b9af1aef5f2c34c1939be0
> > powerpc/pci: Make both ppc32 and ppc64 use sysdata for pci_controller
>
> Hi Hugh,
>
> Thanks for the testing. I don't have access to a G5 unfortunately.
> Are you able to capture the good/bad console output and send it to me?
> A digital photo would be fine if you can't grab the raw text. Add
> #define DEBUG to the top of arch/powerpc/kernel/pci-common.c above the
> #includes too if you don't mind.
>
> I'm investigating on my end. I suspect that I've messed up retrieval
> of the hose pointer.
Hrm, you merged that already ? I would have liked to have a chance to at
least test and review properly...
Oh well, I have G5's here, I'll see if I can find what's wrong tomorrow.
Cheers,
Ben.
^ permalink raw reply
* PowerMac7,3 dvd drive?
From: kevin diggs @ 2011-03-20 23:52 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am seeing ... issues with the optical drive (hda) under 2.6.36. I
can't mount disks:
[root@PowerMacG5 ~]# mount -r /dev/hda /mnt/cdrom
mount: /dev/hda already mounted or /mnt/cdrom busy
The log has:
[ 239.922268] hda: irq timeout: status=0xd0 { Busy }
[ 239.922485] hda: possibly failed opcode: 0xa0
eject hda will hang ... longer than my patience.
At first I thought the drive was going south. But I don't see this (at
least so far) on 2.6.28.
Thanks!
kevin
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Benjamin Herrenschmidt @ 2011-03-20 23:53 UTC (permalink / raw)
To: Hugh Dickins
Cc: Jeremy Fitzhardinge, linuxppc-dev, Andrew Morton, Peter Zijlstra
In-Reply-To: <alpine.LSU.2.00.1103192041390.1592@sister.anvils>
On Sat, 2011-03-19 at 21:11 -0700, Hugh Dickins wrote:
>
> As I warned a few weeks ago, Jeremy has vmalloc apply_to_pte_range
> patches in mmotm, which again assault PowerPC's expectations, and
> cause lots of noise with CONFIG_PREEMPT=y CONFIG_PREEMPT_DEBUG=y.
>
> This time in vmalloc as well as vfree; and Peter's fix to the last
> lot, which went into 2.6.38, doesn't protect against these ones.
> Here's what I now see when I swapon and swapoff:
Right. And we said from day one we had the HARD WIRED assumption that
arch_enter/leave_lazy_mmu_mode() was ALWAYS going to be called within
a PTE lock section, and we did get reassurance that it was going to
remain so.
So why is it ok for them to change those and break us like that ?
Seriously, this is going out of control. If we can't even rely on
fundamental locking assumptions in the VM to remain reasonably stable
or at least get some amount of -care- from who changes them as to
whether they break others and work with us to fix them, wtf ?
I don't know what the right way to fix that is. We have an absolute
requirement that the batching we start within a lazy MMU section
is complete and flushed before any other PTE in that section can be
touched by anything else. Do we -at least- keep that guarantee ?
If yes, then maybe preempt_disable/enable() around
arch_enter/leave_lazy_mmu_mode() in apply_to_pte_range() would do...
Or maybe I should just prevent any batching of init_mm :-(
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc/ptrace: remove BUG_ON when full register set not available
From: Benjamin Herrenschmidt @ 2011-03-21 0:15 UTC (permalink / raw)
To: mjw; +Cc: linuxppc-dev, mikey, anton
In-Reply-To: <1300282642.15145.2.camel@w500>
On Wed, 2011-03-16 at 08:37 -0500, Michael Wolf wrote:
> In some cases during a threaded core dump not all
> the threads will have a full register set. This
> will cause problems when the sigkill is sent to
> the thread. To solve this problem a poison value
> (0xdeadbeef) will be placed in the buffer in place
> of the actual register values. This will affect
> gpr14 to gpr31.
>
> Signed-off-by: Mike Wolf <mjw@linux.vnet.ibm.com>
Patch is busted on ppc32 (you add #define's in the middle of a
multi-line macro) and of doubtful stylistic value :-) I'll merge
a slightly reworked variant that includes a new cset comment
with Paulus explanation in it.
Cheers,
Ben.
> ----------
> --- linux-2.6.32-71.el6.ppc64.orig/arch/powerpc/include/asm/ptrace.h 2010-08-31 23:56:50.000000000 -0500
> +++ linux-2.6.32-71.el6.ppc64/arch/powerpc/include/asm/ptrace.h 2011-03-14 11:43:33.176667099 -0500
> @@ -123,8 +123,14 @@ extern int ptrace_put_reg(struct task_st
> #define TRAP(regs) ((regs)->trap & ~0xF)
> #ifdef __powerpc64__
> #define CHECK_FULL_REGS(regs) BUG_ON(regs->trap & 1)
> +#define PARTIAL_REG_FILL 0xdeadbeefdeadbeefUL
> +#define PARTIAL_REG_START 14
> +#define PARTIAL_REG_END 31
> #else
> #define CHECK_FULL_REGS(regs) \
> +#define PARTIAL_REG_FILL 0xdeadbeef
> +#define PARTIAL_REG_START 14
> +#define PARTIAL_REG_END 31
> do { \
> if ((regs)->trap & 1) \
> printk(KERN_CRIT "%s: partial register set\n", __func__); \
> --- linux-2.6.32-71.el6.ppc64.orig/arch/powerpc/kernel/ptrace.c 2009-12-02 21:51:21.000000000 -0600
> +++ linux-2.6.32-71.el6.ppc64/arch/powerpc/kernel/ptrace.c 2011-03-14 13:01:51.955586126 -0500
> @@ -125,11 +125,16 @@ static int gpr_get(struct task_struct *t
> void *kbuf, void __user *ubuf)
> {
> int ret;
> + int partial_reg;
>
> if (target->thread.regs == NULL)
> return -EIO;
>
> - CHECK_FULL_REGS(target->thread.regs);
> + if (!FULL_REGS(target->thread.regs))
> + /* We have a partial register set. Fill 14-31 with bogus values */
> + for(partial_reg=PARTIAL_REG_START;partial_reg <= PARTIAL_REG_END;
> + partial_reg++)
> + target->thread.regs->gpr[partial_reg] = PARTIAL_REG_FILL;
>
> ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
> target->thread.regs,
> @@ -536,11 +541,16 @@ static int gpr32_get(struct task_struct
> compat_ulong_t *k = kbuf;
> compat_ulong_t __user *u = ubuf;
> compat_ulong_t reg;
> + int partial_reg;
>
> if (target->thread.regs == NULL)
> return -EIO;
>
> - CHECK_FULL_REGS(target->thread.regs);
> + if (!FULL_REGS(target->thread.regs))
> + /* We have a partial register set. Fill 14-31 with bogus values */
> + for(partial_reg=PARTIAL_REG_START;partial_reg <= PARTIAL_REG_END;
> + partial_reg++)
> + target->thread.regs->gpr[partial_reg] = PARTIAL_REG_FILL;
>
> pos /= sizeof(reg);
> count /= sizeof(reg);
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc/ptrace: Remove BUG_ON when full register set not available
From: Benjamin Herrenschmidt @ 2011-03-21 0:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mike Wolf
From: Mike Wolf <mjw@linux.vnet.ibm.com>
In some cases during a threaded core dump not all the threads will have
a full register set. This happens when the signal causing the core dump
races with a thread exiting. The race happens when the exiting thread
has entered the kernel for the last time before the signal arrives, but
doesn't get far enough through the exit code to avoid being included
in the core dump.
So we get a thread included in the core dump which is never going to go
out to userspace again and only has a partial register set recorded
Normally we would catch each thread as it is about to go into userspace
and capture the full register set then.
However, this exiting thread is never going to go out to userspace
again, so we have no way to capture its full register set. It doesn't
really matter, though, as this is a thread which is effectively
already dead.
So instead of hitting a BUG() in this case (a really bad choice of
action in the first place), we use a poison value for the register
values.
[BenH]: Some cosmetic/stylistic changes and fix build on ppc32
Signed-off-by: Mike Wolf <mjw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/ptrace.h | 2 ++
arch/powerpc/kernel/ptrace.c | 15 ++++++++++++---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 0175a67..48223f9 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -125,8 +125,10 @@ extern int ptrace_put_reg(struct task_struct *task, int regno,
#endif /* ! __powerpc64__ */
#define TRAP(regs) ((regs)->trap & ~0xF)
#ifdef __powerpc64__
+#define NV_REG_POISON 0xdeadbeefdeadbeefUL
#define CHECK_FULL_REGS(regs) BUG_ON(regs->trap & 1)
#else
+#define NV_REG_POISON 0xdeadbeef
#define CHECK_FULL_REGS(regs) \
do { \
if ((regs)->trap & 1) \
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 9065369..895b082 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -229,12 +229,16 @@ static int gpr_get(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
- int ret;
+ int i, ret;
if (target->thread.regs == NULL)
return -EIO;
- CHECK_FULL_REGS(target->thread.regs);
+ if (!FULL_REGS(target->thread.regs)) {
+ /* We have a partial register set. Fill 14-31 with bogus values */
+ for (i = 14; i < 32; i++)
+ target->thread.regs->gpr[i] = NV_REG_POISON;
+ }
ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
target->thread.regs,
@@ -641,11 +645,16 @@ static int gpr32_get(struct task_struct *target,
compat_ulong_t *k = kbuf;
compat_ulong_t __user *u = ubuf;
compat_ulong_t reg;
+ int i;
if (target->thread.regs == NULL)
return -EIO;
- CHECK_FULL_REGS(target->thread.regs);
+ if (!FULL_REGS(target->thread.regs)) {
+ /* We have a partial register set. Fill 14-31 with bogus values */
+ for (i = 14; i < 32; i++)
+ target->thread.regs->gpr[i] = NV_REG_POISON;
+ }
pos /= sizeof(reg);
count /= sizeof(reg);
^ permalink raw reply related
* Re: PowerMac7,3 dvd drive?
From: Benjamin Herrenschmidt @ 2011-03-21 0:24 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikRU9W61m7EcNONx9=Uinj-F7escWBCOTTdh==N@mail.gmail.com>
On Sun, 2011-03-20 at 18:52 -0500, kevin diggs wrote:
> I am seeing ... issues with the optical drive (hda) under 2.6.36. I
> can't mount disks:
>
> [root@PowerMacG5 ~]# mount -r /dev/hda /mnt/cdrom
> mount: /dev/hda already mounted or /mnt/cdrom busy
>
> The log has:
>
> [ 239.922268] hda: irq timeout: status=0xd0 { Busy }
> [ 239.922485] hda: possibly failed opcode: 0xa0
>
> eject hda will hang ... longer than my patience.
>
> At first I thought the drive was going south. But I don't see this (at
> least so far) on 2.6.28.
Do you see something similar if you use the new libata based driver
(macio-ata) instead of the old IDE driver ?
It does look like the drive itself is crashing tho. Maybe something the
IDE CDROM driver does upsets it...
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: Fix accounting of softirq time when idle
From: Anton Blanchard @ 2011-03-21 1:28 UTC (permalink / raw)
To: paulus, benh; +Cc: linuxppc-dev
commit cf9efce0ce31 (powerpc: Account time using timebase rather
than PURR) used in_irq() to detect if the time was spent in
interrupt processing. This only catches hardirq context so if we
are in softirq context and in the idle loop we end up accounting it
as idle time. If we instead use in_interrupt() we catch both softirq
and hardirq time.
The issue was found when running a network intensive workload. top
showed the following:
0.0%us, 1.1%sy, 0.0%ni, 85.7%id, 0.0%wa, 9.9%hi, 3.3%si, 0.0%st
85.7% idle. But this was wildly different to the perf events data.
To confirm the suspicion I ran something to keep the core busy:
# yes > /dev/null &
8.2%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 10.3%hi, 81.4%si, 0.0%st
We only got 8.2% of the CPU for the userspace task and softirq has
shot up to 81.4%.
With the patch below top shows the correct stats:
0.0%us, 0.0%sy, 0.0%ni, 5.3%id, 0.0%wa, 13.3%hi, 81.3%si, 0.0%st
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@kernel.org
---
Index: linux-2.6/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/time.c 2011-03-21 12:05:12.056482258 +1100
+++ linux-2.6/arch/powerpc/kernel/time.c 2011-03-21 12:05:18.516721851 +1100
@@ -356,7 +356,7 @@ void account_system_vtime(struct task_st
}
get_paca()->user_time_scaled += user_scaled;
- if (in_irq() || idle_task(smp_processor_id()) != tsk) {
+ if (in_interrupt() || idle_task(smp_processor_id()) != tsk) {
account_system_time(tsk, 0, delta, sys_scaled);
if (stolen)
account_steal_time(stolen);
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Hugh Dickins @ 2011-03-21 1:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jeremy Fitzhardinge, linuxppc-dev, Andrew Morton, Peter Zijlstra
In-Reply-To: <1300665188.2402.64.camel@pasglop>
On Mon, 21 Mar 2011, Benjamin Herrenschmidt wrote:
> On Sat, 2011-03-19 at 21:11 -0700, Hugh Dickins wrote:
> >
> > As I warned a few weeks ago, Jeremy has vmalloc apply_to_pte_range
> > patches in mmotm, which again assault PowerPC's expectations, and
> > cause lots of noise with CONFIG_PREEMPT=y CONFIG_PREEMPT_DEBUG=y.
> >
> > This time in vmalloc as well as vfree; and Peter's fix to the last
> > lot, which went into 2.6.38, doesn't protect against these ones.
> > Here's what I now see when I swapon and swapoff:
>
> Right. And we said from day one we had the HARD WIRED assumption that
> arch_enter/leave_lazy_mmu_mode() was ALWAYS going to be called within
> a PTE lock section, and we did get reassurance that it was going to
> remain so.
>
> So why is it ok for them to change those and break us like that ?
It's not ok. Sounds like Andrew should not forward
mm-remove-unused-token-argument-from-apply_to_page_range-callback.patch
mm-add-apply_to_page_range_batch.patch
ioremap-use-apply_to_page_range_batch-for-ioremap_page_range.patch
vmalloc-use-plain-pte_clear-for-unmaps.patch
vmalloc-use-apply_to_page_range_batch-for-vunmap_page_range.patch
vmalloc-use-apply_to_page_range_batch-for-vmap_page_range_noflush.patch
vmalloc-use-apply_to_page_range_batch-in-alloc_vm_area.patch
xen-mmu-use-apply_to_page_range_batch-in-xen_remap_domain_mfn_range.patch
xen-grant-table-use-apply_to_page_range_batch.patch
or some subset (the vmalloc-use-apply ones? and the ioremap one?)
of that set to Linus for 2.6.39. Your call.
>
> Seriously, this is going out of control. If we can't even rely on
> fundamental locking assumptions in the VM to remain reasonably stable
> or at least get some amount of -care- from who changes them as to
> whether they break others and work with us to fix them, wtf ?
I know next to nothing of arch_enter/leave_lazy_mmu_mode(),
and the same is probably true of most mm developers. The only
people who have it defined to anything interesting appear to be
powerpc and xen and lguest: so it would be a gentleman's agreement
between you and Jeremy and Rusty.
If Jeremy has changed the rules without your agreement, then you
can fight a duel at daybreak, or, since your daybreaks are at
different times, Jeremy's patches just shouldn't go forward yet.
>
> I don't know what the right way to fix that is. We have an absolute
> requirement that the batching we start within a lazy MMU section
> is complete and flushed before any other PTE in that section can be
> touched by anything else. Do we -at least- keep that guarantee ?
I'm guessing it's a guarantee of the same kind as led me to skip
page_table_lock on init_mm in 2.6.15: no locking to guarantee it,
but it would have to be a kernel bug, in a driver or wherever,
for us to be accessing such a section while it was in transit
(short of speculative access prior to tlb flush).
>
> If yes, then maybe preempt_disable/enable() around
> arch_enter/leave_lazy_mmu_mode() in apply_to_pte_range() would do...
>
> Or maybe I should just prevent any batching of init_mm :-(
I don't see where you're doing batching on init_mm today:
it looks as if Jeremy's patches, by using the same code as he has
for user mms, are now enabling batching on init_mm, and you should :-)
But I may be all wrong: it's between you and Jeremy,
and until he defends them, his patches should not go forward.
Hugh
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-03-21 1:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus
Here's a fix for the regression introduced by
b5d937de0367d26f65b9af1aef5f2c34c1939be0 along with a bug fix from Mike
Wolf for a nasty BUG_ON() that shoudn't be there for some odd case of
threaded core dumps, and 3 patches from Meador Inge that I plain forgot
to include before.
Cheers,
Ben.
The following changes since commit a952baa034ae7c2e4a66932005cbc7ebbccfe28d:
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input (2011-03-19 22:27:06 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (1):
powerpc/pci: Fix crash in PCI code on ppc64 when matching device nodes
Meador Inge (3):
powerpc: Document the Open PIC device tree binding
powerpc: Make MPIC honor the "pic-no-reset" device tree property
powerpc: Factoring mpic cpu id fetching into a function
Mike Wolf (1):
powerpc/ptrace: Remove BUG_ON when full register set not available
Documentation/devicetree/bindings/open-pic.txt | 98 ++++++++++++++++++++++++
arch/powerpc/include/asm/mpic.h | 4 +
arch/powerpc/include/asm/ptrace.h | 2 +
arch/powerpc/kernel/pci_dn.c | 7 +-
arch/powerpc/kernel/ptrace.c | 15 +++-
arch/powerpc/sysdev/mpic.c | 85 +++++++++++++++-----
6 files changed, 184 insertions(+), 27 deletions(-)
create mode 100644 Documentation/devicetree/bindings/open-pic.txt
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Benjamin Herrenschmidt @ 2011-03-21 1:50 UTC (permalink / raw)
To: Hugh Dickins
Cc: Jeremy Fitzhardinge, linuxppc-dev, Andrew Morton, Peter Zijlstra
In-Reply-To: <alpine.LSU.2.00.1103201814320.7035@sister.anvils>
On Sun, 2011-03-20 at 18:41 -0700, Hugh Dickins wrote:
> > I don't know what the right way to fix that is. We have an absolute
> > requirement that the batching we start within a lazy MMU section
> > is complete and flushed before any other PTE in that section can be
> > touched by anything else. Do we -at least- keep that guarantee ?
>
> I'm guessing it's a guarantee of the same kind as led me to skip
> page_table_lock on init_mm in 2.6.15: no locking to guarantee it,
> but it would have to be a kernel bug, in a driver or wherever,
> for us to be accessing such a section while it was in transit
> (short of speculative access prior to tlb flush).
As long as the races to avoid are between map/unmap vs. access, yes, it
-should- be fine, and we used to not do demand faulting on kernel space
(but for how long ?). I'm wondering why we don't just stick a ptl in
there or is there a good reason why we can't ?
> I don't see where you're doing batching on init_mm today:
> it looks as if Jeremy's patches, by using the same code as he has
> for user mms, are now enabling batching on init_mm, and you should :-)
>
> But I may be all wrong: it's between you and Jeremy,
> and until he defends them, his patches should not go forward.
We don't do it today (batching). Jeremy's patches have the side effect
of "enabling" it, which isn't wrong per-se ... but on our side relies on
some locking assumptions we are missing.
Cheers,
Ben.
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Hugh Dickins @ 2011-03-21 2:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Jeremy Fitzhardinge, Hugh Dickins, Andrew Morton,
Peter Zijlstra
In-Reply-To: <1300672207.2402.205.camel@pasglop>
On Mon, 21 Mar 2011, Benjamin Herrenschmidt wrote:
>
> As long as the races to avoid are between map/unmap vs. access, yes, it
> -should- be fine, and we used to not do demand faulting on kernel space
> (but for how long ?). I'm wondering why we don't just stick a ptl in
> there or is there a good reason why we can't ?
We can - but we usually prefer to avoid unnecessary locking.
An arch function which locks init_mm.page_table_lock on powerpc,
but does nothing on others?
Hugh
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Benjamin Herrenschmidt @ 2011-03-21 2:22 UTC (permalink / raw)
To: Hugh Dickins
Cc: Jeremy Fitzhardinge, linuxppc-dev, Andrew Morton, Peter Zijlstra
In-Reply-To: <alpine.LSU.2.00.1103201901340.7257@sister.anvils>
On Sun, 2011-03-20 at 19:20 -0700, Hugh Dickins wrote:
> > As long as the races to avoid are between map/unmap vs. access, yes, it
> > -should- be fine, and we used to not do demand faulting on kernel space
> > (but for how long ?). I'm wondering why we don't just stick a ptl in
> > there or is there a good reason why we can't ?
>
> We can - but we usually prefer to avoid unnecessary locking.
> An arch function which locks init_mm.page_table_lock on powerpc,
> but does nothing on others?
That still means gratuitous differences between how the normal and
kernel page tables are handled. Maybe that's not worth bothering ...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
From: WANG Cong @ 2011-03-21 3:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, kexec, linux-kernel
In-Reply-To: <20110315165219.GA22509@in.ibm.com>
On Tue, 15 Mar 2011 22:22:19 +0530, Mahesh J Salgaonkar wrote:
> On Tue, Mar 15, 2011 at 03:52:38PM +0800, Américo Wang wrote:
>> On Tue, Mar 15, 2011 at 2:13 AM, Mahesh J Salgaonkar
>> <mahesh@linux.vnet.ibm.com> wrote:
>> >
>> > During free we do free all of them including RMO region. But since
>> > the rtas region is always on top of RMO, crashkernel memory overlaps
>> > rtas region and we endup freeing that even, which is causing the
>> > crash.
>> >
>> >
>> Okay, but with this patch applied, we will just ignore rtas region,
>> right?
> Correct.
>> Thus, when I echo 0 to free all the 128M crashkernel memory, the final
>> result will be 32M left, which means crash_size will still show 32M.
>> This looks odd.
>>
>> How about skipping the 32M as a whole? I mean once the region being
>> freed has overlap with this rtas region, skip the whole rtas region,
>> and let crash_size
>> show 0?
> The existing code from crash_shrink_memory() function reduces the crash
> size to 0 when echo'ed 0. I did test this patchset and verified that
> /sys/kernel/kexec_crash_size show 0 value.
Oh, ok.
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Thanks.
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Jeremy Fitzhardinge @ 2011-03-21 11:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andrew Morton, Hugh Dickins, Peter Zijlstra
In-Reply-To: <1300665188.2402.64.camel@pasglop>
On 03/20/2011 11:53 PM, Benjamin Herrenschmidt wrote:
> On Sat, 2011-03-19 at 21:11 -0700, Hugh Dickins wrote:
>> As I warned a few weeks ago, Jeremy has vmalloc apply_to_pte_range
>> patches in mmotm, which again assault PowerPC's expectations, and
>> cause lots of noise with CONFIG_PREEMPT=y CONFIG_PREEMPT_DEBUG=y.
>>
>> This time in vmalloc as well as vfree; and Peter's fix to the last
>> lot, which went into 2.6.38, doesn't protect against these ones.
>> Here's what I now see when I swapon and swapoff:
> Right. And we said from day one we had the HARD WIRED assumption that
> arch_enter/leave_lazy_mmu_mode() was ALWAYS going to be called within
> a PTE lock section, and we did get reassurance that it was going to
> remain so.
>
> So why is it ok for them to change those and break us like that ?
In general, the pagetable's locking rules are that all *usermode* pte
updates have to be done under a pte lock, but kernel mode ones do not;
they generally have some kind of per-subsystem ad-hoc locking where
needed, which may or may not be no-preempt.
Originally the enter/leave_lazy_mmu_mode did require preemption to be
disabled for the whole time, but that was incompatible with the above
locking rules, and resulted in preemption being disabled for long
periods when using lazy mode which wouldn't normally happen. This
raised a number of complaints.
To address this, I changed the x86 implementation to deal with
preemption in lazy mode by dropping out for lazy mode at context switch
time (and recording the fact that we were in lazy mode with a TIF flag
and re-entering on the next context switch).
> Seriously, this is going out of control. If we can't even rely on
> fundamental locking assumptions in the VM to remain reasonably stable
> or at least get some amount of -care- from who changes them as to
> whether they break others and work with us to fix them, wtf ?
>
> I don't know what the right way to fix that is. We have an absolute
> requirement that the batching we start within a lazy MMU section
> is complete and flushed before any other PTE in that section can be
> touched by anything else. Do we -at least- keep that guarantee ?
>
> If yes, then maybe preempt_disable/enable() around
> arch_enter/leave_lazy_mmu_mode() in apply_to_pte_range() would do...
>
> Or maybe I should just prevent any batching of init_mm :-(
I'm very sorry about that, I didn't realize power was also using that
interface. Unfortunately, the "no preemption" definition was an error,
and had to be changed to match the pre-existing locking rules.
Could you implement a similar "flush batched pte updates on context
switch" as x86?
J
^ permalink raw reply
* [PATCH 0/3] xics mask_irq fix and other patches
From: Milton Miller @ 2011-03-21 18:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Hi Ben.
I've submitted the fix for the xics mask real irq I mentioned.
During testing I realized current code is passing rtas a linux irq,
which means no interrupt (at least those above NR_IRQs) is being disabled.
I also created a patch to rename irq to hwirq in xics to try to make
the distiction more clear. For your consideration, I don't care if you
don't merge it especially with the upcoming rewrite.
Also, I am sending a printk to printk_once patch that affects BML.
Thanks,
milton
MAIL FROM: <miltonm@bga.com>
RCPT TO: <miltonm@bga.com>
RCPT TO: <linuxppc-dev@lists.ozlabs.org>
RCPT TO: <buytenh@secretlab.ca>
DATA
From: Milton Miller <miltonm@bga.com>
Subject: [PATCH 1/2] powerpc: xics: fix numberspace mismatch from irq_desc conversion
To: linuxppc-dev@lists.ozlabs.org
Cc: Lennert Buytenhek <buytenh@secretlab.ca>
Message-id: <xics-mask-irq-desc-fix@mdm.bga.com>
In-Reply-To: <patches-for-39-rc1@mdm.bga.com>
References: <patches-for-39-rc1@mdm.bga.com>
commit 79f26c268ebad29bd75d078cfc09d3d82b30ccbd (powerpc:
platforms/pseries irq_data conversion) pushed irq_desc down into many
functions, dererencing the descriptor irq field as late as possible.
But it incorrectly passed a linix virtural irq number to RTAS,
resulting in the interrupt not being disabled and possibly
other bad things, such as another interrupt being disabled and/or
a checkstop.
In addition this missed the point of xics_mask_unknown_vec and
the seperation of xics_mask_real_irq from xics_mask_irq. When
xics_mask_unknown_vec is called it's because the hardware delivered an
irq source for which we have no linux irq allocated, and thefore we can
not have an irq_desc allocated.
Revert xics_mask_real_irq to its prior version, naming the argument
hwirq to highlight the difference.
Signed-off-by: Milton Miller <miltonm@bga.com>
--
Lennert can you please review the other patches for similar problems?
Any reference to irq_map[x].hwirq is in a different number domain.
I initially saw the problem pushing irq_desc through unknown_vec
found this due to my knowledge of the split (I added that function)
and only realized the wrong number space when preparing to test the fix.
In fact I tried without the patch and my firmware checkstops the machine
(hardware stops executing instructions)!
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index 01fea46..5686db9 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -250,26 +250,26 @@ static unsigned int xics_startup(struct irq_data *d)
return 0;
}
-static void xics_mask_real_irq(struct irq_data *d)
+static void xics_mask_real_irq(unsigned int hwirq)
{
int call_status;
- if (d->irq == XICS_IPI)
+ if (hwirq == XICS_IPI)
return;
- call_status = rtas_call(ibm_int_off, 1, 1, NULL, d->irq);
+ call_status = rtas_call(ibm_int_off, 1, 1, NULL, hwirq);
if (call_status != 0) {
printk(KERN_ERR "%s: ibm_int_off irq=%u returned %d\n",
- __func__, d->irq, call_status);
+ __func__, hwirq, call_status);
return;
}
/* Have to set XIVE to 0xff to be able to remove a slot */
- call_status = rtas_call(ibm_set_xive, 3, 1, NULL, d->irq,
+ call_status = rtas_call(ibm_set_xive, 3, 1, NULL, hwirq,
default_server, 0xff);
if (call_status != 0) {
printk(KERN_ERR "%s: ibm_set_xive(0xff) irq=%u returned %d\n",
- __func__, d->irq, call_status);
+ __func__, hwirq, call_status);
return;
}
}
@@ -283,13 +283,13 @@ static void xics_mask_irq(struct irq_data *d)
irq = (unsigned int)irq_map[d->irq].hwirq;
if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
return;
- xics_mask_real_irq(d);
+ xics_mask_real_irq(irq);
}
static void xics_mask_unknown_vec(unsigned int vec)
{
printk(KERN_ERR "Interrupt %u (real) is invalid, disabling it.\n", vec);
- xics_mask_real_irq(irq_get_irq_data(vec));
+ xics_mask_real_irq(vec);
}
static inline unsigned int xics_xirr_vector(unsigned int xirr)
^ permalink raw reply related
* [PATCH] powerpc: pseries/smp: query-cpu-stopped-state support won't change
From: Milton Miller @ 2011-03-21 18:12 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <patches-for-39-rc1@mdm.bga.com>
If a given firmware doesn't have a token to support query-cpu-stopped-state,
its not likely to change during the lifetime of the kernel.
Only print this information once, not once per secondary thread.
While here, make the line wrap grep friendly.
Signed-off-by: Milton Miller <miltonm@bga.com>
Index: work.git/arch/powerpc/platforms/pseries/smp.c
===================================================================
--- work.git.orig/arch/powerpc/platforms/pseries/smp.c 2011-03-21 11:27:54.000000000 -0500
+++ work.git/arch/powerpc/platforms/pseries/smp.c 2011-03-21 11:29:51.000000000 -0500
@@ -64,8 +64,8 @@ int smp_query_cpu_stopped(unsigned int p
int qcss_tok = rtas_token("query-cpu-stopped-state");
if (qcss_tok == RTAS_UNKNOWN_SERVICE) {
- printk(KERN_INFO "Firmware doesn't support "
- "query-cpu-stopped-state\n");
+ printk_once(KERN_INFO
+ "Firmware doesn't support query-cpu-stopped-state\n");
return QCSS_HARDWARE_ERROR;
}
^ permalink raw reply
* [PATCH 2/2] powerpc: xics: use hwirq for xics domain irq number
From: Milton Miller @ 2011-03-21 18:12 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <patches-for-39-rc1@mdm.bga.com>
To try to avoid future confusion, rename irq to hwirq when it refers
to a xics domain number instead of a linux irq number.
Signed-off-by: Milton Miller <miltonm@bga.com>
Index: next.git/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2011-03-19 23:21:21.775085058 -0500
+++ next.git/arch/powerpc/platforms/pseries/xics.c 2011-03-20 00:57:33.144560092 -0500
@@ -204,33 +204,33 @@ static int get_irq_server(unsigned int v
static void xics_unmask_irq(struct irq_data *d)
{
- unsigned int irq;
+ unsigned int hwirq;
int call_status;
int server;
pr_devel("xics: unmask virq %d\n", d->irq);
- irq = (unsigned int)irq_map[d->irq].hwirq;
- pr_devel(" -> map to hwirq 0x%x\n", irq);
- if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
+ hwirq = (unsigned int)irq_map[d->irq].hwirq;
+ pr_devel(" -> map to hwirq 0x%x\n", hwirq);
+ if (hwirq == XICS_IPI || hwirq == XICS_IRQ_SPURIOUS)
return;
server = get_irq_server(d->irq, d->affinity, 0);
- call_status = rtas_call(ibm_set_xive, 3, 1, NULL, irq, server,
+ call_status = rtas_call(ibm_set_xive, 3, 1, NULL, hwirq, server,
DEFAULT_PRIORITY);
if (call_status != 0) {
printk(KERN_ERR
"%s: ibm_set_xive irq %u server %x returned %d\n",
- __func__, irq, server, call_status);
+ __func__, hwirq, server, call_status);
return;
}
/* Now unmask the interrupt (often a no-op) */
- call_status = rtas_call(ibm_int_on, 1, 1, NULL, irq);
+ call_status = rtas_call(ibm_int_on, 1, 1, NULL, hwirq);
if (call_status != 0) {
printk(KERN_ERR "%s: ibm_int_on irq=%u returned %d\n",
- __func__, irq, call_status);
+ __func__, hwirq, call_status);
return;
}
}
@@ -276,14 +276,14 @@ static void xics_mask_real_irq(unsigned
static void xics_mask_irq(struct irq_data *d)
{
- unsigned int irq;
+ unsigned int hwirq;
pr_devel("xics: mask virq %d\n", d->irq);
- irq = (unsigned int)irq_map[d->irq].hwirq;
- if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
+ hwirq = (unsigned int)irq_map[d->irq].hwirq;
+ if (hwirq == XICS_IPI || hwirq == XICS_IRQ_SPURIOUS)
return;
- xics_mask_real_irq(irq);
+ xics_mask_real_irq(hwirq);
}
static void xics_mask_unknown_vec(unsigned int vec)
@@ -373,37 +373,37 @@ static unsigned char pop_cppr(void)
static void xics_eoi_direct(struct irq_data *d)
{
- unsigned int irq = (unsigned int)irq_map[d->irq].hwirq;
+ unsigned int hwirq = (unsigned int)irq_map[d->irq].hwirq;
iosync();
- direct_xirr_info_set((pop_cppr() << 24) | irq);
+ direct_xirr_info_set((pop_cppr() << 24) | hwirq);
}
static void xics_eoi_lpar(struct irq_data *d)
{
- unsigned int irq = (unsigned int)irq_map[d->irq].hwirq;
+ unsigned int hwirq = (unsigned int)irq_map[d->irq].hwirq;
iosync();
- lpar_xirr_info_set((pop_cppr() << 24) | irq);
+ lpar_xirr_info_set((pop_cppr() << 24) | hwirq);
}
static int
xics_set_affinity(struct irq_data *d, const struct cpumask *cpumask, bool force)
{
- unsigned int irq;
+ unsigned int hwirq;
int status;
int xics_status[2];
int irq_server;
- irq = (unsigned int)irq_map[d->irq].hwirq;
- if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
+ hwirq = (unsigned int)irq_map[d->irq].hwirq;
+ if (hwirq == XICS_IPI || hwirq == XICS_IRQ_SPURIOUS)
return -1;
- status = rtas_call(ibm_get_xive, 1, 3, xics_status, irq);
+ status = rtas_call(ibm_get_xive, 1, 3, xics_status, hwirq);
if (status) {
printk(KERN_ERR "%s: ibm,get-xive irq=%u returns %d\n",
- __func__, irq, status);
+ __func__, hwirq, status);
return -1;
}
@@ -418,11 +418,11 @@ xics_set_affinity(struct irq_data *d, co
}
status = rtas_call(ibm_set_xive, 3, 1, NULL,
- irq, irq_server, xics_status[1]);
+ hwirq, irq_server, xics_status[1]);
if (status) {
printk(KERN_ERR "%s: ibm,set-xive irq=%u returns %d\n",
- __func__, irq, status);
+ __func__, hwirq, status);
return -1;
}
@@ -874,7 +874,7 @@ void xics_kexec_teardown_cpu(int seconda
void xics_migrate_irqs_away(void)
{
int cpu = smp_processor_id(), hw_cpu = hard_smp_processor_id();
- unsigned int irq, virq;
+ int virq;
/* If we used to be the default server, move to the new "boot_cpuid" */
if (hw_cpu == default_server)
@@ -892,6 +892,7 @@ void xics_migrate_irqs_away(void)
for_each_irq(virq) {
struct irq_desc *desc;
struct irq_chip *chip;
+ unsigned int hwirq;
int xics_status[2];
int status;
unsigned long flags;
@@ -901,9 +902,9 @@ void xics_migrate_irqs_away(void)
continue;
if (irq_map[virq].host != xics_host)
continue;
- irq = (unsigned int)irq_map[virq].hwirq;
+ hwirq = (unsigned int)irq_map[virq].hwirq;
/* We need to get IPIs still. */
- if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
+ if (hwirq == XICS_IPI || hwirq == XICS_IRQ_SPURIOUS)
continue;
desc = irq_to_desc(virq);
@@ -918,10 +919,10 @@ void xics_migrate_irqs_away(void)
raw_spin_lock_irqsave(&desc->lock, flags);
- status = rtas_call(ibm_get_xive, 1, 3, xics_status, irq);
+ status = rtas_call(ibm_get_xive, 1, 3, xics_status, hwirq);
if (status) {
printk(KERN_ERR "%s: ibm,get-xive irq=%u returns %d\n",
- __func__, irq, status);
+ __func__, hwirq, status);
goto unlock;
}
^ 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