While porting u-boot/linux to the QEMU M68K virt machine with configured
with a 68000 cpu (i.e. nommu..) I noticed that this has been broken for
a while.
I can't test this works on DragonBall right now as I need to get u-boot
working, put the UART driver back etc but this is working fine on QEMU
with some other WIP bits except for the issue that as soon as a process
exits the kernel panics that I'm debugging currently:
qemu-system-m68k \
-cpu m68000 \
-m 128 \
-M virt \
-kernel u-boot/u-boot.elf.fudged \
-nographic \
-drive file=fat:./bootfiles/,if=none,id=drive-dummy,readonly=on \
-device virtio-blk-device,drive=drive-dummy \
-drive format=raw,file=buildroot/output/images/rootfs.squashfs,if=none,id=drive-rootfs \
-device virtio-blk-device,drive=drive-rootfs \
-device virtio-serial-device \
-netdev user,id=net1 \
-device virtio-net-device,netdev=net1 \
-s
U-Boot 2024.01-rc6-00024-g90c9fa986604-dirty (Jan 08 2024 - 17:58:36 +0900)
DRAM: 128 MiB
Core: 134 devices, 6 uclasses, devicetree: embed
Warning: Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07!
Loading Environment from nowhere... OK
In: uart@ff008000
Out: uart@ff008000
Err: uart@ff008000
Net: No ethernet found.
=> virtio scan; fatload virtio 1:1 0x3000000 vmlinux; setenv autostart yes; setenv bootargs console=ttyGF0 init=/bin/sh root=/dev/vda rootfstype=squashfs; bootelf 0x3000000
3669228 bytes read in 5 ms (699.8 MiB/s)
## Starting application at 0x00000400 ...
new fdt 07bf1810
[ 0.000000] Linux version 6.7.0-rc8-00188-gd9657c8bdd78 (daniel@shiro) (m68k-linux-gnu-gcc (Debian 13.2.0-7) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41.50.20231227) #38 Mon Jan 8 17:58:45 JST 2024
[ 0.000000] Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
[ 0.000000] Generic DT Machine (C) 2024 Daniel Palmer <[email protected]>
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x00000000ffffefff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Kernel command line: console=ttyGF0 init=/bin/sh root=/dev/vda rootfstype=squashfs
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 32512
[ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[ 0.000000] Memory: 126140K/131072K available (2571K kernel code, 299K rwdata, 604K rodata, 108K init, 106K bss, 4932K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=16, Order=0-1, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] NR_IRQS: 126
[ 0.000000] irq_goldfish_pic: /soc/pic@0: Successfully registered.
[ 0.000000] irq_goldfish_pic: /soc/pic@1: Successfully registered.
[ 0.000000] irq_goldfish_pic: /soc/pic@2: Successfully registered.
[ 0.000000] irq_goldfish_pic: /soc/pic@3: Successfully registered.
[ 0.000000] irq_goldfish_pic: /soc/pic@4: Successfully registered.
[ 0.000000] irq_goldfish_pic: /soc/pic@5: Successfully registered.
[ 0.010000] Calibrating delay loop... 2046.36 BogoMIPS (lpj=10231808)
[ 0.070000] pid_max: default: 32768 minimum: 301
[ 0.070000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.070000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.080000] devtmpfs: initialized
[ 0.090000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.090000] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[ 0.100000] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.140000] NET: Registered PF_INET protocol family
[ 0.140000] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
[ 0.140000] tcp_listen_portaddr_hash hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.140000] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.150000] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.150000] TCP bind hash table entries: 1024 (order: 1, 8192 bytes, linear)
[ 0.150000] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.150000] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 0.150000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 0.150000] workingset: timestamp_bits=30 max_order=15 bucket_order=0
[ 0.150000] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 0.160000] printk: legacy console [ttyGF0] enabled
[ 0.170000] virtio_blk virtio2: 1/0/0 default/read/poll queues
[ 0.170000] virtio_blk virtio2: [vda] 936 512-byte logical blocks (479 kB/468 KiB)
[ 0.180000] virtio_blk virtio3: 1/0/0 default/read/poll queues
[ 0.180000] virtio_blk virtio3: [vdb] 1032192 512-byte logical blocks (528 MB/504 MiB)
[ 0.180000] vdb: vdb1
[ 0.190000] goldfish_rtc ff007000.rtc: registered as rtc0
[ 0.190000] goldfish_rtc ff007000.rtc: setting system clock to 2024-01-08T08:58:52 UTC (1704704332)
[ 0.190000] NET: Registered PF_INET6 protocol family
[ 0.190000] Segment Routing with IPv6
[ 0.190000] In-situ OAM (IOAM) with IPv6
[ 0.190000] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 0.210000] VFS: Mounted root (squashfs filesystem) readonly on device 254:0.
[ 0.210000] devtmpfs: mounted
[ 0.210000] Freeing unused kernel image (initmem) memory: 108K
[ 0.210000] This architecture does not have kernel memory protection.
[ 0.210000] Run /bin/sh as init process
[ 0.250000] random: sh: uninitialized urandom read (4 bytes read)
~ # uname -a
[ 54.830000] random: uname: uninitialized urandom read (4 bytes read)
uClinux (none) 6.7.0-rc8-00188-gd9657c8bdd78 #38 Mon Jan 8 17:58:45 JST 2024 m68k GNU/Linux
[ 54.840000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[ 54.840000] CPU: 0 PID: 1 Comm: sh Not tainted 6.7.0-rc8-00188-gd9657c8bdd78 #38
[ 54.840000] Stack from 0041bf20:
[ 54.840000] 0041bf20 002fd8d1 002fd8d1 0041fb00 00000001 0041bf40 0027e946 002fd8d1
[ 54.840000] 0041bf5c 0027b36e 0041fbc4 000000ff 00000000 00418000 00321ba4 0041bfa0
[ 54.840000] 0027bbee 002f6dbe 00000000 00000000 000000f7 0062e538 00000001 00000000
[ 54.840000] 00000000 00004c10 008255fe 00825272 008406da 008255fe 0041bf98 0041bf98
[ 54.840000] 0041bfb4 000057f8 00000000 00000000 0041a000 0041bfc4 0027bdf2 00000000
[ 54.840000] 002f6ef9 00891cb4 000019f8 00000000 00000000 000000f7 0062e538 00000001
[ 54.840000] Call Trace: [<0027e946>] dump_stack+0x10/0x16
[ 54.840000] [<0027b36e>] panic+0xc2/0x24c
[ 54.840000] [<0027bbee>] do_exit+0x4bc/0x684
[ 54.840000] [<00004c10>] get_current+0x0/0x16
[ 54.840000] [<000057f8>] do_group_exit+0x2a/0x6c
[ 54.840000] [<0027bdf2>] pr_cont_pool_info+0x0/0x62
[ 54.840000] [<000019f8>] system_call+0x48/0x4c
[ 54.840000] [<00200000>] tcp_seq_next+0x6e/0x90
[ 54.840000]
[ 54.840000] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 ]---
Daniel Palmer (2):
m68k: Use macro to generate 68000 interrupt entry sleds
m68k: Fix interrupt stack frames for 68000
arch/m68k/68000/entry.S | 103 ++++++----------------------
arch/m68k/68000/ints.c | 30 ++++----
arch/m68k/include/asm/entry.h | 3 +
arch/m68k/include/uapi/asm/ptrace.h | 2 +-
4 files changed, 40 insertions(+), 98 deletions(-)
--
2.43.0
In preparation for decoupling the plain 68000 code from
the DragonBall support clean entry.S a little bit by
using a macro to generic the interrupt sleds (needed to
put the vector number on the stack as the 68000 doesn't
do that) and use the correct numbers.
The function to call from the sled is a parameter so that
other interrupt types (i.e. autovectored ones) can specify
their handler when they are added later.
Signed-off-by: Daniel Palmer <[email protected]>
---
arch/m68k/68000/entry.S | 100 ++++++++--------------------------------
arch/m68k/68000/ints.c | 28 +++++------
2 files changed, 34 insertions(+), 94 deletions(-)
diff --git a/arch/m68k/68000/entry.S b/arch/m68k/68000/entry.S
index 72e95663b62f..e1fc740412f2 100644
--- a/arch/m68k/68000/entry.S
+++ b/arch/m68k/68000/entry.S
@@ -23,13 +23,6 @@
.globl ret_from_exception
.globl sys_call_table
.globl bad_interrupt
-.globl inthandler1
-.globl inthandler2
-.globl inthandler3
-.globl inthandler4
-.globl inthandler5
-.globl inthandler6
-.globl inthandler7
badsys:
movel #-ENOSYS,%sp@(PT_OFF_D0)
@@ -119,85 +112,32 @@ Lsignal_return:
addql #4,%sp
jra 1b
-/*
- * This is the main interrupt handler, responsible for calling process_int()
- */
-inthandler1:
- SAVE_ALL_INT
- movew %sp@(PT_OFF_FORMATVEC), %d0
- and #0x3ff, %d0
-
- movel %sp,%sp@-
- movel #65,%sp@- /* put vector # on stack*/
- jbsr process_int /* process the IRQ*/
-3: addql #8,%sp /* pop parameters off stack*/
- bra ret_from_exception
-
-inthandler2:
- SAVE_ALL_INT
- movew %sp@(PT_OFF_FORMATVEC), %d0
- and #0x3ff, %d0
-
- movel %sp,%sp@-
- movel #66,%sp@- /* put vector # on stack*/
- jbsr process_int /* process the IRQ*/
-3: addql #8,%sp /* pop parameters off stack*/
- bra ret_from_exception
-
-inthandler3:
- SAVE_ALL_INT
- movew %sp@(PT_OFF_FORMATVEC), %d0
- and #0x3ff, %d0
-
- movel %sp,%sp@-
- movel #67,%sp@- /* put vector # on stack*/
- jbsr process_int /* process the IRQ*/
-3: addql #8,%sp /* pop parameters off stack*/
- bra ret_from_exception
-
-inthandler4:
+/* Create an interrupt vector sled */
+ .macro inthandler num func
+ .globl inthandler\num
+ inthandler\num:
SAVE_ALL_INT
movew %sp@(PT_OFF_FORMATVEC), %d0
and #0x3ff, %d0
movel %sp,%sp@-
- movel #68,%sp@- /* put vector # on stack*/
- jbsr process_int /* process the IRQ*/
-3: addql #8,%sp /* pop parameters off stack*/
- bra ret_from_exception
-
-inthandler5:
- SAVE_ALL_INT
- movew %sp@(PT_OFF_FORMATVEC), %d0
- and #0x3ff, %d0
-
- movel %sp,%sp@-
- movel #69,%sp@- /* put vector # on stack*/
- jbsr process_int /* process the IRQ*/
-3: addql #8,%sp /* pop parameters off stack*/
- bra ret_from_exception
-
-inthandler6:
- SAVE_ALL_INT
- movew %sp@(PT_OFF_FORMATVEC), %d0
- and #0x3ff, %d0
-
- movel %sp,%sp@-
- movel #70,%sp@- /* put vector # on stack*/
- jbsr process_int /* process the IRQ*/
-3: addql #8,%sp /* pop parameters off stack*/
- bra ret_from_exception
-
-inthandler7:
- SAVE_ALL_INT
- movew %sp@(PT_OFF_FORMATVEC), %d0
- and #0x3ff, %d0
-
- movel %sp,%sp@-
- movel #71,%sp@- /* put vector # on stack*/
- jbsr process_int /* process the IRQ*/
-3: addql #8,%sp /* pop parameters off stack*/
+ /* put vector # on stack*/
+ movel #\num,%sp@-
+ /* process the IRQ*/
+ jbsr \func
+ /* pop parameters off stack*/
+ addql #8,%sp
bra ret_from_exception
+ .endm
+
+/* Dragonball interrupts */
+inthandler 65 process_int
+inthandler 66 process_int
+inthandler 67 process_int
+inthandler 68 process_int
+inthandler 69 process_int
+inthandler 70 process_int
+inthandler 71 process_int
inthandler:
SAVE_ALL_INT
diff --git a/arch/m68k/68000/ints.c b/arch/m68k/68000/ints.c
index 2ba9926e91ae..e721932e495d 100644
--- a/arch/m68k/68000/ints.c
+++ b/arch/m68k/68000/ints.c
@@ -63,13 +63,13 @@ asmlinkage void trap46(void);
asmlinkage void trap47(void);
asmlinkage irqreturn_t bad_interrupt(int, void *);
asmlinkage irqreturn_t inthandler(void);
-asmlinkage irqreturn_t inthandler1(void);
-asmlinkage irqreturn_t inthandler2(void);
-asmlinkage irqreturn_t inthandler3(void);
-asmlinkage irqreturn_t inthandler4(void);
-asmlinkage irqreturn_t inthandler5(void);
-asmlinkage irqreturn_t inthandler6(void);
-asmlinkage irqreturn_t inthandler7(void);
+asmlinkage irqreturn_t inthandler65(void);
+asmlinkage irqreturn_t inthandler66(void);
+asmlinkage irqreturn_t inthandler67(void);
+asmlinkage irqreturn_t inthandler68(void);
+asmlinkage irqreturn_t inthandler69(void);
+asmlinkage irqreturn_t inthandler70(void);
+asmlinkage irqreturn_t inthandler71(void);
/* The 68k family did not have a good way to determine the source
* of interrupts until later in the family. The EC000 core does
@@ -163,13 +163,13 @@ void __init trap_init(void)
_ramvec[32] = system_call;
- _ramvec[65] = (e_vector) inthandler1;
- _ramvec[66] = (e_vector) inthandler2;
- _ramvec[67] = (e_vector) inthandler3;
- _ramvec[68] = (e_vector) inthandler4;
- _ramvec[69] = (e_vector) inthandler5;
- _ramvec[70] = (e_vector) inthandler6;
- _ramvec[71] = (e_vector) inthandler7;
+ _ramvec[65] = (e_vector) inthandler65;
+ _ramvec[66] = (e_vector) inthandler66;
+ _ramvec[67] = (e_vector) inthandler67;
+ _ramvec[68] = (e_vector) inthandler68;
+ _ramvec[69] = (e_vector) inthandler69;
+ _ramvec[70] = (e_vector) inthandler70;
+ _ramvec[71] = (e_vector) inthandler71;
}
void __init init_IRQ(void)
--
2.43.0
The plain old 68000 does not push the frame type/vector on the
stack when an interrupt starts like the brand new 68010 does.
This means that currently everything in struct pt_regs is
a bit off because it expects the processor to push an extra
short before the kernel interrupt code adds the rest.
In entry.S for the 68000 we already need to manually put
the vector number on the stack to work out what interrupt
is being handled because the cpu doesn't push that to the
stack.
So we can jiggle this around a bit to fix the issue:
- For 68000 use the same struct pt_regs layout as coldfire
where frame/vector is after pc and sp.
- In entry.S push the vector number first, the stack pointer
now lines up with the sktadj field in pt_regs and when saving
the remaining registers the offsets match the fields in the
struct.
- Remove the vec argument from the DragonBall interrupt
decoding logic as it's not pushed on the stack anymore
and not used either way.
Signed-off-by: Daniel Palmer <[email protected]>
---
arch/m68k/68000/entry.S | 9 ++++-----
arch/m68k/68000/ints.c | 2 +-
arch/m68k/include/asm/entry.h | 3 +++
arch/m68k/include/uapi/asm/ptrace.h | 2 +-
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/m68k/68000/entry.S b/arch/m68k/68000/entry.S
index e1fc740412f2..58c64656713a 100644
--- a/arch/m68k/68000/entry.S
+++ b/arch/m68k/68000/entry.S
@@ -54,6 +54,7 @@ do_trace:
jra ret_from_exception
ENTRY(system_call)
+ movew #32,%sp@-
SAVE_ALL_SYS
/* save top of frame*/
@@ -116,17 +117,15 @@ Lsignal_return:
.macro inthandler num func
.globl inthandler\num
inthandler\num:
+ movew #\num,%sp@-
SAVE_ALL_INT
- movew %sp@(PT_OFF_FORMATVEC), %d0
- and #0x3ff, %d0
+ /* Push frame address onto stack */
movel %sp,%sp@-
- /* put vector # on stack*/
- movel #\num,%sp@-
/* process the IRQ*/
jbsr \func
/* pop parameters off stack*/
- addql #8,%sp
+ addql #4,%sp
bra ret_from_exception
.endm
diff --git a/arch/m68k/68000/ints.c b/arch/m68k/68000/ints.c
index e721932e495d..67c8f9e000ca 100644
--- a/arch/m68k/68000/ints.c
+++ b/arch/m68k/68000/ints.c
@@ -77,7 +77,7 @@ asmlinkage irqreturn_t inthandler71(void);
* into one vector and look in the blasted mask register...
* This code is designed to be fast, almost constant time, not clean!
*/
-asmlinkage void process_int(int vec, struct pt_regs *fp)
+asmlinkage void process_int(struct pt_regs *fp)
{
int irq;
int mask;
diff --git a/arch/m68k/include/asm/entry.h b/arch/m68k/include/asm/entry.h
index 9b52b060c76a..71396c948162 100644
--- a/arch/m68k/include/asm/entry.h
+++ b/arch/m68k/include/asm/entry.h
@@ -184,6 +184,7 @@
* that the stack frame is NOT for syscall
*/
.macro SAVE_ALL_INT
+ /* entry.S should populate the vector */
clrl %sp@- /* stk_adj */
pea -1:w /* orig d0 */
movel %d0,%sp@- /* d0 */
@@ -191,6 +192,7 @@
.endm
.macro SAVE_ALL_SYS
+ /* entry.S should populate the vector */
clrl %sp@- /* stk_adj */
movel %d0,%sp@- /* orig d0 */
movel %d0,%sp@- /* d0 */
@@ -202,6 +204,7 @@
movel %sp@+,%d0
addql #4,%sp /* orig d0 */
addl %sp@+,%sp /* stk adj */
+ addql #2,%sp /* entry.S populated vector */
rte
.endm
diff --git a/arch/m68k/include/uapi/asm/ptrace.h b/arch/m68k/include/uapi/asm/ptrace.h
index 5b50ea592e00..49d7829df77c 100644
--- a/arch/m68k/include/uapi/asm/ptrace.h
+++ b/arch/m68k/include/uapi/asm/ptrace.h
@@ -39,7 +39,7 @@ struct pt_regs {
long d0;
long orig_d0;
long stkadj;
-#ifdef CONFIG_COLDFIRE
+#if defined(CONFIG_COLDFIRE) || defined(CONFIG_M68000)
unsigned format : 4; /* frame format specifier */
unsigned vector : 12; /* vector offset */
unsigned short sr;
--
2.43.0
Hi Daniel,
Thanks for your patch!
On Mon, Jan 8, 2024 at 10:32 AM Daniel Palmer <[email protected]> wrote:
> The plain old 68000 does not push the frame type/vector on the
> stack when an interrupt starts like the brand new 68010 does.
;-)
> This means that currently everything in struct pt_regs is
> a bit off because it expects the processor to push an extra
> short before the kernel interrupt code adds the rest.
>
> In entry.S for the 68000 we already need to manually put
> the vector number on the stack to work out what interrupt
> is being handled because the cpu doesn't push that to the
> stack.
>
> So we can jiggle this around a bit to fix the issue:
> - For 68000 use the same struct pt_regs layout as coldfire
> where frame/vector is after pc and sp.
> - In entry.S push the vector number first, the stack pointer
> now lines up with the sktadj field in pt_regs and when saving
> the remaining registers the offsets match the fields in the
> struct.
> - Remove the vec argument from the DragonBall interrupt
> decoding logic as it's not pushed on the stack anymore
> and not used either way.
>
> Signed-off-by: Daniel Palmer <[email protected]>
> --- a/arch/m68k/include/uapi/asm/ptrace.h
> +++ b/arch/m68k/include/uapi/asm/ptrace.h
> @@ -39,7 +39,7 @@ struct pt_regs {
> long d0;
> long orig_d0;
> long stkadj;
> -#ifdef CONFIG_COLDFIRE
> +#if defined(CONFIG_COLDFIRE) || defined(CONFIG_M68000)
> unsigned format : 4; /* frame format specifier */
> unsigned vector : 12; /* vector offset */
> unsigned short sr;
I think it would be better to use the classic m68k stack frame.
That would pave the way for building a single nommu kernel for
MC680[012346]0 that runs on e.g. any Amiga.
MC68000 and Coldfire are incompatible anyway.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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 Geert,
On Mon, 8 Jan 2024 at 18:56, Geert Uytterhoeven <[email protected]> wrote:
>
> I think it would be better to use the classic m68k stack frame.
> That would pave the way for building a single nommu kernel for
> MC680[012346]0 that runs on e.g. any Amiga.
> MC68000 and Coldfire are incompatible anyway.
Ok, I'll work that out. I have an A600 with an 020 board so I could
actually test it on real hardware. :)
Cheers,
Daniel
Hi Daniel,
kernel test robot noticed the following build errors:
[auto build test ERROR on gerg-m68knommu/for-next]
[also build test ERROR on geert-m68k/for-next geert-m68k/for-linus linus/master v6.7 next-20240108]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Daniel-Palmer/m68k-Use-macro-to-generate-68000-interrupt-entry-sleds/20240108-175040
base: https://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next
patch link: https://lore.kernel.org/r/20240108093221.1477020-3-daniel%400x0f.com
patch subject: [PATCH v2 2/2] m68k: Fix interrupt stack frames for 68000
config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20240109/[email protected]/config)
compiler: m68k-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240109/[email protected]/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
All errors (new ones prefixed by >>):
scripts/genksyms/parse.y: warning: 9 shift/reduce conflicts [-Wconflicts-sr]
scripts/genksyms/parse.y: warning: 5 reduce/reduce conflicts [-Wconflicts-rr]
scripts/genksyms/parse.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples
>> error: arch/m68k/include/uapi/asm/ptrace.h: leak CONFIG_M68000 to user-space
make[3]: *** [scripts/Makefile.headersinst:63: usr/include/asm/ptrace.h] Error 1
make[3]: Target '__headers' not remade because of errors.
make[2]: *** [Makefile:1288: headers] Error 2
make[2]: Target 'prepare' not remade because of errors.
make[1]: *** [Makefile:234: __sub-make] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:234: __sub-make] Error 2
make: Target 'prepare' not remade because of errors.
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Hi All,
Sorry for the spam..
On Mon, 8 Jan 2024 at 18:56, Geert Uytterhoeven <[email protected]> wrote:
> I think it would be better to use the classic m68k stack frame.
> That would pave the way for building a single nommu kernel for
> MC680[012346]0 that runs on e.g. any Amiga.
> MC68000 and Coldfire are incompatible anyway.
While looking at how to do this I realised that the addql #2,%sp in
RESTORE_ALL in entry.h will now break the stack frames for those fancy
68010+ users.
So that needs to be #ifdef'd to make it only compile for 68000. I saw
an error email from the next build stuff so I guess the change has
been queued somewhere? If so I should send a fix..
I'm not sure how to actually make that generic without patching the
code at runtime (remove the 68000 specific bit, reserve enough extra
space to rewrite the code..) but it's a macro so not so simple.
Anyhow, and more importantly, it seems like there is another issue in
68000/entry.S that breaks syscalls (especially vfork). After fixing
that I now have a working nommu 68000 system. I'll send a fix for that
too.
Cheers,
Daniel
Hi Daniel,
On Tue, Jan 9, 2024 at 3:10 PM Daniel Palmer <[email protected]> wrote:
> On Mon, 8 Jan 2024 at 18:56, Geert Uytterhoeven <[email protected]> wrote:
> > I think it would be better to use the classic m68k stack frame.
> > That would pave the way for building a single nommu kernel for
> > MC680[012346]0 that runs on e.g. any Amiga.
> > MC68000 and Coldfire are incompatible anyway.
>
> While looking at how to do this I realised that the addql #2,%sp in
> RESTORE_ALL in entry.h will now break the stack frames for those fancy
> 68010+ users.
> So that needs to be #ifdef'd to make it only compile for 68000. I saw
> an error email from the next build stuff so I guess the change has
> been queued somewhere? If so I should send a fix..
AFAIK it hasn't been applied yet. These days the bots also test
patches from mailing lists...
> I'm not sure how to actually make that generic without patching the
> code at runtime (remove the 68000 specific bit, reserve enough extra
> space to rewrite the code..) but it's a macro so not so simple.
Or use different entry points depending on CPU type?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
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