| Message ID | 20201101170454.9567-1-rppt@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | arch, mm: deprecate DISCONTIGMEM | expand |
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
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 - glaubitz@debian.org > `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
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
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 :)
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
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 - glaubitz@debian.org > `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
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
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 - glaubitz@debian.org > `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
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.
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 <rppt@linux.ibm.com> > 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 <glaubitz@physik.fu-berlin.de> > Fixes: bbb026da151c ("ia64: add support for TIF_NOTIFY_SIGNAL") > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> > --- > > 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_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)) { > + test_thread_flag(TIF_NOTIFY_SIGNAL)) { > local_irq_enable(); /* force interrupt enable */ > ia64_do_signal(scr, in_syscall); > } > This fixes the issue for me. Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Adrian
Hi Jens, On Tue, Dec 1, 2020 at 4:03 PM Jens Axboe <axboe@kernel.dk> 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 lkp@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 -- geert@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
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 <glaubitz@physik.fu-berlin.de> 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
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 <glaubitz@physik.fu-berlin.de> > > 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 - glaubitz@debian.org > `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
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 lkp@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.
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 lkp@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
On Wed, Dec 02, 2020 at 08:43:26AM +0000, 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 lkp@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/
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.
On Wed, Dec 02, 2020 at 10:46:28AM +0200, Mike Rapoport wrote: > On Wed, Dec 02, 2020 at 08:43:26AM +0000, 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 lkp@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.
From: Mike Rapoport <rppt@linux.ibm.com> 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-rppt@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