On Tue, Sep 08, 2015 at 04:08:06PM +1000, Michael Ellerman wrote:
> On Wed, 2015-08-12 at 10:53 +0530, Bharata B Rao wrote:
> > On Tue, Aug 11, 2015 at 03:48:26PM +0200, Andrea Arcangeli wrote:
> > > Hello Bharata,
> > >
> > > On Tue, Aug 11, 2015 at 03:37:29PM +0530, Bharata B Rao wrote:
> > > >
On Wed, 2015-08-12 at 10:53 +0530, Bharata B Rao wrote:
> On Tue, Aug 11, 2015 at 03:48:26PM +0200, Andrea Arcangeli wrote:
> > Hello Bharata,
> >
> > On Tue, Aug 11, 2015 at 03:37:29PM +0530, Bharata B Rao wrote:
> > > May be it is a bit late to bring this up, but I needed the following fix
> > >
Hi all,
I'm running this kernel:
[ +0.00] Linux version 3.16.0-4-powerpc64
(debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian
4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
on my Xserve G5, and it works great except these messages keep
coming in dmesg:
[Sep 4 19:11] i2c
On 09/07/2015 10:40 AM, Michael Ellerman wrote:
On Fri, 2015-09-04 at 17:51 -0300, Arnaldo Carvalho de Melo wrote:
Em Tue, Sep 01, 2015 at 12:18:47PM +0530, Hemant Kumar escreveu:
Should I try to process the 5 together, applying thest two first?
Yes, this patchset needs to be applied befo
On Mon, 2015-09-07 at 16:24 +0200, Christophe Leroy wrote:
> memcpy() uses instruction dcbz to speed up copy by not wasting time
> loading cache line with data that will be overwritten.
> Some platform like mpc52xx do no have cache active at startup and
> can therefore not use memcpy(). Allthough n
On Mon, 2015-09-07 at 10:59 +, David Laight wrote:
> From: Michal Sojka
> > >> I think GCC uses memcpy() in well known situations like initialising
> > >> structures or copying structures.
> > >> Shouldn't we just avoid this kind of actions in the very few early init
> > >> functions ?
> > > Wh
On Mon, 2015-09-07 at 13:39 +0300, Denis Kirjanov wrote:
> On 9/7/15, Michael Ellerman wrote:
> > On Mon, 2015-09-07 at 10:30 +0300, Denis Kirjanov wrote:
> >> On 6/19/15, Benjamin Herrenschmidt wrote:
> >> > On Thu, 2015-06-18 at 17:34 +0300, Denis Kirjanov wrote:
> >> >> On 6/12/15, Denis Kirja
On 07.09.2015 [19:19:09 +1000], Michael Ellerman wrote:
> On Fri, 2015-09-04 at 11:22 -0700, Nishanth Aravamudan wrote:
> > The 32-bit TCE table initialization relies on the DMA window having a
> > size equal to a power of 2 (and checks for it explicitly). But
> > crashkernel= has no constraint tha
On Mon, Sep 07, 2015 at 07:29:42PM +1000, Michael Ellerman wrote:
> On Mon, 2015-24-08 at 11:20:25 UTC, Kevin Hao wrote:
> > This function is only used by get_vtb(). They are almost the same
> > except the reading from the real register. Move the mfspr() to
> > get_vtb() and kill the function mfvtb
On 09/07/2015 12:10 AM, Michael Ellerman wrote:
But we later removed pci_msi_off() completely, so I think we probably
*could* call pci_msi_setup_pci_dev() from pci_init_capabilities().
That would be much nicer because it makes more sense there, and it
would do the right thing for powerpc and sp
On Sun, 2015-09-06 at 17:44 +0300, Michael S. Tsirkin wrote:
My question is: is necessary to initialize MSI capabilities even with
CONFIG_PCI_MSI not set? In negative case, would be "cleaner" revert the 3
commits, right?
I think the reason why it's necessary is explained in
commit log for co
On 07/17/2015 01:47 PM, Kamalesh Babulal wrote:
* Michael Ellerman [2015-07-16 14:05:52]:
[..]
Why are we even getting these reset events when nothing has happened?
Thanks for the review. It was seen only on one machine, couldn't
get hold of the machine any more. I am guessing here, that it
Allow it to be used from SPU, since it should not have unwanted
side-effects.
[ Picked-by: Michael Ellerman ]
Signed-off-by: Mathieu Desnoyers
CC: Andrew Morton
CC: linux-...@vger.kernel.org
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: linuxppc-dev@lists.ozlabs.org
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: David Vrabel
Cc: Boris Ostrovsky
Cc: linuxppc-dev@lists.ozlabs.org
Changes in v4:
- The ring is always 4K (
From: Christophe Leroy
> Sent: 07 September 2015 15:25
...
> diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
> index 2ef50c6..05b3096 100644
> --- a/arch/powerpc/lib/copy_32.S
> +++ b/arch/powerpc/lib/copy_32.S
> @@ -172,7 +172,16 @@ _GLOBAL(memcpy)
> mtctr r0
> b
On Mon, Sep 07 2015, Christophe Leroy wrote:
> memcpy() uses instruction dcbz to speed up copy by not wasting time
> loading cache line with data that will be overwritten.
> Some platform like mpc52xx do no have cache active at startup and
> can therefore not use memcpy(). Allthough no part of the
memcpy() uses instruction dcbz to speed up copy by not wasting time
loading cache line with data that will be overwritten.
Some platform like mpc52xx do no have cache active at startup and
can therefore not use memcpy(). Allthough no part of the code
explicitly uses memcpy(), GCC makes calls to it.
FYI:
On 07 September 2015 at 11:07 AM, Boris Reinhard
[debian-powe...@lists.debian.org] wrote:
Off-list reply, please don't quote/ forward
Hi,
wrong list, please use this one if you want to reach ppl that do
active work on ppc:
https://lists.ozlabs.org/listinfo/linuxppc-dev
Come to thin
On 4.9.2015 21:49, Michal Sojka wrote:
On 4.9.2015 20:10, christophe leroy wrote:
Le 04/09/2015 16:35, Michal Sojka a écrit :
On Fri, Sep 04 2015, Christophe LEROY wrote:
Le 04/09/2015 15:33, Michal Sojka a écrit :
Dear Christophe,
my MPC5200-based system stopped booting recently. I bisect
One other thing.
The way to present all the people who submitted, such that each one got some
amount of exposure, was a dynamic thing that just occurred to me as we were
setting up.
Sort of like you first starting to select the judging panels, by ‘guessing’ a
number… which didn’t work very wel
On 4.9.2015 20:10, christophe leroy wrote:
Le 04/09/2015 16:35, Michal Sojka a écrit :
On Fri, Sep 04 2015, Christophe LEROY wrote:
Le 04/09/2015 15:33, Michal Sojka a écrit :
Dear Christophe,
my MPC5200-based system stopped booting recently. I bisected the
problem
to your commit below. I
On Fri, Sep 04 2015, Christophe LEROY wrote:
> Le 04/09/2015 15:33, Michal Sojka a écrit :
>> Dear Christophe,
>>
>> my MPC5200-based system stopped booting recently. I bisected the problem
>> to your commit below. If I revert that commit (on top of
>> 807249d3ada1ff28a47c4054ca4edd479421b671 = v4.
Dear Christophe,
my MPC5200-based system stopped booting recently. I bisected the problem
to your commit below. If I revert that commit (on top of
807249d3ada1ff28a47c4054ca4edd479421b671 = v4.2-6663-g807249d), my
system boots again.
commit 0b05e2d671c40cfb57e66e4e402320d6e056b2f8
Author: LEROY C
From: Michal Sojka
> >> I think GCC uses memcpy() in well known situations like initialising
> >> structures or copying structures.
> >> Shouldn't we just avoid this kind of actions in the very few early init
> >> functions ?
> > Which are the "very few" early init functions? Can you make a list, f
On 9/7/15, Michael Ellerman wrote:
> On Mon, 2015-09-07 at 10:30 +0300, Denis Kirjanov wrote:
>> On 6/19/15, Benjamin Herrenschmidt wrote:
>> > On Thu, 2015-06-18 at 17:34 +0300, Denis Kirjanov wrote:
>> >> On 6/12/15, Denis Kirjanov wrote:
>> >> > Fix the memory leak in create_gatt_table:
>> >>
On Mon, 2015-09-07 at 10:30 +0300, Denis Kirjanov wrote:
> On 6/19/15, Benjamin Herrenschmidt wrote:
> > On Thu, 2015-06-18 at 17:34 +0300, Denis Kirjanov wrote:
> >> On 6/12/15, Denis Kirjanov wrote:
> >> > Fix the memory leak in create_gatt_table:
> >> > we've lost a kfree on the exit path for
On Mon, Sep 07, 2015 at 07:22:04PM +1000, Michael Ellerman wrote:
> On Fri, 2015-04-09 at 10:04:12 UTC, Bharata B Rao wrote:
> > From: Bharata B Rao
> >
> > dlpar_cpu_probe() should release the acquired DRC if configure_connector
> > call fails.
> >
> > Signed-off-by: Bharata B Rao
> > Cc: Nath
From: Bharata B Rao
Commit f32393c943e2 ("powerpc/pseries: Correct cpu affinity for
dlpar added cpus") moved dlpar_acquire_drc() call to before
dlpar_configure_connector() call in dlpar_cpu_probe(), but missed
to release the DRC if dlpar_configure_connector() failed.
During CPU hotplug, if config
On 7.9.2015 10:40, Michael Ellerman wrote:
On Mon, 2015-09-07 at 09:08 +0200, Christophe LEROY wrote:
Hi Michael
Le 07/09/2015 03:14, Michael Ellerman a écrit :
On Sun, 2015-09-06 at 23:01 +0200, Michal Sojka wrote:
I found the problem. The compiler replaces an assignment with a call to
memcp
On Mon, 2015-24-08 at 11:20:25 UTC, Kevin Hao wrote:
> This function is only used by get_vtb(). They are almost the same
> except the reading from the real register. Move the mfspr() to
> get_vtb() and kill the function mfvtb(). With this, we can eliminate
> the use of cpu_has_feature() in very cor
On Fri, 2015-04-09 at 10:04:12 UTC, Bharata B Rao wrote:
> From: Bharata B Rao
>
> dlpar_cpu_probe() should release the acquired DRC if configure_connector
> call fails.
>
> Signed-off-by: Bharata B Rao
> Cc: Nathan Fontenot
> Reviewed-by: Nathan Fontenot
Which commit caused this to be a bug
On Fri, 2015-09-04 at 11:22 -0700, Nishanth Aravamudan wrote:
> The 32-bit TCE table initialization relies on the DMA window having a
> size equal to a power of 2 (and checks for it explicitly). But
> crashkernel= has no constraint that requires a power-of-2 be specified.
> This causes the kdump ke
On Fri, Sep 04, 2015 at 05:50:09PM +0100, Marc Zyngier wrote:
> When pci-host-generic looks for the probe-only property, it seems
> to trust the DT to be correctly written, and assumes that there
> is a parameter to the property.
>
> Unfortunately, this is not always the case, and some firmware ex
On Fri, 2015-09-04 at 17:50 +0100, Marc Zyngier wrote:
> When find_and_init_phbs() looks for the probe-only property, it seems
> to trust the firmware to be correctly written, and assumes that there
> is a parameter to the property.
>
> It is conceivable that the firmware could not be that perfect
On Mon, 2015-09-07 at 16:33 +1000, Ian Munsie wrote:
> No worries. I've been caught out by something similar in the past when I
> assumed that something like this:
>
> if (foo)
> /*
>* A big long
>* multiline
>* block comment!
>*/
>do_something()
>
>
On Mon, 2015-09-07 at 09:08 +0200, Christophe LEROY wrote:
> Hi Michael
>
> Le 07/09/2015 03:14, Michael Ellerman a écrit :
> > On Sun, 2015-09-06 at 23:01 +0200, Michal Sojka wrote:
> >> I found the problem. The compiler replaces an assignment with a call to
> >> memcpy. The following patch fixes
On 6/19/15, Benjamin Herrenschmidt wrote:
> On Thu, 2015-06-18 at 17:34 +0300, Denis Kirjanov wrote:
>> On 6/12/15, Denis Kirjanov wrote:
>> > Fix the memory leak in create_gatt_table:
>> > we've lost a kfree on the exit path for the pages array allocated
>> > in uninorth_create_gatt_table
>> >
>
After commit e2b3d202d1dba8f3546ed28224ce485bc50010be
("powerpc: Switch 16GB and 16MB explicit hugepages to a
different page table format"), we don't need to support
is_hugepd() for 64K page size.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/page.h | 15 +++
arch/powe
Hi Michael
Le 07/09/2015 03:14, Michael Ellerman a écrit :
Hi Michal,
Thanks for finding the problem.
On Sun, 2015-09-06 at 23:01 +0200, Michal Sojka wrote:
I found the problem. The compiler replaces an assignment with a call to
memcpy. The following patch fixes the problem for me. However, I
39 matches
Mail list logo
