Re: m68k-v4.19 crashes in free_all_bootmem
Hello Andreas,
On Fri, Nov 30, 2018 at 10:12:47PM +0100, Andreas Schwab wrote:
> On Nov 30 2018, Andreas Schwab wrote:
>
> > [0.00] Linux version 4.19.0 (andr...@igel.home) (gcc version 8.1.1
> > 20180712 (GCC)) #3 Fri Nov 30 20:53:33 CET 2018
> > [0.00] Saving 190 bytes of bootinfo
> > [0.00] console [debug0] enabled
> > [0.00] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM
> > CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
> > [0.00] Ignoring memory chunk at 0x0:0xe0 before the first chunk
> > [0.00] Fix your bootloader or use a memfile to make use of this
> > area!
> > [0.00] On node 0 totalpages: 786432
> > [0.00] DMA zone: 7680 pages used for memmap
> > [0.00] DMA zone: 0 pages reserved
> > [0.00] DMA zone: 786432 pages, LIFO batch:63
> > [0.00] NatFeats found (ARAnyM, 1.0)
> > [0.00] initrd: bf767a60 - c000
> > [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> > [0.00] pcpu-alloc: [0] 0
> > [0.00] Built 1 zonelists, mobility grouping on. Total pages: 778752
> > [0.00] Kernel command line: root=/dev/nfhd0p1 video=atafb:vga256
> > debug debug=par console=nfcon init=/bin/sh BOOT_IMAGE=vmlinux
> > [0.00] Dentry cache hash table entries: 524288 (order: 9, 2097152
> > bytes)
> > [0.00] Inode-cache hash table entries: 262144 (order: 8, 1048576
> > bytes)
> > [0.00] Sorting __ex_table...
> > [0.00] Unable to handle kernel NULL pointer dereference at virtual
> > address (ptrval)
> > [0.00] Oops:
> > [0.00] Modules linked in:
> > [0.00] PC: [<0069dbac>] free_all_bootmem+0x12c/0x186
> > [0.00] SR: 2714 SP: (ptrval) a2: 005e3314
> > [0.00] d0: d1: 000ad2: 0e00d3:
> > [0.00] d4: 005e1fc0d5: 001aa0: 0100a1:
> > [0.00] Process swapper (pid: 0, task=(ptrval))
> > [0.00] Frame format=7 eff addr=0736 ssw=0505 faddr=0736
> > [0.00] wb 1 stat/addr/data:
> > [0.00] wb 2 stat/addr/data:
> > [0.00] wb 3 stat/addr/data: 0736
> > [0.00] push data:
> > [0.00] Stack from 005e1f84:
> > [0.00] 000a 027d3260 006b5006
> >
> > [0.00] 0004f062 0003a220 0069e272 005e1ff8 054c
> > 00e0
> > [0.00] 0001 00693cd8 027d3260 0004f062 0003a220
> > 00691be6
> > [0.00] 006b5006
> > 00690872
> > [0.00] Call Trace: [<0004f062>] printk+0x0/0x18
> > [0.00] [<0003a220>] parse_args+0x0/0x2d4
> > [0.00] [<0069e272>] memblock_virt_alloc_try_nid+0x0/0xa4
> > [0.00] [<00693cd8>] mem_init+0xa/0x5c
> > [0.00] [<0004f062>] printk+0x0/0x18
> > [0.00] [<0003a220>] parse_args+0x0/0x2d4
> > [0.00] [<00691be6>] start_kernel+0x1ca/0x462
> > [0.00] [<00690872>] _sinittext+0x872/0x11f8
> > [0.00] Code: 7a1a eaae 2270 6db0 0061 ef14 2f01 2f03 <96a9> 0736
> > 2203 e589 d681 e78b d6a9 0732 2f03 2f40 0034 4eb9 0069 b8d0 260e 4fef
> > [0.00] Disabling lock debugging due to kernel taint
> > [0.00] Kernel panic - not syncing: Attempted to kill the idle task!
> > [0.00] Rebooting in 90 seconds..
>
> 1008a11590b966b469e60dc3756c9226a685ce12 is the first bad commit
> commit 1008a11590b966b469e60dc3756c9226a685ce12
> Author: Mike Rapoport
> Date: Wed Jul 4 09:28:16 2018 +0300
>
> m68k: switch to MEMBLOCK + NO_BOOTMEM
>
> In m68k the physical memory is described by [memory_start, memory_end] for
> !MMU variant and by m68k_memory array of memory ranges for the MMU
> version.
> This information is directly use to register the physical memory with
> memblock.
>
> The reserve_bootmem() calls are replaced with memblock_reserve() and the
> bootmap bitmap allocation is simply dropped.
>
> Since the MMU variant creates early mappings only for the small part of
> the
> memory we force bottom-up allocations in memblock.
>
> Signed-off-by: Mike Rapoport
> Acked-by: Greg Ungerer
> Signed-off-by: Geert Uytterhoeven
>
> :04 04 ab557d708e6989fc12b64f431fc2d3bdaf827c58
> 5ac7a44f882b1a3ca22a2008e5012d03382e4e24 M arch
>
> Andreas.
Can you please check what memblock debug will print with the following
pacth:
diff --git a/mm/memblock.c b/mm/memblock.c
index c63742b..48b2a3a 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -119,7 +119,7 @@ struct memblock memblock __initdata_memblock = {
.current_limit = MEMBLOCK_ALLOC_ANYWHERE,
};
-int memblock_debug __initdata_memblock;
+int
Re: m68k-v4.19 crashes in free_all_bootmem
On Fri, Nov 30, 2018 at 10:24 PM Michael Schmitz wrote:
> Am 01.12.2018 um 10:12 schrieb Andreas Schwab:
> > On Nov 30 2018, Andreas Schwab wrote:
> >
> >> [0.00] Linux version 4.19.0 (andr...@igel.home) (gcc version 8.1.1
> >> 20180712 (GCC)) #3 Fri Nov 30 20:53:33 CET 2018
> >> [0.00] Saving 190 bytes of bootinfo
> >> [0.00] console [debug0] enabled
> >> [0.00] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM
> >> CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
> >> [0.00] Ignoring memory chunk at 0x0:0xe0 before the first chunk
> The difference appears to be this:
>
> > [0.00] Linux version 4.19.0-rc1-atari-fpuemu-clocksource4+
> > (schmitz@xplor) (gcc version 4.6.3 (GCC)) #925 Wed Nov 21 12:51:19 NZDT 2018
> > [0.00] Saving 202 bytes of bootinfo
> > [0.00] console [debug0] enabled
> > [0.00] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM
> > CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
> > [0.00] On node 0 totalpages: 3584
> > [0.00] DMA zone: 35 pages used for memmap
> > [0.00] DMA zone: 0 pages reserved
> > [0.00] DMA zone: 3584 pages, LIFO batch:0
> > [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> > [0.00] pcpu-alloc: [0] 0
> > [0.00] Built 1 zonelists, mobility grouping off. Total pages: 3549
>
> Only a single memory chunk (ST-RAM), and kernel loaded there.
Same here.
The only memory-related option I have in my ARAnyM config is
FastRAM = 256
and that works.
Andreas: can you please share your ARAnyM config, so we can reproduce?
Thanks!
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: m68k-v4.19 crashes in free_all_bootmem
On Sat, Dec 01, 2018 at 11:51:52AM +1300, Michael Schmitz wrote:
> Andreas,
>
> Am 01.12.2018 um 11:23 schrieb Andreas Schwab:
> >On Dez 01 2018, Michael Schmitz wrote:
> >
> >>Must be a new kind of monster kernel that wouldn't fit inside 14 MB.
> >
> >There's way more than the kernel that must fit in 14 MB.
>
> I realize that. I only said to try and load the kernel to ST-RAM, not to
> switch off FastRAM entirely. Anything beyond a very minimal (or old) user
> space won't fit in 14 MB anymore, running out of VM even before swapon can
> run.
>
> The 'skipping memory chunk 0:e0 before the first chunk' to me means the
> bootstrap has reordered memory chunks so FastRAM comes before ST-RAM. It
> only does that when the kernel was loaded to FastRAM. Shortcomings of the
> old memory model caused the mis-ordered ST-RAM chunk then not to be mapped
> in kernel VM space at all. We still need ST-RAM for video framebuffer and
> DMA-able memory on Falcon, so I provided a dedicated ST-RAM allocator
> (similar to what Geert did for Zorro2-RAM) that will map a pool of ST-RAM
> and use that to satisfy the needs of atafb, atari_scsi and the like.
>
> I had looked over Mike's patches to check that handling of such reserved
> memory hasn't changed, but I have evidently missed something. Since kernels
> with 'normal' ram chunk ordering work fine, the alternate ordering code path
> is my prime suspect.
If I understand correctly, there are two types of RAM on Atari/ARAnyM:
ST-RAM and FastRAM. The ST-RAM resides at the physical range 0x0 - 0xe0 and
FastRAM takes a range somewhere above.
When the kernel is loaded into the FastRAM, bootloader sets the first entry
in the memory info to the FastRAM and the second one to ST-RAM and thus
m68k_memory becomes something like:
[0] = {
, ,
},
[1] = {
0x0, 0xe0,
}
In the paging_init() the ST-RAM chunk is essentially removed from the
m68k_memory, but it still can be used via the dedicated ST-RAM allocator.
Yet, my patch surely didn't take such reordering into account, and, more
importantly, I didn't take care of the removal of an entry from
m68k_memory. As the result, memblock sees ST-RAM as available and will
allocated memory from there, but this memory is not yet mapped.
I don't know what were the shortcomings of the old memory model, and why
ST-RAM and FastRAM are treated differently, so probably the simplest way
would be just inform memblock that the ST-RAM is not available to it:
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index 7497cf3..0bda2c4 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -233,6 +233,7 @@ void __init paging_init(void)
printk("Ignoring memory chunk at 0x%lx:0x%lx before the
first chunk\n",
m68k_memory[i].addr, m68k_memory[i].size);
printk("Fix your bootloader or use a memfile to make
use of this area!\n");
+ memblock_remove(m68k_memory[i].addr,
m68k_memory[i].size);
m68k_num_memory--;
memmove(m68k_memory + i, m68k_memory + i + 1,
(m68k_num_memory - i) * sizeof(struct
m68k_mem_info));
> I've tried to reproduce the bug by attempting to get the kernel loaded to
> FastRAM. Doesn't work for me - with or without -s option I get the same
> ordering of memory chunks (ST-RAM first) so the kernel clearly still runs in
> ST-RAM.
>
> Hence my question - how did you get the kernel loaded to FastRAM? What
> version of ARAnyM do you use? What's the size of your kernel (uncompressed)?
>
> Cheers,
>
> Michael
>
--
Sincerely yours,
Mike.
Re: m68k-v4.19 crashes in free_all_bootmem
Geert, On 3/12/18 11:57 AM, Michael Schmitz wrote: Only a single memory chunk (ST-RAM), and kernel loaded there. Same here. The only memory-related option I have in my ARAnyM config is FastRAM = 256 and that works. Andreas: can you please share your ARAnyM config, so we can reproduce? Thanks! For the record: LoadToFastRAM = yes in the [LILO] section does reproduce the bug for me. I've now found another option in one of my ARAnyM config files: SkipSTRAM = true I was certain I had used that trick before when working on getting the kernel to boot from FastRAM Oddly enough, that option does not appear to be honoured by ARAnyM 0.95. Neither is LoadToFastRAM (which works with 1.0.2). Cheers, Michael
Re: m68k-v4.19 crashes in free_all_bootmem
Geert, On 2/12/18 10:57 PM, Geert Uytterhoeven wrote: On Fri, Nov 30, 2018 at 10:24 PM Michael Schmitz wrote: Am 01.12.2018 um 10:12 schrieb Andreas Schwab: On Nov 30 2018, Andreas Schwab wrote: [0.00] Linux version 4.19.0 (andr...@igel.home) (gcc version 8.1.1 20180712 (GCC)) #3 Fri Nov 30 20:53:33 CET 2018 [0.00] Saving 190 bytes of bootinfo [0.00] console [debug0] enabled [0.00] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED [0.00] Ignoring memory chunk at 0x0:0xe0 before the first chunk The difference appears to be this: [0.00] Linux version 4.19.0-rc1-atari-fpuemu-clocksource4+ (schmitz@xplor) (gcc version 4.6.3 (GCC)) #925 Wed Nov 21 12:51:19 NZDT 2018 [0.00] Saving 202 bytes of bootinfo [0.00] console [debug0] enabled [0.00] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED [0.00] On node 0 totalpages: 3584 [0.00] DMA zone: 35 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3584 pages, LIFO batch:0 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists, mobility grouping off. Total pages: 3549 Only a single memory chunk (ST-RAM), and kernel loaded there. Same here. The only memory-related option I have in my ARAnyM config is FastRAM = 256 and that works. Andreas: can you please share your ARAnyM config, so we can reproduce? Thanks! For the record: LoadToFastRAM = yes in the [LILO] section does reproduce the bug for me. Disassembly of free_all_bootmem() (the nobootmem.c variety reveals the null pointer access: 00409780 : 409780: 4fef ffec lea %sp@(-20),%sp 409784: 48e7 3f1e moveml %d2-%d7/%a3-%fp,%sp@- 409788: 4eb9 0040 9738 jsr 409738 40978e: 4878 pea 409792: 42a7 clrl %sp@- 409794: 4eb9 0041 a270 jsr 41a270 40979a: 42af 0034 clrl %sp@(52) 40979e: 42af 0038 clrl %sp@(56) 4097a2: 7640 moveq #64,%d3 4097a4: d68f addl %sp,%d3 4097a6: 2f03 movel %d3,%sp@- 4097a8: 7440 moveq #64,%d2 4097aa: d48f addl %sp,%d2 4097ac: 2f02 movel %d2,%sp@- 4097ae: 49ef 003c lea %sp@(60),%a4 4097b2: 2f0c movel %a4,%sp@- 4097b4: 47f9 0041 9716 lea 419716 <__next_reserved_mem_region>,%a3 4097ba: 4e93 jsr %a3@ 4097bc: 4fef 0014 lea %sp@(20),%sp 4097c0: 4bf9 0041 912c lea 41912c ,%a5 4097c6: 6016 bras 4097de 4097c8: 2f2f 0038 movel %sp@(56),%sp@- 4097cc: 2f2f 0038 movel %sp@(56),%sp@- 4097d0: 4e95 jsr %a5@ 4097d2: 2f03 movel %d3,%sp@- 4097d4: 2f02 movel %d2,%sp@- 4097d6: 2f0c movel %a4,%sp@- 4097d8: 4e93 jsr %a3@ 4097da: 4fef 0014 lea %sp@(20),%sp 4097de: 202f 002c movel %sp@(44),%d0 4097e2: 222f 0030 movel %sp@(48),%d1 4097e6: 78ff moveq #-1,%d4 4097e8: 7aff moveq #-1,%d5 4097ea: 9285 subl %d5,%d1 4097ec: 9184 subxl %d4,%d0 4097ee: 66d8 bnes 4097c8 4097f0: 42af 002c clrl %sp@(44) 4097f4: 42af 0030 clrl %sp@(48) 4097f8: 42a7 clrl %sp@- 4097fa: 763c moveq #60,%d3 4097fc: d68f addl %sp,%d3 4097fe: 2f03 movel %d3,%sp@- 409800: 743c moveq #60,%d2 409802: 4877 2800 pea %sp@(,%d2:l) 409806: 4879 0042 0d56 pea 420d56 40980c: 4879 0042 0d42 pea 420d42 409812: 42a7 clrl %sp@- 409814: 4878 pea 409818: 47ef 0048 lea %sp@(72),%a3 40981c: 2f0b movel %a3,%sp@- 40981e: 4eb9 0041 9788 jsr 419788 <__next_mem_range> 409824: 4fef 0020 lea %sp@(32),%sp 409828: 4286 clrl %d6 40982a: 7a00 moveq #0,%d5 40982c: 2a45 moveal %d5,%a5 40982e: 49f9 0040 7754 lea 407754 <__free_pages_bootmem>,%a4 409834: 2c43 moveal %d3,%fp 409836: 6000 00bc braw 4098f4 40983a: 282f 0034 movel %sp@(52),%d4 40983e: 0684 0fff addil #4095,%d4 409844: 700c moveq #12,%d0 409846: e0ac lsrl %d0,%d4 409848: 242f 0038 movel %sp@(56),%d2 40984c: 2039 003e c020 movel 3ec020 ,%d0 409852: 720c moveq #12,%d1 409854: e2aa lsrl
Re: m68k-v4.19 crashes in free_all_bootmem
On 3/12/18 12:04 AM, Mike Rapoport wrote:
On Sat, Dec 01, 2018 at 11:51:52AM +1300, Michael Schmitz wrote:
Andreas,
Am 01.12.2018 um 11:23 schrieb Andreas Schwab:
On Dez 01 2018, Michael Schmitz wrote:
Must be a new kind of monster kernel that wouldn't fit inside 14 MB.
There's way more than the kernel that must fit in 14 MB.
I realize that. I only said to try and load the kernel to ST-RAM, not to
switch off FastRAM entirely. Anything beyond a very minimal (or old) user
space won't fit in 14 MB anymore, running out of VM even before swapon can
run.
The 'skipping memory chunk 0:e0 before the first chunk' to me means the
bootstrap has reordered memory chunks so FastRAM comes before ST-RAM. It
only does that when the kernel was loaded to FastRAM. Shortcomings of the
old memory model caused the mis-ordered ST-RAM chunk then not to be mapped
in kernel VM space at all. We still need ST-RAM for video framebuffer and
DMA-able memory on Falcon, so I provided a dedicated ST-RAM allocator
(similar to what Geert did for Zorro2-RAM) that will map a pool of ST-RAM
and use that to satisfy the needs of atafb, atari_scsi and the like.
I had looked over Mike's patches to check that handling of such reserved
memory hasn't changed, but I have evidently missed something. Since kernels
with 'normal' ram chunk ordering work fine, the alternate ordering code path
is my prime suspect.
If I understand correctly, there are two types of RAM on Atari/ARAnyM:
ST-RAM and FastRAM. The ST-RAM resides at the physical range 0x0 - 0xe0 and
FastRAM takes a range somewhere above.
When the kernel is loaded into the FastRAM, bootloader sets the first entry
in the memory info to the FastRAM and the second one to ST-RAM and thus
m68k_memory becomes something like:
[0] = {
, ,
},
[1] = {
0x0, 0xe0,
}
In the paging_init() the ST-RAM chunk is essentially removed from the
m68k_memory, but it still can be used via the dedicated ST-RAM allocator.
Correct.
Yet, my patch surely didn't take such reordering into account, and, more
importantly, I didn't take care of the removal of an entry from
m68k_memory. As the result, memblock sees ST-RAM as available and will
allocated memory from there, but this memory is not yet mapped.
Ah - I had thought that since the ST-RAM chunk was passed over in
parsing the ramchunk bootinfo data, it was not made known to any parts
of the kernel (beyond the ST-RAM allocator) so no need to treat it
special beyond that.
I don't know what were the shortcomings of the old memory model, and why
ST-RAM and FastRAM are treated differently, so probably the simplest way
m68k used the discontigmem model, which does require memory chunks are
ordered. Not sure whether that is a requirement of the memory model, or
the MMU setup code for m68k. I had looked into this a few years back and
we would have needed a switch to a different memory model (NUMA?) at
that time, which was a bit too much for my taste.
ST-RAM is quite a bit slower than the other kind, but not as bad as with
Zorro-II RAM on Amiga. The system runs noticeably faster with the kernel
in FastRAM where available (in particular on 68060 accelerator cards),
and the larger FastRAM size means users mostly don't miss a little
ST-RAM. Making that bit available to user space again would be nice, but
it's not a priority for me.
would be just inform memblock that the ST-RAM is not available to it:
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index 7497cf3..0bda2c4 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -233,6 +233,7 @@ void __init paging_init(void)
printk("Ignoring memory chunk at 0x%lx:0x%lx before the
first chunk\n",
m68k_memory[i].addr, m68k_memory[i].size);
printk("Fix your bootloader or use a memfile to make use of
this area!\n");
+ memblock_remove(m68k_memory[i].addr,
m68k_memory[i].size);
m68k_num_memory--;
memmove(m68k_memory + i, m68k_memory + i + 1,
(m68k_num_memory - i) * sizeof(struct
m68k_mem_info));
I'll try that (at home, where I have the only ARAnyM installation that
seems to honour the SkipSTRAM or LoadToFastRAM options...)
Cheers,
Michael
I've tried to reproduce the bug by attempting to get the kernel loaded to
FastRAM. Doesn't work for me - with or without -s option I get the same
ordering of memory chunks (ST-RAM first) so the kernel clearly still runs in
ST-RAM.
Hence my question - how did you get the kernel loaded to FastRAM? What
version of ARAnyM do you use? What's the size of your kernel (uncompressed)?
Cheers,
Michael
Re: m68k-v4.19 crashes in free_all_bootmem
Hi Mike,
Am 03.12.2018 um 00:04 schrieb Mike Rapoport:
I don't know what were the shortcomings of the old memory model, and why
ST-RAM and FastRAM are treated differently, so probably the simplest way
would be just inform memblock that the ST-RAM is not available to it:
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index 7497cf3..0bda2c4 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -233,6 +233,7 @@ void __init paging_init(void)
printk("Ignoring memory chunk at 0x%lx:0x%lx before the
first chunk\n",
m68k_memory[i].addr, m68k_memory[i].size);
printk("Fix your bootloader or use a memfile to make use of
this area!\n");
+ memblock_remove(m68k_memory[i].addr,
m68k_memory[i].size);
m68k_num_memory--;
memmove(m68k_memory + i, m68k_memory + i + 1,
(m68k_num_memory - i) * sizeof(struct
m68k_mem_info));
Thanks, that's fixed it for me. Andreas?
Cheers,
Michael
Re: [PATCH v5 20/21] m68k/mac: Switch to use %ptR
On Thu, Nov 29, 2018 at 12:04 PM Andy Shevchenko
wrote:
> Use %ptR instead of open coded variant to print content of
> struct rtc_time in human readable format.
>
> Cc: Geert Uytterhoeven
> Cc: linux-m68k
> Signed-off-by: Andy Shevchenko
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
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 06/15] m68k: define syscall_get_arch()
Hi Dmitry,
On Tue, Nov 20, 2018 at 1:15 AM Dmitry V. Levin wrote:
> syscall_get_arch() is required to be implemented on all architectures
> in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
> request.
>
> Signed-off-by: Dmitry V. Levin
Reviewed-by: Geert Uytterhoeven
What's your plan w.r.t. the upstreaming strategy?
Do you plan to get this series in as a whole, or through individual architecture
maintainers?
Thanks!
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 v5 2/3] m68k: add system call table generation support
Hi Firoz,
On Tue, Nov 13, 2018 at 7:01 AM Firoz Khan wrote:
> The system call tables are in different format in all
> architecture and it will be difficult to manually add,
> modify or delete the syscall table entries in the res-
> pective files. To make it easy by keeping a script and
> which will generate the uapi header and syscall table
> file. This change will also help to unify the implemen-
> tation across all architectures.
>
> The system call table generation script is added in
> kernel/syscalls directory which contain the scripts to
> generate both uapi header file and system call table
> files. The syscall.tbl will be input for the scripts.
>
> syscall.tbl contains the list of available system calls
> along with system call number and corresponding entry
> point. Add a new system call in this architecture will
> be possible by adding new entry in the syscall.tbl file.
>
> Adding a new table entry consisting of:
> - System call number.
> - ABI.
> - System call name.
> - Entry point name.
>
> syscallhdr.sh and syscalltbl.sh will generate uapi header
> unistd_32.h and syscall_table.h files respectively. Both
> .sh files will parse the content syscall.tbl to generate
> the header and table files. unistd_32.h will be included
> by uapi/asm/unistd.h and syscall_table.h is included by
> kernel/syscall_table.S - the real system call table.
>
> ARM, s390 and x86 architecuture does have similar support.
> I leverage their implementation to come up with a generic
> solution.
>
> Signed-off-by: Firoz Khan
Thanks for your patch!
> --- /dev/null
> +++ b/arch/m68k/kernel/syscalls/syscallhdr.sh
> @@ -0,0 +1,36 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +
> +in="$1"
> +out="$2"
> +my_abis=`echo "($3)" | tr ',' '|'`
> +prefix="$4"
> +offset="$5"
> +
> +fileguard=_UAPI_ASM_M68K_`basename "$out" | sed \
> + -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' \
> + -e 's/[^A-Z0-9_]/_/g' -e 's/__/_/g'`
> +grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
> + printf "#ifndef %s\n" "${fileguard}"
> + printf "#define %s\n" "${fileguard}"
> + printf "\n"
> +
> + nxt=0
> + while read nr abi name entry ; do
> + if [ -z "$offset" ]; then
> + printf "#define __NR_%s%s\t%s\n" \
> + "${prefix}" "${name}" "${nr}"
> + else
> + printf "#define __NR_%s%s\t(%s + %s)\n" \
> + "${prefix}" "${name}" "${offset}" "${nr}"
> + fi
> + nxt=$((nr+1))
> + done
> +
> + printf "\n"
> + printf "#ifdef __KERNEL__\n"
> + printf "#define __NR_syscalls\t%s\n" "${nxt}"
> + printf "#endif\n"
> + printf "\n"
> + printf "#endif /* %s */" "${fileguard}"
The above line is lacking a "\n", causing:
./arch/m68k/include/generated/uapi/asm/unistd_32.h:370:42:
warning: no newline at end of file
Changing it to:
printf "#endif /* %s */\n" "${fileguard}"
fixes this.
Interestingly, this issue seems to be present on powerpc, parisc, sparc,
sh, xtensa (and probably more, I gave up looking), too?
Apart from that, it seems to work fine on m68k.
> +) > "$out"
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 06/15] m68k: define syscall_get_arch()
Hi Geert, On Sun, Dec 02, 2018 at 11:29:10AM +0100, Geert Uytterhoeven wrote: > Hi Dmitry, > > On Tue, Nov 20, 2018 at 1:15 AM Dmitry V. Levin wrote: > > syscall_get_arch() is required to be implemented on all architectures > > in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO > > request. > > > > Signed-off-by: Dmitry V. Levin > > Reviewed-by: Geert Uytterhoeven > > What's your plan w.r.t. the upstreaming strategy? > Do you plan to get this series in as a whole, or through individual > architecture > maintainers? Given that the last patch in this series adds an argument to syscall_get_arch(), my plan is to get this series in as a whole along with PTRACE_GET_SYSCALL_INFO series. -- ldv signature.asc Description: PGP signature
Re: [PATCH v2 06/15] m68k: define syscall_get_arch()
Hi Dmitry,
On Mon, Dec 3, 2018 at 1:24 AM Dmitry V. Levin wrote:
> On Sun, Dec 02, 2018 at 11:29:10AM +0100, Geert Uytterhoeven wrote:
> > On Tue, Nov 20, 2018 at 1:15 AM Dmitry V. Levin wrote:
> > > syscall_get_arch() is required to be implemented on all architectures
> > > in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
> > > request.
> > >
> > > Signed-off-by: Dmitry V. Levin
> >
> > Reviewed-by: Geert Uytterhoeven
> >
> > What's your plan w.r.t. the upstreaming strategy?
> > Do you plan to get this series in as a whole, or through individual
> > architecture
> > maintainers?
>
> Given that the last patch in this series adds an argument
> to syscall_get_arch(), my plan is to get this series in
> as a whole along with PTRACE_GET_SYSCALL_INFO series.
Cool, thanks!
Acked-by: Geert Uytterhoeven
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: m68k-v4.19 crashes in free_all_bootmem
Hi Michael, Mike,
On Mon, Dec 3, 2018 at 5:53 AM Michael Schmitz wrote:
> Am 03.12.2018 um 00:04 schrieb Mike Rapoport:
> > I don't know what were the shortcomings of the old memory model, and why
> > ST-RAM and FastRAM are treated differently, so probably the simplest way
> > would be just inform memblock that the ST-RAM is not available to it:
> >
> > diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
> > index 7497cf3..0bda2c4 100644
> > --- a/arch/m68k/mm/motorola.c
> > +++ b/arch/m68k/mm/motorola.c
> > @@ -233,6 +233,7 @@ void __init paging_init(void)
> > printk("Ignoring memory chunk at 0x%lx:0x%lx before
> > the first chunk\n",
> > m68k_memory[i].addr, m68k_memory[i].size);
> > printk("Fix your bootloader or use a memfile to make
> > use of this area!\n");
> > + memblock_remove(m68k_memory[i].addr,
> > m68k_memory[i].size);
> > m68k_num_memory--;
> > memmove(m68k_memory + i, m68k_memory + i + 1,
> > (m68k_num_memory - i) * sizeof(struct
> > m68k_mem_info));
> >
>
> Thanks, that's fixed it for me. Andreas?
Amigas with both Zorro III and Zorro II memory probably have a similar
issue, so I think we also need (gmail-whitespace-damaged):
--- a/arch/m68k/amiga/config.c
+++ b/arch/m68k/amiga/config.c
@@ -427,6 +427,8 @@ void __init config_amiga(void)
continue;
}
disabled_z2mem += m68k_memory[i].size;
+ memblock_remove(m68k_memory[i].addr,
+ m68k_memory[i].size);
m68k_num_memory--;
for (j = i; j < m68k_num_memory; j++)
m68k_memory[j] = m68k_memory[j+1];
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
