On Wed, Jan 16, 2019 at 6:09 AM Michael Ellerman wrote:
>
> Christophe Leroy writes:
> > Le 15/01/2019 à 08:26, Mathieu Malaterre a écrit :
> ...
> >>
> >> I did check that `custom_defconfig` is the minimal defconfig generated
> >> by `savedefconfig` in both cases.
> >>
> >> Hints or comments wel
Le 16/01/2019 à 07:21, Anshuman Khandual a écrit :
All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
__GFP_ZERO) and using it for allocating page table pages. This causes some
code duplication which can be easily avoided. GFP_KERNEL allocated and
cleared out pages (__
On Wed 16-01-19 11:51:32, Anshuman Khandual wrote:
> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
> __GFP_ZERO) and using it for allocating page table pages. This causes some
> code duplication which can be easily avoided. GFP_KERNEL allocated and
> cleared out pages
Tobias Ulmer writes:
> Hi,
>
> both the latest stable 4.20.2 and 5.0 rc2+ hang early on the G5 Quad.
>
> Surely I'm not the first to run into this, but I couldn't find any
> discussion or bug report. Sorry if you're already aware.
Actually you're probably the first to hit it :)
I have a quad but
On Wed, Jan 16, 2019 at 11:51:32AM +0530, Anshuman Khandual wrote:
> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
> __GFP_ZERO) and using it for allocating page table pages. This causes some
> code duplication which can be easily avoided. GFP_KERNEL allocated and
> cl
Le 16/01/2019 à 01:35, Jonathan Neuschäfer a écrit :
On Tue, Jan 15, 2019 at 07:51:01AM +0100, Christophe Leroy wrote:
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
[...]
I've checked it patch-by-patch now (with STRICT_KERNEL_RWX):
- patches 1 and 2 build and boot fine
- patches 3 t
All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
__GFP_ZERO) and using it for allocating page table pages. This causes some
code duplication which can be easily avoided. GFP_KERNEL allocated and
cleared out pages (__GFP_ZERO) are required for page tables on any given
arch
Christophe Leroy writes:
> Le 15/01/2019 à 08:26, Mathieu Malaterre a écrit :
...
>>
>> I did check that `custom_defconfig` is the minimal defconfig generated
>> by `savedefconfig` in both cases.
>>
>> Hints or comments welcome, thanks much.
>
> I think you should do:
>
> make ARCH=powerpc CROSS
-Original Message-
From: Rob Herring
Sent: 2019年1月11日 22:31
To: Xiaowei Bao
Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
shawn...@kernel.org; Leo Li ; kis...@ti.com;
lorenzo.pieral...@arm.com; a...@arndb.de; gre...@linuxfoundation.org; M.h. Lian
; Mingkai Hu ;
Hi Michael,
Thanks for your email.
On Mon, 14 Jan 2019 at 17:06, Michael Ellerman wrote:
> nxt=0
> while read nr abi name entry compat ; do
> - printf "#define __NR_%s%s\t%s\n" \
> - "${prefix}" "${name}" "${nr}"
> + printf "#defi
On Tue, 2019-01-15 at 23:49 +0100, Tobias Ulmer wrote:
> Hi,
>
> both the latest stable 4.20.2 and 5.0 rc2+ hang early on the G5 Quad.
>
> Surely I'm not the first to run into this, but I couldn't find any
> discussion or bug report. Sorry if you're already aware.
>
> You can see it hang here (5
On Tue, Jan 15, 2019 at 07:51:01AM +0100, Christophe Leroy wrote:
> Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
[...]
> > I've checked it patch-by-patch now (with STRICT_KERNEL_RWX):
> >
> > - patches 1 and 2 build and boot fine
> > - patches 3 to 6 build, but fail to boot with this error
Arnd Bergmann writes:
> On Mon, Jan 14, 2019 at 12:36 PM Michael Ellerman wrote:
>>
>> We never pass a value for offset, nor do we need to, so remove the
>> offset logic.
>>
>> Signed-off-by: Michael Ellerman
>
> This change and the next three defeat the idea of having a shared script
> across
Arnd Bergmann writes:
> On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman wrote:
>> Arnd Bergmann writes:
>> > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
>> > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++
>> > arch/powerpc/kernel/syscalls/syscall.tbl | 12
Arnd Bergmann writes:
> On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
>>
>> On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman wrote:
>> > Arnd Bergmann writes:
>> > > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
>> > > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 ++
Hi,
both the latest stable 4.20.2 and 5.0 rc2+ hang early on the G5 Quad.
Surely I'm not the first to run into this, but I couldn't find any
discussion or bug report. Sorry if you're already aware.
You can see it hang here (5.0 rc2+, 4.20.2 is nearly identical) until
the watchdog triggers a rebo
Le 15/01/2019 à 08:26, Mathieu Malaterre a écrit :
[Sorry to hijack this thread. ]
On Tue, Jan 15, 2019 at 5:22 AM Andrew Donnellan
wrote:
kcov provides kernel coverage data that's useful for fuzzing tools like
syzkaller.
Wire up kcov support on powerpc. Disable kcov instrumentation on th
On Tue, Jan 15, 2019 at 5:36 PM Geert Uytterhoeven wrote:
> On Tue, Jan 15, 2019 at 4:19 PM Arnd Bergmann wrote:
> > On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
> > > On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman
> > > wrote:
> > > > Arnd Bergmann writes:
> > > > > arch/m68k/kern
On Tue, Jan 08, 2019 at 01:05:51PM +, Viorel Suman wrote:
> Add the DT binding documentation for Audio Mixer
> machine driver.
>
> Signed-off-by: Viorel Suman
> ---
> .../devicetree/bindings/sound/imx-audmix.txt | 24
> ++
> 1 file changed, 24 insertions(+)
> crea
On Tue, 8 Jan 2019 13:05:47 +, Viorel Suman wrote:
> Add the DT binding documentation for NXP Audio Mixer
> CPU DAI driver.
>
> Signed-off-by: Viorel Suman
> ---
> .../devicetree/bindings/sound/fsl,audmix.txt | 44
> ++
> 1 file changed, 44 insertions(+)
> create
On 1/15/19 2:14 PM, Dmitry Vyukov wrote:
> On Tue, Jan 15, 2019 at 8:27 AM Christophe Leroy
> wrote:
>> On 01/14/2019 09:34 AM, Dmitry Vyukov wrote:
>>> On Sat, Jan 12, 2019 at 12:16 PM Christophe Leroy
>>> wrote:
>>> >
>>> > In kernel/cputable.c, explicitly use memcpy() in order
>>> > to allo
Le 15/01/2019 à 18:10, Dmitry Vyukov a écrit :
On Tue, Jan 15, 2019 at 6:06 PM Andrey Ryabinin wrote:
On 1/15/19 2:14 PM, Dmitry Vyukov wrote:
On Tue, Jan 15, 2019 at 8:27 AM Christophe Leroy
wrote:
On 01/14/2019 09:34 AM, Dmitry Vyukov wrote:
On Sat, Jan 12, 2019 at 12:16 PM Christop
On 1/12/19 2:16 PM, Christophe Leroy wrote:
> +KASAN_SANITIZE_early_32.o := n
> +KASAN_SANITIZE_cputable.o := n
> +KASAN_SANITIZE_prom_init.o := n
> +
Usually it's also good idea to disable branch profiling - define
DISABLE_BRANCH_PROFILING
either in top of these files or via Makefile. Branch
On Tue, Jan 15, 2019 at 6:06 PM Andrey Ryabinin wrote:
>
>
>
> On 1/15/19 2:14 PM, Dmitry Vyukov wrote:
> > On Tue, Jan 15, 2019 at 8:27 AM Christophe Leroy
> > wrote:
> >> On 01/14/2019 09:34 AM, Dmitry Vyukov wrote:
> >>> On Sat, Jan 12, 2019 at 12:16 PM Christophe Leroy
> >>> wrote:
> >>> >
>
'nobats' kernel parameter or some options like CONFIG_DEBUG_PAGEALLOC
deny the use of BATS for mapping memory.
This patch makes sure that the specific wii RAM mapping function
takes it into account as well.
Fixes: de32400dd26e ("wii: use both mem1 and mem2 as ram")
Cc: sta...@vger.kernel.org
Sign
Hi Arnd,
On Tue, Jan 15, 2019 at 4:19 PM Arnd Bergmann wrote:
> On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
> > On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman
> > wrote:
> > > Arnd Bergmann writes:
> > > > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
> > > > arch/mi
On Mon, Jan 14, 2019 at 12:36 PM Michael Ellerman wrote:
>
> Using the ABI field to encode whether a syscall is usable by SPU
> programs or not is a bit of kludge.
>
> The ABI of the syscall doesn't change depending on the SPU-ness, but
> in order to make the syscall generation work we have to pre
On Mon, Jan 14, 2019 at 12:36 PM Michael Ellerman wrote:
>
> We never pass a value for offset, nor do we need to, so remove the
> offset logic.
>
> Signed-off-by: Michael Ellerman
This change and the next three defeat the idea of having a shared script across
all architectures. Firoz has already
On Mon, Jan 14, 2019 at 12:36 PM Michael Ellerman wrote:
>
> Currently the macro that inserts entries into the SPU syscall table
> doesn't actually use the "nr" (syscall number) parameter.
>
> This does work, but it relies on the exact right number of syscall
> entries being emitted in order for t
On 15.01.19 16:38, Christoph Hellwig wrote:
> On Mon, Jan 14, 2019 at 01:58:54PM +0100, David Hildenbrand wrote:
>> Nothing major changed since the last version. I would be happy about
>> additional ACKs. If there are no further comments, can this go via the
>> mm-tree in one chunk?
>>
>> I was rec
On Mon, Jan 14, 2019 at 01:58:54PM +0100, David Hildenbrand wrote:
> Nothing major changed since the last version. I would be happy about
> additional ACKs. If there are no further comments, can this go via the
> mm-tree in one chunk?
>
> I was recently going over all users of PG_reserved. Short s
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
>
> On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman wrote:
> > Arnd Bergmann writes:
> > > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
> > > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++
> > > arch/powerpc/kerne
On Tue, Jan 15, 2019 at 02:56:34PM +0100, Christian Zigotzky wrote:
> On 15 January 2019 at 2:35PM, Christoph Hellwig wrote:
>> On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
>>> Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the
>>> generic direct mappin
On Tue, Jan 15, 2019 at 7:45 PM Alexey Kardashevskiy wrote:
>
>
>
> On 15/01/2019 18:19, Masahiro Yamada wrote:
> > Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
> > caused kernel panic on PowerPC if an external module is used with
> > CONFIG_STACKPROTECTOR because the 'prepare'
On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman wrote:
> Arnd Bergmann writes:
> > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
> > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++
> > arch/powerpc/kernel/syscalls/syscall.tbl | 12
>
> I have some changes
On Tue, Jan 15, 2019 at 7:35 PM Mathieu Malaterre wrote:
>
> On Tue, Jan 15, 2019 at 8:22 AM Masahiro Yamada
> wrote:
> >
> > Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
> > caused kernel panic on PowerPC if an external module is used with
> > CONFIG_STACKPROTECTOR because the
On Tue, Jan 15, 2019 at 12:52 PM Russell King - ARM Linux admin
wrote:
>
> On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> > Most architectures define system call numbers for the rseq and pkey system
> > calls, even when they don't support the features, and perhaps never will.
> >
On 01/14/2019 12:31 PM, Michal Hocko wrote:
> On Mon 14-01-19 09:30:55, Anshuman Khandual wrote:
>>
>>
>> On 01/13/2019 11:05 PM, Michal Hocko wrote:
>>> On Sat 12-01-19 15:56:38, Anshuman Khandual wrote:
All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
__GFP
On 15 January 2019 at 2:35PM, Christoph Hellwig wrote:
On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the
generic direct mapping bypass)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma
On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
> Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the
> generic direct mapping bypass)
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 21074ef03c0816ae158721a78cab
On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> Most architectures define system call numbers for the rseq and pkey system
> calls, even when they don't support the features, and perhaps never will.
>
> Only a few architectures are missing these, so just define them anyway
> for c
You can ignore this one.
On 1/14/19 3:24 PM, Aneesh Kumar K.V wrote:
---
mm/gup.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 6e8152594e83..91849c39931a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1226,7 +1226,7 @@ static long check_and_mig
Le 15/01/2019 à 11:22, Michael Ellerman a écrit :
Christophe Leroy writes:
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
...
- patches 7 to 11 fail to build with this error (really a warning, but
arch/powerpc doesn't allow warnings by default):
CC arch/powerpc/m
Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use
the generic direct mapping bypass)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 21074ef03c0816ae158721a78cabe9035938
I was able to compile the kernel for the AmigaOne X1000 (Nemo b
On 15/01/2019 18:19, Masahiro Yamada wrote:
> Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
> caused kernel panic on PowerPC if an external module is used with
> CONFIG_STACKPROTECTOR because the 'prepare' target was not executed
> for the external module build.
>
> Commit e07
On Tue, Jan 15, 2019 at 8:22 AM Masahiro Yamada
wrote:
>
> Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
> caused kernel panic on PowerPC if an external module is used with
> CONFIG_STACKPROTECTOR because the 'prepare' target was not executed
> for the external module build.
>
>
Hi Jason,
Thanks for the patch.
"Jason A. Donenfeld" writes:
> Commit 0e759bd75285 moved around the declaration of pnv_npu2_init, but
> did not conditionalize it inside of the PCI pSeries driver. This meant
> that CONFIG_PCI && CONFIG_PPC_PSERIES && !CONFIG_PPC_POWERNV resulted
> in:
>
> powerpc
Christophe Leroy writes:
> Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
...
>>
>> - patches 7 to 11 fail to build with this error (really a warning, but
>>arch/powerpc doesn't allow warnings by default):
>>
>>CC arch/powerpc/mm/ppc_mmu_32.o
>> ../arch/powerpc/mm/ppc
Next step: 63a6e350e037a21e9a88c8b710129bea7049a80f (powerpc/dma: use
the dma_direct mapping routines)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 63a6e350e037a21e9a88c8b710129bea7049a80f
Error message:
arch/powerpc/kernel/dma.o:(.data.rel.ro+0x0): und
On 15/1/19 6:26 pm, Mathieu Malaterre wrote:
[Sorry to hijack this thread. ]
On Tue, Jan 15, 2019 at 5:22 AM Andrew Donnellan
wrote:
kcov provides kernel coverage data that's useful for fuzzing tools like
syzkaller.
Wire up kcov support on powerpc. Disable kcov instrumentation on the same
fi
Next step: 240d7ecd7f6fa62e074e8a835e620047954f0b28 (powerpc/dma: use
the dma-direct allocator for coherent platforms)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 240d7ecd7f6fa62e074e8a835e620047954f0b28
Link to the Git:
http://git.infradead.org/users/
On Tue, 15 Jan 2019 at 08:20, Masahiro Yamada
wrote:
>
> Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
> caused kernel panic on PowerPC if an external module is used with
> CONFIG_STACKPROTECTOR because the 'prepare' target was not executed
> for the external module build.
>
> Co
On 15/1/19 5:40 pm, Dmitry Vyukov wrote:
On Tue, Jan 15, 2019 at 5:20 AM Andrew Donnellan
wrote:
kcov provides kernel coverage data that's useful for fuzzing tools like
syzkaller.
Wire up kcov support on powerpc. Disable kcov instrumentation on the same
files where we currently disable gcov a
54 matches
Mail list logo
