On Wed, Mar 09, 2011 at 06:51:44PM +1100, Benjamin Herrenschmidt wrote:
> > > > -static void mpic_unmask_ht_irq(unsigned int irq)
> > > > +static void mpic_unmask_ht_irq(struct irq_data *d)
> > > > {
> > > > - struct mpic *mpic = mpic_from_irq(irq);
> > > > - unsigned int src = mpic_irq_to_hw
Signed-off-by: Lennert Buytenhek
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/include/asm/mpic.h |6 +-
arch/powerpc/platforms/pasemi/setup.c |4 +-
arch/powerpc/sysdev/mpic.c| 137 +
arch/powerpc/sysde
Signed-off-by: Lennert Buytenhek
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/platforms/52xx/media5200.c | 21
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 26 +-
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 80 ++-
Signed-off-by: Lennert Buytenhek
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 27 -
1 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
b/arch
Signed-off-by: Lennert Buytenhek
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/platforms/embedded6xx/flipper-pic.c | 32
arch/powerpc/platforms/embedded6xx/hlwd-pic.c| 41 +++--
2 files changed, 37 insertions(+), 36 delet
Signed-off-by: Lennert Buytenhek
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/sysdev/mpc8xxx_gpio.c | 42 ++--
1 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c
b/arch/powerpc/
Signed-off-by: Lennert Buytenhek
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/platforms/ps3/interrupt.c | 40
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/interrupt.c
b/arch/powe
Signed-off-by: Lennert Buytenhek
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/include/asm/qe_ic.h | 19 +++
arch/powerpc/sysdev/qe_lib/qe_ic.c | 25 +++--
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a
Signed-off-by: Lennert Buytenhek
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/sysdev/uic.c | 59 +++--
1 files changed, 30 insertions(+), 29 deletions(-)
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic
Signed-off-by: Lennert Buytenhek
---
v2: get_irq_chip_data(d->irq) => irq_data_get_irq_chip_data(d)
arch/powerpc/sysdev/xilinx_intc.c | 48 +++-
1 files changed, 25 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/sysdev/xilinx_intc.c
b/arch/powerpc/sy
On Wed, 2011-03-09 at 13:58 +1100, Benjamin Herrenschmidt wrote:
> So I've been experiencing hangs shortly after boot with recent kernels
> on a Power7 machine. I was testing with PREEMPT & HZ=1024 which might
> increase the frequency of the problem but I don't think they are
> necessary to expose
On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > It appears that this corresponds to one CPU deciding to rebuild the
> > sched domains. There's various reasons why that can happen, the typical
> > one in our case is the new VPNH feature where the hypervisor informs us
> > of a change in
On Wed, Mar 09, 2011 at 12:02:06PM +0530, Mahesh Jagannath Salgaonkar wrote:
>On 08/25/2010 06:07 AM, Eric W. Biederman wrote:
>> Anton Blanchard writes:
>>
>>> On ppc64 the crashkernel region almost always overlaps an area of firmware.
>>> This works fine except when using the sysfs interface to
Hi,
> The crashkernel region is specified via kernel cmdline, so why
> not just drop a failure when it overlaps with RMO region?
> Am I missing something?
Unfortunately a ppc64 kernel requires a chunk of RMO memory. We would
need the ability to specify multiple crashkernel regions - about 32MB
i
On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> No, the domain stuff is good, we allocate new domains and have a
> synchronize_sched() between us installing the new ones and freeing the
> old ones.
Gah, if only..
___
Linuxppc-dev mailing list
On Wed, 09 Mar 2011 12:33:49 +0100
Peter Zijlstra wrote:
> On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > > It appears that this corresponds to one CPU deciding to rebuild the
> > > sched domains. There's various reasons why that can happen, the typical
> > > one in our case is the
On Wed, 2011-03-09 at 14:15 +0100, Martin Schwidefsky wrote:
> On Wed, 09 Mar 2011 12:33:49 +0100
> Peter Zijlstra wrote:
>
> > On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > > > It appears that this corresponds to one CPU deciding to rebuild the
> > > > sched domains. There's vario
On Wed, 09 Mar 2011 14:19:29 +0100
Peter Zijlstra wrote:
> On Wed, 2011-03-09 at 14:15 +0100, Martin Schwidefsky wrote:
> > On Wed, 09 Mar 2011 12:33:49 +0100
> > Peter Zijlstra wrote:
> >
> > > On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > > > > It appears that this corresponds
On Wed, 2011-03-09 at 14:31 +0100, Martin Schwidefsky wrote:
> > But if you don't also update the cpu->node memory mappings (which I
> > think it near impossible) what good is it to change the scheduler
> > topology?
>
> The memory for the different LPARs is striped over all nodes (or books as we
On Wed, 09 Mar 2011 14:33:56 +0100
Peter Zijlstra wrote:
> On Wed, 2011-03-09 at 14:31 +0100, Martin Schwidefsky wrote:
> > > But if you don't also update the cpu->node memory mappings (which I
> > > think it near impossible) what good is it to change the scheduler
> > > topology?
> >
> > The me
On Wed, 2011-03-09 at 14:46 +0100, Martin Schwidefsky wrote:
> On Wed, 09 Mar 2011 14:33:56 +0100
> Peter Zijlstra wrote:
>
> > On Wed, 2011-03-09 at 14:31 +0100, Martin Schwidefsky wrote:
> > > > But if you don't also update the cpu->node memory mappings (which I
> > > > think it near impossible
On Wed, Mar 09, 2011 at 05:09:09AM -0800, Michel Lespinasse wrote:
> On Tue, Mar 8, 2011 at 4:31 PM, Stephen Wilson wrote:
> > Morally, the question of whether an address lies in a gate vma should be
> > asked
> > with respect to an mm, not a particular task.
> >
> > Practically, dropping the dep
On Wed, Mar 09, 2011 at 11:46:57PM +1100, Anton Blanchard wrote:
>
>Hi,
>
>> The crashkernel region is specified via kernel cmdline, so why
>> not just drop a failure when it overlaps with RMO region?
>> Am I missing something?
>
>Unfortunately a ppc64 kernel requires a chunk of RMO memory. We woul
On Wed, Mar 09, 2011 at 12:33:49PM +0100, Peter Zijlstra wrote:
>
> That is of course aside from the fact that we have a real bug there that
> needs fixing, but really guys, WTF!
They just wanted to give you a very nice reproducer for that bug ;)
-- Steve
___
On Tue, Mar 8, 2011 at 4:31 PM, Stephen Wilson wrote:
> Morally, the question of whether an address lies in a gate vma should be asked
> with respect to an mm, not a particular task.
>
> Practically, dropping the dependency on task_struct will help make current and
> future operations on mm's more
Hi all,
I have a slightly off-topic question regarding the use of mpc52xx_lpbfifo_submit()
& friends...
In struct mpc52xx_lpbfifo_request, the element 'data' (with address 'data_phys') is
apparently the chunk of data which is transferred through bestcomm, right? Dumb
question: has this chunk
This feature triggers nasty races in the scheduler between the
rebuilding of the topology and the load balancing code, causing
the machine to hang.
Disable it for now until the races are fixed.
Signed-off-by: Benjamin Herrenschmidt
---
Jesse: I'm sending that to Linus now. We'll sort things out
On Thu, 2011-03-10 at 10:00 +1100, Benjamin Herrenschmidt wrote:
> This feature triggers nasty races in the scheduler between the
> rebuilding of the topology and the load balancing code, causing
> the machine to hang.
>
> Disable it for now until the races are fixed.
>
> Signed-off-by: Benjamin
On Mon, 2011-03-07 at 21:34 -0800, Nishanth Aravamudan wrote:
> On 03.03.2011 [23:24:44 -0800], Nishanth Aravamudan wrote:
> > On 04.03.2011 [14:01:24 +1100], Michael Ellerman wrote:
> > > Looking closer at your patch, now I don't understand :)
> > >
> > > + /*
> > > +* disabling MSI
On Thu, 2011-03-03 at 19:29 -0800, Joe Perches wrote:
> On Fri, 2011-03-04 at 14:06 +1100, Michael Ellerman wrote:
> > On Thu, 2011-03-03 at 17:41 -0800, Nishanth Aravamudan wrote:
> > > On 04.03.2011 [12:05:29 +1100], Michael Ellerman wrote:
> > > > Cc: Me :)
> > > Sorry! I was in a hurry to get
Hi Linus !
Here's a pair of regression fixes for 2.6.38. One fixes a 2.6.37
regression (I'll send it to -stable separately) that breaks booting on
legacy iSeries, and the other one disables a newly introduced features
as it triggers nasty races in the scheduler that causes hangs and seem
to be too
On Thu, 2011-03-10 at 10:12 +1100, Michael Ellerman wrote:
> True my last patch may have been two years ago, but I _wrote the entire
> file_, and essentially no one else has ever touched it.
>
> > $ ./scripts/get_maintainer.pl -f arch/powerpc/platforms/pseries/msi.c
> > Benjamin Herrenschmidt (su
On 09.03.2011 [16:28:23 -0800], Joe Perches wrote:
> On Thu, 2011-03-10 at 10:12 +1100, Michael Ellerman wrote:
> > True my last patch may have been two years ago, but I _wrote the entire
> > file_, and essentially no one else has ever touched it.
> >
> > > $ ./scripts/get_maintainer.pl -f arch/po
Add SEC4 device tree binding documentation and add a SEC4
device node to the P4080's dts.
Signed-off-by: Steve Cornelius
Signed-off-by: Kim Phillips
---
.../devicetree/bindings/crypto/fsl-sec4.txt| 409
arch/powerpc/boot/dts/p4080ds.dts | 95
splitting and resending due to apparent 100KB message limit imposed by
linux-crypto and devicetree-discuss mailing lists.
No content has been changed from the original post that made it through
linuxppc-dev's 400KB limit, available here:
http://patchwork.ozlabs.org/patch/86051/
.../devicetree/b
Dear Wolfram,
Though register-set looks identical but features were different. And also
manufacturer is different.
But still it might be possible that we can reuse ds1307.c with some
modification.
But if I look at the drivers present in drivers/rtc folder. Most of them looks
similar but still t
On Wed, 2011-03-09 at 16:28 -0800, Joe Perches wrote:
> On Thu, 2011-03-10 at 10:12 +1100, Michael Ellerman wrote:
> > True my last patch may have been two years ago, but I _wrote the entire
> > file_, and essentially no one else has ever touched it.
> >
> > > $ ./scripts/get_maintainer.pl -f arch
On Tue, 2011-03-08 at 17:37 +1100, Benjamin Herrenschmidt wrote:
> Signed-off-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/kernel/smp.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index e337073..60233
On Thu, 2011-03-10 at 14:35 +1100, Michael Ellerman wrote:
> On Wed, 2011-03-09 at 16:28 -0800, Joe Perches wrote:
> > On Thu, 2011-03-10 at 10:12 +1100, Michael Ellerman wrote:
> > > True my last patch may have been two years ago, but I _wrote the entire
> > > file_, and essentially no one else ha
On Thu, 2011-03-10 at 14:41 +1100, Michael Ellerman wrote:
>
> So the SYSTEM_RUNNING check is to avoid clashing with the logic in
> smp_setup_cpu_maps() I presume:
>
> arch/powerpc/kernel/setup-common.c: vdso_data->processorCount =
> num_present_cpus();
>
>
> But why not remove that, and l
Am 10.03.2011 04:50 schrieb "Joe Perches" :
>
> On Thu, 2011-03-10 at 14:35 +1100, Michael Ellerman wrote:
> > On Wed, 2011-03-09 at 16:28 -0800, Joe Perches wrote:
> > > On Thu, 2011-03-10 at 10:12 +1100, Michael Ellerman wrote:
> > > > True my last patch may have been two years ago, but I _wrote
41 matches
Mail list logo
