Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
On Wed, Dec 02, 2020 at 10:46:28AM +0200, Mike Rapoport wrote: > On Wed, Dec 02, 2020 at 08:43:26AM +, Christoph Hellwig wrote: > > On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote: > > > > That's a lot of typos in that patch... I wonder why the buildbot hasn't > > > > complained about this. Thanks for fixing this up! I'm going to fold this > > > > into the original to avoid the breakage. > > > > > > Does l...@intel.com do ia64 builds? Yes, it builds zx1_defconfig. > > > > I've never got results. Which is annoying, as debian doesn't ship an > > ia64 cross toolchain either, and I can't find any pre-built one that > > works for me. > > Arnd publishes a bunch of cross compilers here: > > https://mirrors.edge.kernel.org/pub/tools/crosstool/ This is my source for those architectures where debian doesn't ship cross compilers. I'm stuck with mostly gcc 7/8 so I'm glad to see there have been some major updates.
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
On Wed, Dec 02, 2020 at 09:45:24AM +0100, John Paul Adrian Glaubitz wrote: > > I've never got results. Which is annoying, as debian doesn't ship an > > ia64 cross toolchain either, and I can't find any pre-built one that > > works for me. > > The ia64 toolchain available from kernel.org works for me for cross-building > a kernel that boots on my RX2600. > > It's just not a fully-fledged toolchain due to the limitations with libunwind. Actually, you are right, I did manage to finally get that working a while ago. I think openrisc is the one where I failed to get anything to work at all now that I think of it.
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
On Wed, Dec 02, 2020 at 08:43:26AM +, Christoph Hellwig wrote: > On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote: > > > That's a lot of typos in that patch... I wonder why the buildbot hasn't > > > complained about this. Thanks for fixing this up! I'm going to fold this > > > into the original to avoid the breakage. > > > > Does l...@intel.com do ia64 builds? Yes, it builds zx1_defconfig. > > I've never got results. Which is annoying, as debian doesn't ship an > ia64 cross toolchain either, and I can't find any pre-built one that > works for me. Arnd publishes a bunch of cross compilers here: https://mirrors.edge.kernel.org/pub/tools/crosstool/ -- Sincerely yours, Mike.
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Christoph! On 12/2/20 9:43 AM, Christoph Hellwig wrote: > On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote: >>> That's a lot of typos in that patch... I wonder why the buildbot hasn't >>> complained about this. Thanks for fixing this up! I'm going to fold this >>> into the original to avoid the breakage. >> >> Does l...@intel.com do ia64 builds? Yes, it builds zx1_defconfig. > > I've never got results. Which is annoying, as debian doesn't ship an > ia64 cross toolchain either, and I can't find any pre-built one that > works for me. The ia64 toolchain available from kernel.org works for me for cross-building a kernel that boots on my RX2600. It's just not a fully-fledged toolchain due to the limitations with libunwind. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote: > > That's a lot of typos in that patch... I wonder why the buildbot hasn't > > complained about this. Thanks for fixing this up! I'm going to fold this > > into the original to avoid the breakage. > > Does l...@intel.com do ia64 builds? Yes, it builds zx1_defconfig. I've never got results. Which is annoying, as debian doesn't ship an ia64 cross toolchain either, and I can't find any pre-built one that works for me.
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Adrian, On Tue, Dec 01, 2020 at 08:55:37PM +0100, John Paul Adrian Glaubitz wrote: > Hi Mike! > > On 12/1/20 4:07 PM, John Paul Adrian Glaubitz wrote: > > This fixes the issue for me. > > > > Tested-by: John Paul Adrian Glaubitz > > I just booted the kernel from the linux-mm branch and I can't get the hpsa > driver > to work anymore. Even if I compile it into the kernel, the driver is no longer > loaded and hence I can't access the disks. > > Any idea what could be wrong? I know nearly nothing about SCSI, I can only suggest to enable all the debug options available and see if anything shows up :) > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > -- Sincerely yours, Mike.
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Mike! On 12/1/20 4:07 PM, John Paul Adrian Glaubitz wrote: > This fixes the issue for me. > > Tested-by: John Paul Adrian Glaubitz I just booted the kernel from the linux-mm branch and I can't get the hpsa driver to work anymore. Even if I compile it into the kernel, the driver is no longer loaded and hence I can't access the disks. Any idea what could be wrong? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Jens,
On Tue, Dec 1, 2020 at 4:03 PM Jens Axboe wrote:
> On 12/1/20 6:56 AM, Mike Rapoport wrote:
> > (added Jens)
> >
> > On Tue, Dec 01, 2020 at 01:16:05PM +0100, John Paul Adrian Glaubitz wrote:
> >> Hi Mike!
> >>
> >> On 12/1/20 1:10 PM, Mike Rapoport wrote:
> >>> On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Mike!
>
> On 12/1/20 11:29 AM, Mike Rapoport wrote:
> > These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/
> > with a mirror at https://github.com/hnaz/linux-mm)
> >
> > I beleive they will be coming in 5.11.
>
> Just pulled from that tree and gave it a try, it actually fails to build:
>
> LDS arch/ia64/kernel/vmlinux.lds
> AS arch/ia64/kernel/entry.o
> arch/ia64/kernel/entry.S: Assembler messages:
> arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a
> general register
> arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed
> by instruction
> arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a
> general register
> arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed
> by instruction
> GEN usr/initramfs_data.cpio
> make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o]
> Error 1
> make: *** [Makefile:1797: arch/ia64/kernel] Error 2
> make: *** Waiting for unfinished jobs
> CC init/do_mounts_initrd.o
> SHIPPED usr/initramfs_inc_data
> AS usr/initramfs_data.o
> >>>
> >>> Hmm, it was buidling fine with v5.10-rc2-mmotm-2020-11-07-21-40.
> >>> I'll try to see what could cause this.
> >>>
> >>> Do you build with defconfig or do you use a custom config?
> >>
> >> That's with "localmodconfig", see attached configuration file.
> >
> > Thanks.
> > It seems that the recent addition of TIF_NOTIFY_SIGNAL to ia64 in
> > linux-next caused the issue. Can you please try the below patch?
>
> That's a lot of typos in that patch... I wonder why the buildbot hasn't
> complained about this. Thanks for fixing this up! I'm going to fold this
> into the original to avoid the breakage.
Does l...@intel.com do ia64 builds? Yes, it builds zx1_defconfig.
Kisskb doesn't seem to build zx1_defconfig, but generic_defconfig.
http://kisskb.ellerman.id.au/kisskb/target/101883/ shows this has been broken
since Oct 30. Perhaps kisskb build failures are not emailed to the ia64
maintainers, or not acted upon?
(I do receive kisskb build failure emails for m68k)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
On 12/1/20 2:56 PM, Mike Rapoport wrote:
> (added Jens)
>
> On Tue, Dec 01, 2020 at 01:16:05PM +0100, John Paul Adrian Glaubitz wrote:
>> Hi Mike!
>>
>> On 12/1/20 1:10 PM, Mike Rapoport wrote:
>>> On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote:
Hi Mike!
On 12/1/20 11:29 AM, Mike Rapoport wrote:
> These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/
> with a mirror at https://github.com/hnaz/linux-mm)
>
> I beleive they will be coming in 5.11.
Just pulled from that tree and gave it a try, it actually fails to build:
LDS arch/ia64/kernel/vmlinux.lds
AS arch/ia64/kernel/entry.o
arch/ia64/kernel/entry.S: Assembler messages:
arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a
general register
arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by
instruction
arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a
general register
arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by
instruction
GEN usr/initramfs_data.cpio
make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1
make: *** [Makefile:1797: arch/ia64/kernel] Error 2
make: *** Waiting for unfinished jobs
CC init/do_mounts_initrd.o
SHIPPED usr/initramfs_inc_data
AS usr/initramfs_data.o
>>>
>>> Hmm, it was buidling fine with v5.10-rc2-mmotm-2020-11-07-21-40.
>>> I'll try to see what could cause this.
>>>
>>> Do you build with defconfig or do you use a custom config?
>>
>> That's with "localmodconfig", see attached configuration file.
>
> Thanks.
> It seems that the recent addition of TIF_NOTIFY_SIGNAL to ia64 in
> linux-next caused the issue. Can you please try the below patch?
>
> From c4d06cf1c2938e6b2302e7ed0be95c3401181ebb Mon Sep 17 00:00:00 2001
> From: Mike Rapoport
> Date: Tue, 1 Dec 2020 15:40:28 +0200
> Subject: [PATCH] ia64: fix TIF_NOTIFY_SIGNAL implementation
>
> * Replace wrong spelling of TIF_SIGNAL_NOTIFY with the correct
> TIF_NOTIFY_SIGNAL
> * Remove mistyped plural in test_thread_flag() call in
> process::do_notify_resume_user()
> * Use number 5 for TIF_NOTIFY_SIGNAL as 7 is too big and assembler is not
> happy:
>
> AS arch/ia64/kernel/entry.o
> arch/ia64/kernel/entry.S: Assembler messages:
> arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be an 8-bit
> integer (-128-127)
> arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by
> instruction
>
> Reported-by: John Paul Adrian Glaubitz
> Fixes: bbb026da151c ("ia64: add support for TIF_NOTIFY_SIGNAL")
> Signed-off-by: Mike Rapoport
> ---
>
> The Fixes tag is based on the commit in next-20201201, I'm not 100% sure
> it is stable
>
> arch/ia64/include/asm/thread_info.h | 4 ++--
> arch/ia64/kernel/process.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/ia64/include/asm/thread_info.h
> b/arch/ia64/include/asm/thread_info.h
> index 759d7d68a5f2..51d20cb37706 100644
> --- a/arch/ia64/include/asm/thread_info.h
> +++ b/arch/ia64/include/asm/thread_info.h
> @@ -103,8 +103,8 @@ struct thread_info {
> #define TIF_SYSCALL_TRACE2 /* syscall trace active */
> #define TIF_SYSCALL_AUDIT3 /* syscall auditing active */
> #define TIF_SINGLESTEP 4 /* restore singlestep on return
> to user mode */
> +#define TIF_NOTIFY_SIGNAL5 /* signal notification exist */
> #define TIF_NOTIFY_RESUME6 /* resumption notification requested */
> -#define TIF_NOTIFY_SIGNAL7 /* signal notification exist */
> #define TIF_MEMDIE 17 /* is terminating due to OOM killer */
> #define TIF_MCA_INIT 18 /* this task is processing MCA or INIT
> */
> #define TIF_DB_DISABLED 19 /* debug trap disabled for
> fsyscall */
> @@ -116,7 +116,7 @@ struct thread_info {
> #define _TIF_SINGLESTEP (1 << TIF_SINGLESTEP)
> #define _TIF_SYSCALL_TRACEAUDIT
> (_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SINGLESTEP)
> #define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
> -#define _TIF_SIGNAL_NOTIFY (1 << TIF_SIGNAL_NOTIFY)
> +#define _TIF_NOTIFY_SIGNAL (1 << TIF_NOTIFY_SIGNAL)
> #define _TIF_SIGPENDING (1 << TIF_SIGPENDING)
> #define _TIF_NEED_RESCHED(1 << TIF_NEED_RESCHED)
> #define _TIF_MCA_INIT(1 << TIF_MCA_INIT)
> diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
> index 468525fc64e0..ee394abcc03e 100644
> --- a/arch/ia64/kernel/process.c
> +++ b/arch/ia64/kernel/process.c
> @@ -172,7 +172,7 @@ do_notify_resume_user(sigset_t *unused, struct sigscratch
> *scr, long in_syscall)
>
> /* deal with pending signal delivery */
> if (test_thread_flag(TIF_SIGPENDING) ||
> - test_thread_flags(TIF_NOTIFY_SIGNAL)) {
> +
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
On 12/1/20 6:56 AM, Mike Rapoport wrote: > (added Jens) > > On Tue, Dec 01, 2020 at 01:16:05PM +0100, John Paul Adrian Glaubitz wrote: >> Hi Mike! >> >> On 12/1/20 1:10 PM, Mike Rapoport wrote: >>> On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote: Hi Mike! On 12/1/20 11:29 AM, Mike Rapoport wrote: > These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/ > with a mirror at https://github.com/hnaz/linux-mm) > > I beleive they will be coming in 5.11. Just pulled from that tree and gave it a try, it actually fails to build: LDS arch/ia64/kernel/vmlinux.lds AS arch/ia64/kernel/entry.o arch/ia64/kernel/entry.S: Assembler messages: arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a general register arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by instruction arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a general register arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by instruction GEN usr/initramfs_data.cpio make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1 make: *** [Makefile:1797: arch/ia64/kernel] Error 2 make: *** Waiting for unfinished jobs CC init/do_mounts_initrd.o SHIPPED usr/initramfs_inc_data AS usr/initramfs_data.o >>> >>> Hmm, it was buidling fine with v5.10-rc2-mmotm-2020-11-07-21-40. >>> I'll try to see what could cause this. >>> >>> Do you build with defconfig or do you use a custom config? >> >> That's with "localmodconfig", see attached configuration file. > > Thanks. > It seems that the recent addition of TIF_NOTIFY_SIGNAL to ia64 in > linux-next caused the issue. Can you please try the below patch? That's a lot of typos in that patch... I wonder why the buildbot hasn't complained about this. Thanks for fixing this up! I'm going to fold this into the original to avoid the breakage. -- Jens Axboe
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
(added Jens)
On Tue, Dec 01, 2020 at 01:16:05PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Mike!
>
> On 12/1/20 1:10 PM, Mike Rapoport wrote:
> > On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote:
> >> Hi Mike!
> >>
> >> On 12/1/20 11:29 AM, Mike Rapoport wrote:
> >>> These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/
> >>> with a mirror at https://github.com/hnaz/linux-mm)
> >>>
> >>> I beleive they will be coming in 5.11.
> >>
> >> Just pulled from that tree and gave it a try, it actually fails to build:
> >>
> >> LDS arch/ia64/kernel/vmlinux.lds
> >> AS arch/ia64/kernel/entry.o
> >> arch/ia64/kernel/entry.S: Assembler messages:
> >> arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a
> >> general register
> >> arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by
> >> instruction
> >> arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a
> >> general register
> >> arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by
> >> instruction
> >> GEN usr/initramfs_data.cpio
> >> make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1
> >> make: *** [Makefile:1797: arch/ia64/kernel] Error 2
> >> make: *** Waiting for unfinished jobs
> >> CC init/do_mounts_initrd.o
> >> SHIPPED usr/initramfs_inc_data
> >> AS usr/initramfs_data.o
> >
> > Hmm, it was buidling fine with v5.10-rc2-mmotm-2020-11-07-21-40.
> > I'll try to see what could cause this.
> >
> > Do you build with defconfig or do you use a custom config?
>
> That's with "localmodconfig", see attached configuration file.
Thanks.
It seems that the recent addition of TIF_NOTIFY_SIGNAL to ia64 in
linux-next caused the issue. Can you please try the below patch?
>From c4d06cf1c2938e6b2302e7ed0be95c3401181ebb Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Tue, 1 Dec 2020 15:40:28 +0200
Subject: [PATCH] ia64: fix TIF_NOTIFY_SIGNAL implementation
* Replace wrong spelling of TIF_SIGNAL_NOTIFY with the correct
TIF_NOTIFY_SIGNAL
* Remove mistyped plural in test_thread_flag() call in
process::do_notify_resume_user()
* Use number 5 for TIF_NOTIFY_SIGNAL as 7 is too big and assembler is not
happy:
AS arch/ia64/kernel/entry.o
arch/ia64/kernel/entry.S: Assembler messages:
arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be an 8-bit
integer (-128-127)
arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by
instruction
Reported-by: John Paul Adrian Glaubitz
Fixes: bbb026da151c ("ia64: add support for TIF_NOTIFY_SIGNAL")
Signed-off-by: Mike Rapoport
---
The Fixes tag is based on the commit in next-20201201, I'm not 100% sure
it is stable
arch/ia64/include/asm/thread_info.h | 4 ++--
arch/ia64/kernel/process.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/ia64/include/asm/thread_info.h
b/arch/ia64/include/asm/thread_info.h
index 759d7d68a5f2..51d20cb37706 100644
--- a/arch/ia64/include/asm/thread_info.h
+++ b/arch/ia64/include/asm/thread_info.h
@@ -103,8 +103,8 @@ struct thread_info {
#define TIF_SYSCALL_TRACE 2 /* syscall trace active */
#define TIF_SYSCALL_AUDIT 3 /* syscall auditing active */
#define TIF_SINGLESTEP 4 /* restore singlestep on return to user
mode */
+#define TIF_NOTIFY_SIGNAL 5 /* signal notification exist */
#define TIF_NOTIFY_RESUME 6 /* resumption notification requested */
-#define TIF_NOTIFY_SIGNAL 7 /* signal notification exist */
#define TIF_MEMDIE 17 /* is terminating due to OOM killer */
#define TIF_MCA_INIT 18 /* this task is processing MCA or INIT
*/
#define TIF_DB_DISABLED19 /* debug trap disabled for
fsyscall */
@@ -116,7 +116,7 @@ struct thread_info {
#define _TIF_SINGLESTEP(1 << TIF_SINGLESTEP)
#define _TIF_SYSCALL_TRACEAUDIT
(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SINGLESTEP)
#define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
-#define _TIF_SIGNAL_NOTIFY (1 << TIF_SIGNAL_NOTIFY)
+#define _TIF_NOTIFY_SIGNAL (1 << TIF_NOTIFY_SIGNAL)
#define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
#define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED)
#define _TIF_MCA_INIT (1 << TIF_MCA_INIT)
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index 468525fc64e0..ee394abcc03e 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -172,7 +172,7 @@ do_notify_resume_user(sigset_t *unused, struct sigscratch
*scr, long in_syscall)
/* deal with pending signal delivery */
if (test_thread_flag(TIF_SIGPENDING) ||
- test_thread_flags(TIF_NOTIFY_SIGNAL)) {
+ test_thread_flag(TIF_NOTIFY_SIGNAL)) {
local_irq_enable(); /* force interrupt enable */
ia64_do_signal(scr, in_syscall);
}
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Mike! On 12/1/20 1:10 PM, Mike Rapoport wrote: > On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote: >> Hi Mike! >> >> On 12/1/20 11:29 AM, Mike Rapoport wrote: >>> These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/ >>> with a mirror at https://github.com/hnaz/linux-mm) >>> >>> I beleive they will be coming in 5.11. >> >> Just pulled from that tree and gave it a try, it actually fails to build: >> >> LDS arch/ia64/kernel/vmlinux.lds >> AS arch/ia64/kernel/entry.o >> arch/ia64/kernel/entry.S: Assembler messages: >> arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a general >> register >> arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by >> instruction >> arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a general >> register >> arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by >> instruction >> GEN usr/initramfs_data.cpio >> make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1 >> make: *** [Makefile:1797: arch/ia64/kernel] Error 2 >> make: *** Waiting for unfinished jobs >> CC init/do_mounts_initrd.o >> SHIPPED usr/initramfs_inc_data >> AS usr/initramfs_data.o > > Hmm, it was buidling fine with v5.10-rc2-mmotm-2020-11-07-21-40. > I'll try to see what could cause this. > > Do you build with defconfig or do you use a custom config? That's with "localmodconfig", see attached configuration file. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 # # Automatically generated file; DO NOT EDIT. # Linux/ia64 5.10.0-rc5-mm1 Kernel Configuration # CONFIG_CC_VERSION_TEXT="gcc (Debian 10.2.0-19) 10.2.0" CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=100200 CONFIG_LD_VERSION=23501 CONFIG_CLANG_VERSION=0 CONFIG_CC_CAN_LINK=y CONFIG_CC_CAN_LINK_STATIC=y CONFIG_CC_HAS_ASM_GOTO=y CONFIG_CC_HAS_ASM_INLINE=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_BUILD_SALT="4.19.0-5-mckinley" CONFIG_DEFAULT_INIT="" CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_WATCH_QUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_LEGACY=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set # end of IRQ subsystem CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_LEGACY_TIMER_TICK=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # CONFIG_PSI is not set # end of CPU/Task time and stats accounting CONFIG_CPU_ISOLATION=y # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_TASKS_RCU_GENERIC=y CONFIG_TASKS_TRACE_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y # end of RCU Subsystem CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m # CONFIG_IKCONFIG_PROC is not set # CONFIG_IKHEADERS is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # # Scheduler features # # CONFIG_UCLAMP_TASK is not set # end of Scheduler features CONFIG_CC_HAS_INT128=y CONFIG_CGROUPS=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_KMEM=y CONFIG_BLK_CGROUP=y CONFIG_CGROUP_WRITEBACK=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_CGROUP_PIDS=y CONFIG_CGROUP_RDMA=y CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_HUGETLB is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_BPF=y # CONFIG_CGROUP_DEBUG is not set CONFIG_SOCK_CGROUP_DATA=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_CHECKPOINT_RESTORE=y CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y CONFIG_RD_ZSTD=y # CONFIG_BOOT_CONFIG is not set CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y #
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote: > Hi Mike! > > On 12/1/20 11:29 AM, Mike Rapoport wrote: > > These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/ > > with a mirror at https://github.com/hnaz/linux-mm) > > > > I beleive they will be coming in 5.11. > > Just pulled from that tree and gave it a try, it actually fails to build: > > LDS arch/ia64/kernel/vmlinux.lds > AS arch/ia64/kernel/entry.o > arch/ia64/kernel/entry.S: Assembler messages: > arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a general > register > arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by > instruction > arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a general > register > arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by > instruction > GEN usr/initramfs_data.cpio > make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1 > make: *** [Makefile:1797: arch/ia64/kernel] Error 2 > make: *** Waiting for unfinished jobs > CC init/do_mounts_initrd.o > SHIPPED usr/initramfs_inc_data > AS usr/initramfs_data.o Hmm, it was buidling fine with v5.10-rc2-mmotm-2020-11-07-21-40. I'll try to see what could cause this. Do you build with defconfig or do you use a custom config? > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > -- Sincerely yours, Mike.
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Mike! On 12/1/20 11:29 AM, Mike Rapoport wrote: > These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/ > with a mirror at https://github.com/hnaz/linux-mm) > > I beleive they will be coming in 5.11. Just pulled from that tree and gave it a try, it actually fails to build: LDS arch/ia64/kernel/vmlinux.lds AS arch/ia64/kernel/entry.o arch/ia64/kernel/entry.S: Assembler messages: arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a general register arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by instruction arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a general register arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by instruction GEN usr/initramfs_data.cpio make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1 make: *** [Makefile:1797: arch/ia64/kernel] Error 2 make: *** Waiting for unfinished jobs CC init/do_mounts_initrd.o SHIPPED usr/initramfs_inc_data AS usr/initramfs_data.o Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Adrian, On Tue, Dec 01, 2020 at 10:10:56AM +0100, John Paul Adrian Glaubitz wrote: > Hi Mike! > > On 11/17/20 7:23 AM, Mike Rapoport wrote: > >> Apologies for the late reply. Is this still relevant for testing? > >> > >> I have already successfully tested v1 of the patch set, shall I test v2? > > > > There were minor differences only for m68k between the versions. I've > > verified them on ARAnyM but if you have a real machine a run there would > > be nice. > > I have just built a fresh kernel from the tip of Linus' tree and it boots > fine on my RX-2600: > > root@glendronach:~# uname -a > Linux glendronach 5.10.0-rc6 #6 SMP Tue Dec 1 04:52:49 CET 2020 ia64 GNU/Linux > root@glendronach:~# > > No issues observed so far. Looking at the git log, it seems these changes > haven't > been merged for 5.10 yet. I assume they will be coming with 5.11? These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/ with a mirror at https://github.com/hnaz/linux-mm) I beleive they will be coming in 5.11. > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > -- Sincerely yours, Mike.
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Mike! On 11/17/20 7:23 AM, Mike Rapoport wrote: >> Apologies for the late reply. Is this still relevant for testing? >> >> I have already successfully tested v1 of the patch set, shall I test v2? > > There were minor differences only for m68k between the versions. I've > verified them on ARAnyM but if you have a real machine a run there would > be nice. I have just built a fresh kernel from the tip of Linus' tree and it boots fine on my RX-2600: root@glendronach:~# uname -a Linux glendronach 5.10.0-rc6 #6 SMP Tue Dec 1 04:52:49 CET 2020 ia64 GNU/Linux root@glendronach:~# No issues observed so far. Looking at the git log, it seems these changes haven't been merged for 5.10 yet. I assume they will be coming with 5.11? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Adrian, On Tue, Nov 17, 2020 at 09:07:25AM +0100, John Paul Adrian Glaubitz wrote: > Hi Mike! > > On 11/17/20 7:23 AM, Mike Rapoport wrote: > > There were minor differences only for m68k between the versions. I've > > verified them on ARAnyM but if you have a real machine a run there would > > be nice. > > I do have a real machine (Amiga 68060) but it's currently not set up (but it > will be in the near future). So I'm not sure if I can test the change within > a short time frame. > > I will certainly report back when I run into issues on real hardware. I hope there won't be any :) -- Sincerely yours, Mike.
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Mike! On 11/17/20 7:23 AM, Mike Rapoport wrote: > There were minor differences only for m68k between the versions. I've > verified them on ARAnyM but if you have a real machine a run there would > be nice. I do have a real machine (Amiga 68060) but it's currently not set up (but it will be in the near future). So I'm not sure if I can test the change within a short time frame. I will certainly report back when I run into issues on real hardware. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Adrian, On Tue, Nov 17, 2020 at 06:24:51AM +0100, John Paul Adrian Glaubitz wrote: > Hi! > > On 11/1/20 6:04 PM, Mike Rapoport wrote: > > It's been a while since DISCONTIGMEM is generally considered deprecated, > > but it is still used by four architectures. This set replaces DISCONTIGMEM > > with a different way to handle holes in the memory map and marks > > DISCONTIGMEM configuration as BROKEN in Kconfigs of these architectures with > > the intention to completely remove it in several releases. > > > > While for 64-bit alpha and ia64 the switch to SPARSEMEM is quite obvious > > and was a matter of moving some bits around, for smaller 32-bit arc and > > m68k SPARSEMEM is not necessarily the best thing to do. > > > > On 32-bit machines SPARSEMEM would require large sections to make section > > index fit in the page flags, but larger sections mean that more memory is > > wasted for unused memory map. > > > > Besides, pfn_to_page() and page_to_pfn() become less efficient, at least on > > arc. > > > > So I've decided to generalize arm's approach for freeing of unused parts of > > the memory map with FLATMEM and enable it for both arc and m68k. The > > details are in the description of patches 10 (arc) and 13 (m68k). > > Apologies for the late reply. Is this still relevant for testing? > > I have already successfully tested v1 of the patch set, shall I test v2? There were minor differences only for m68k between the versions. I've verified them on ARAnyM but if you have a real machine a run there would be nice. > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > -- Sincerely yours, Mike.
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi! On 11/1/20 6:04 PM, Mike Rapoport wrote: > It's been a while since DISCONTIGMEM is generally considered deprecated, > but it is still used by four architectures. This set replaces DISCONTIGMEM > with a different way to handle holes in the memory map and marks > DISCONTIGMEM configuration as BROKEN in Kconfigs of these architectures with > the intention to completely remove it in several releases. > > While for 64-bit alpha and ia64 the switch to SPARSEMEM is quite obvious > and was a matter of moving some bits around, for smaller 32-bit arc and > m68k SPARSEMEM is not necessarily the best thing to do. > > On 32-bit machines SPARSEMEM would require large sections to make section > index fit in the page flags, but larger sections mean that more memory is > wasted for unused memory map. > > Besides, pfn_to_page() and page_to_pfn() become less efficient, at least on > arc. > > So I've decided to generalize arm's approach for freeing of unused parts of > the memory map with FLATMEM and enable it for both arc and m68k. The > details are in the description of patches 10 (arc) and 13 (m68k). Apologies for the late reply. Is this still relevant for testing? I have already successfully tested v1 of the patch set, shall I test v2? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
From: Mike Rapoport Hi, It's been a while since DISCONTIGMEM is generally considered deprecated, but it is still used by four architectures. This set replaces DISCONTIGMEM with a different way to handle holes in the memory map and marks DISCONTIGMEM configuration as BROKEN in Kconfigs of these architectures with the intention to completely remove it in several releases. While for 64-bit alpha and ia64 the switch to SPARSEMEM is quite obvious and was a matter of moving some bits around, for smaller 32-bit arc and m68k SPARSEMEM is not necessarily the best thing to do. On 32-bit machines SPARSEMEM would require large sections to make section index fit in the page flags, but larger sections mean that more memory is wasted for unused memory map. Besides, pfn_to_page() and page_to_pfn() become less efficient, at least on arc. So I've decided to generalize arm's approach for freeing of unused parts of the memory map with FLATMEM and enable it for both arc and m68k. The details are in the description of patches 10 (arc) and 13 (m68k). v2 changes: - remove additional stale '#ifdef CONFIG_SINGLE_MEMORY_CHUNK' on m68k - fix bisectability on m68k v1: https://lore.kernel.org/lkml/20201027112955.14157-1-r...@kernel.org Mike Rapoport (13): alpha: switch from DISCONTIGMEM to SPARSEMEM ia64: remove custom __early_pfn_to_nid() ia64: remove 'ifdef CONFIG_ZONE_DMA32' statements ia64: discontig: paging_init(): remove local max_pfn calculation ia64: split virtual map initialization out of paging_init() ia64: forbid using VIRTUAL_MEM_MAP with FLATMEM ia64: make SPARSEMEM default and disable DISCONTIGMEM arm: remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL arm, arm64: move free_unused_memmap() to generic mm arc: use FLATMEM with freeing of unused memory map instead of DISCONTIGMEM m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM m68k/mm: enable use of generic memory_model.h for !DISCONTIGMEM m68k: deprecate DISCONTIGMEM Documentation/vm/memory-model.rst | 3 +- arch/Kconfig| 3 ++ arch/alpha/Kconfig | 8 +++ arch/alpha/include/asm/mmzone.h | 14 + arch/alpha/include/asm/page.h | 7 +-- arch/alpha/include/asm/pgtable.h| 12 ++--- arch/alpha/include/asm/sparsemem.h | 18 +++ arch/alpha/kernel/setup.c | 1 + arch/arc/Kconfig| 3 +- arch/arc/include/asm/page.h | 20 ++-- arch/arc/mm/init.c | 29 --- arch/arm/Kconfig| 10 +--- arch/arm/mach-bcm/Kconfig | 1 - arch/arm/mach-davinci/Kconfig | 1 - arch/arm/mach-exynos/Kconfig| 1 - arch/arm/mach-highbank/Kconfig | 1 - arch/arm/mach-omap2/Kconfig | 1 - arch/arm/mach-s5pv210/Kconfig | 1 - arch/arm/mach-tango/Kconfig | 1 - arch/arm/mm/init.c | 78 arch/arm64/Kconfig | 4 +- arch/arm64/mm/init.c| 68 arch/ia64/Kconfig | 11 ++-- arch/ia64/include/asm/meminit.h | 2 - arch/ia64/mm/contig.c | 58 ++--- arch/ia64/mm/discontig.c| 44 arch/ia64/mm/init.c | 14 - arch/ia64/mm/numa.c | 30 --- arch/m68k/Kconfig.cpu | 31 +-- arch/m68k/include/asm/page.h| 2 + arch/m68k/include/asm/page_mm.h | 7 ++- arch/m68k/include/asm/virtconvert.h | 5 -- arch/m68k/mm/init.c | 8 +-- fs/proc/kcore.c | 2 - include/linux/mm.h | 3 -- include/linux/mmzone.h | 42 --- mm/memblock.c | 80 + mm/mmzone.c | 14 - mm/page_alloc.c | 16 -- mm/vmstat.c | 4 -- 40 files changed, 270 insertions(+), 388 deletions(-) create mode 100644 arch/alpha/include/asm/sparsemem.h base-commit: 3650b228f83adda7e5ee532e2b90429c03f7b9ec -- 2.28.0
