[Cc: +LLVM/clang build support folks] Dear Zhouyi, dear Nathan, dear Nick, To recap: On a ppc64le machine, building Linux in Ubuntu 21.10 with *llvm* and *clang* 1:13.0-53~exp1 $ clang --version Ubuntu clang version 13.0.0-2 Target: powerpc64le-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin results in a segmentation fault, while it works when building with GCC. $ gcc --version gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0 ``` […] [ T1] ipip: IPv4 and MPLS over IPv4 tunneling driver [ T1] NET: Registered PF_INET6 protocol family [ T1] Segment Routing with IPv6 [ T1] In-situ OAM (IOAM) with IPv6 [ T1] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver [ T1] BUG: Kernel NULL pointer dereference on write at 0x00000000 [ T1] Faulting instruction address: 0xc0000000008e2400 [ T1] Oops: Kernel access of bad area, sig: 11 [#1] [ T1] LE PAGE_SIZE=64K MMU=Hash PREEMPT SMP NR_CPUS=16 NUMA PowerNV [ T1] Modules linked in: [ T1] CPU: 11 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc1-00032-gdd81e1c7d5fb #29 [ T1] NIP: c0000000008e2400 LR: c000000000d65db0 CTR: c000000000f0bb60 [ T1] REGS: c0000000125033e0 TRAP: 0380 Not tainted (5.17.0-rc1-00032-gdd81e1c7d5fb) [ T1] MSR: 9000000000009033 CR: 42800c40 XER: 00000000 [ T1] CFAR: c000000000d65dac IRQMASK: 0 [ T1] GPR00: c000000000d65b40 c000000012503680 c00000000290c600 0000000000000000 [ T1] GPR04: ffffffffffffffff 00000000ffffffff 0000000000000000 0000000000000cc0 [ T1] GPR08: 0000000000000000 0000000000000000 ffffffffffffffff 0000000000000001 [ T1] GPR12: 0000000000000000 c000007fffff6c00 c000000000012478 0000000000000000 [ T1] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ T1] GPR20: 0000000000000000 c000000002810100 0000000000000cc0 0000000000000000 [ T1] GPR24: 0000000000000010 c00000000294cf50 0000000000000000 0000000000000000 [ T1] GPR28: 0000000000000000 c00000001ec61000 0000000000000000 c000000012503680 [ T1] NIP [c0000000008e2400] strlen+0x10/0x30 [ T1] LR [c000000000d65db0] if_nlmsg_size+0x150/0x360 [ T1] Call Trace: [ T1] [c000000012503680] [c0000000125036c0] 0xc0000000125036c0 (unreliable) [ T1] [c0000000125036f0] [c000000000d65b40] rtmsg_ifinfo_build_skb+0x80/0x1a0 [ T1] [c0000000125037b0] [c000000000d66be0] rtmsg_ifinfo+0x70/0xd0 [ T1] [c000000012503800] [c000000000d4de50] register_netdevice+0x690/0x770 [ T1] [c000000012503890] [c000000000d4e2bc] register_netdev+0x4c/0x80 [ T1] [c0000000125038c0] [c000000000f4784c] sit_init_net+0x10c/0x1d0 [ T1] [c000000012503910] [c000000000d33c0c] ops_init+0x13c/0x1b0 [ T1] [c000000012503970] [c000000000d331bc] register_pernet_operations+0xec/0x1e0 [ T1] [c0000000125039d0] [c000000000d33440] register_pernet_device+0x60/0xd0 [ T1] [c000000012503a20] [c000000002085478] sit_init+0x54/0x160 [ T1] [c000000012503ab0] [c000000000011ba8] do_one_initcall+0xd8/0x3b0 [ T1] [c000000012503c70] [c000000002006064] do_initcall_level+0xe4/0x1c4 [ T1] [c000000012503cc0] [c000000002005f20] do_initcalls+0x84/0xe4 [ T1] [c000000012503d40] [c000000002005c7c] kernel_init_freeable+0x160/0x1ec [ T1] [c000000012503da0] [c0000000000124ac] kernel_init+0x3c/0x270 [ T1] [c000000012503e10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64 [ T1] Instruction dump: [ T1] eb81ffe0 7c0803a6 4e800020 00000000 00000000 00000000 60000000 60000000 [ T1] 3883ffff 60000000 60000000 60000000 <8ca40001> 28050000 4082fff8 7c632050 [ T1] ---[ end trace 0000000000000000 ]--- [ T1] [ T1] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b […] ``` Am 30.01.22 um 14:24 schrieb Zhouyi Zhou: > On Sun, Jan 30, 2022 at 4:19 PM Paul Menzel wrote: >> Am 30.01.22 um 01:21 schrieb Zhouyi Zhou: >> >>> Thank you for your instructions, I learned a lot from this process. >> >> Same on my end. >> >>> On Sun, Jan 30, 2022 at 12:52 AM Paul Menzel wrote: >> >>>> Am 29.01.22 um 03:23 schrieb Zhouyi Zhou: >>>> >>>>> I don't have an IBM machine, but I tried to analyze the problem using >>>>> my x86_64 kvm virtual machine, I can't reproduce the bug using my >>>>> x86_64 kvm virtual machine. >>>> >>>> No idea, if it’s architecture specific. >>>> >>>>> I saw the panic is caused by registration of sit device (A sit device >>>>> is a type of virtual network device that takes our IPv6 traffic, >>>>> encapsulates/decapsulates it in IPv4 packets, and sends/receives it >>>>> over the IPv4 Internet to another host) >>>>> >>>>> sit device is registered in function sit_init_net: >>>>> 1895 static int __net_init sit_init_net(struct net *net) >>>>> 1896 { >>>>> 1897 struct sit_net *sitn = net_generic(net, sit_net_id); >>>>> 1898 struct ip_tunnel *t; >>>>> 1899 int err; >>>>> 1900 >>>>> 1901 sitn->tunnels[0] = sitn->tunnels_wc; >>>>> 1902 sitn->tunnels[1] = sitn->tunnels_l; >>>>> 1903 sitn->tunnels[2] = sitn->tunnels_r; >>>>> 1904 sitn->tunnels[3] = sitn->tunnels_r_l; >>>>> 1905 >>>>> 1906 if (!net_has_fallback_tunnels(net)) >>>>> 1907 return 0; >>>>> 1908 >>>>> 1909 sitn->fb_tunnel_dev = alloc_netdev(sizeof(struct ip_tunnel), "sit0", >>>>> 1910 NET_NAME_UNKNOWN, >>>>> 1911 ipip6_tunnel_setup); >>>>> 1912 if (!sitn->fb_tunnel_dev) { >>>>> 1913 err = -ENOMEM; >>>>> 1914 goto err_alloc_dev; >>>>> 1915 } >>>>> 1916 dev_net_set(sitn->fb_tunnel_dev, net); >>>>> 1917 sitn->fb_tunnel_dev->rtnl_link_ops = &sit_link_ops; >>>>> 1918 /* FB netdevice is special: we have one, and only one per netns. >>>>> 1919 * Allowing to move it to another netns is clearly unsafe. >>>>> 1920 */ >>>>> 1921 sitn->fb_tunnel_dev->features |= NETIF_F_NETNS_LOCAL; >>>>> 1922 >>>>> 1923 err = register_netdev(sitn->fb_tunnel_dev); >>>>> register_netdev on line 1923 will call if_nlmsg_size indirectly. >>>>> >>>>> On the other hand, the function that calls the paniced strlen is if_nlmsg_size: >>>>> (gdb) disassemble if_nlmsg_size >>>>> Dump of assembler code for function if_nlmsg_size: >>>>> 0xffffffff81a0dc20 <+0>: nopl 0x0(%rax,%rax,1) >>>>> 0xffffffff81a0dc25 <+5>: push %rbp >>>>> 0xffffffff81a0dc26 <+6>: push %r15 >>>>> 0xffffffff81a0dd04 <+228>: je 0xffffffff81a0de20 >>>>> 0xffffffff81a0dd0a <+234>: mov 0x10(%rbp),%rdi >>>>> ... >>>>> => 0xffffffff81a0dd0e <+238>: callq 0xffffffff817532d0 >>>>> 0xffffffff81a0dd13 <+243>: add $0x10,%eax >>>>> 0xffffffff81a0dd16 <+246>: movslq %eax,%r12 >>>> >>>> Excuse my ignorance, would that look the same for ppc64le? >>>> Unfortunately, I didn’t save the problematic `vmlinuz` file, but on a >>>> current build (without rcutorture) I have the line below, where strlen >>>> shows up. >>>> >>>> (gdb) disassemble if_nlmsg_size >>>> […] >>>> 0xc000000000f7f82c <+332>: bl 0xc000000000a10e30 >>>> […] >>>> >>>>> and the C code for 0xffffffff81a0dd0e is following (line 524): >>>>> 515 static size_t rtnl_link_get_size(const struct net_device *dev) >>>>> 516 { >>>>> 517 const struct rtnl_link_ops *ops = dev->rtnl_link_ops; >>>>> 518 size_t size; >>>>> 519 >>>>> 520 if (!ops) >>>>> 521 return 0; >>>>> 522 >>>>> 523 size = nla_total_size(sizeof(struct nlattr)) + /* IFLA_LINKINFO */ >>>>> 524 nla_total_size(strlen(ops->kind) + 1); /* IFLA_INFO_KIND */ >>>> >>>> How do I connect the disassemby output with the corresponding line? >>> I use "make ARCH=powerpc CC=powerpc64le-linux-gnu-gcc-9 >>> CROSS_COMPILE=powerpc64le-linux-gnu- -j 16" to cross compile kernel >>> for powerpc64le in my Ubuntu 20.04 x86_64. >>> >>> gdb-multiarch ./vmlinux >>> (gdb)disassemble if_nlmsg_size >>> [...] >>> 0xc00000000191bf40 <+112>: bl 0xc000000001c28ad0 >>> [...] >>> (gdb) break *0xc00000000191bf40 >>> Breakpoint 1 at 0xc00000000191bf40: file ./include/net/netlink.h, line 1112. >>> >>> But in include/net/netlink.h:1112, I can't find the call to strlen >>> 1110static inline int nla_total_size(int payload) >>> 1111{ >>> 1112 return NLA_ALIGN(nla_attr_size(payload)); >>> 1113} >>> This may be due to the compiler wrongly encode the debug information, I guess. >> >> `rtnl_link_get_size()` contains: >> >> size = nla_total_size(sizeof(struct nlattr)) + /* >> IFLA_LINKINFO */ >> nla_total_size(strlen(ops->kind) + 1); /* >> IFLA_INFO_KIND */ >> >> Is that inlined(?) and the code at fault? > Yes, that is inlined! because > (gdb) disassemble if_nlmsg_size > Dump of assembler code for function if_nlmsg_size: > [...] > 0xc00000000191bf38 <+104>: beq 0xc00000000191c1f0 > 0xc00000000191bf3c <+108>: ld r3,16(r31) > 0xc00000000191bf40 <+112>: bl 0xc000000001c28ad0 > [...] > (gdb) > (gdb) break *0xc00000000191bf40 > Breakpoint 1 at 0xc00000000191bf40: file ./include/net/netlink.h, line 1112. > (gdb) break *0xc00000000191bf38 > Breakpoint 2 at 0xc00000000191bf38: file net/core/rtnetlink.c, line 520. > >> >>>>> But ops is assigned the value of sit_link_ops in function sit_init_net >>>>> line 1917, so I guess something must happened between the calls. >>>>> >>>>> Do we have KASAN in IBM machine? would KASAN help us find out what >>>>> happened in between? >>>> >>>> Unfortunately, KASAN is not support on Power, I have, as far as I can >>>> see. From `arch/powerpc/Kconfig`: >>>> >>>> select HAVE_ARCH_KASAN if PPC32 && PPC_PAGE_SHIFT <= 14 >>>> select HAVE_ARCH_KASAN_VMALLOC if PPC32 && PPC_PAGE_SHIFT <= 14 >>>> >>> en, agree, I invoke "make menuconfig ARCH=powerpc >>> CC=powerpc64le-linux-gnu-gcc-9 CROSS_COMPILE=powerpc64le-linux-gnu- -j >>> 16", I can't find KASAN under Memory Debugging, I guess we should find >>> the bug by bisecting instead. >> >> I do not know, if it is a regression, as it was the first time I tried >> to run a Linux kernel built with rcutorture on real hardware. > I tried to add some debug statements to the kernel to locate the bug > more accurately, you can try it when you're not busy in the future, > or just ignore it if the following patch looks not very effective ;-) > diff --git a/net/core/dev.c b/net/core/dev.c > index 1baab07820f6..969ac7c540cc 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -9707,6 +9707,9 @@ int register_netdevice(struct net_device *dev) > * Prevent userspace races by waiting until the network > * device is fully setup before sending notifications. > */ > + if (dev->rtnl_link_ops) > + printk(KERN_INFO "%lx IFLA_INFO_KIND %s %s\n", dev->rtnl_link_ops, > + dev->rtnl_link_ops->kind, __FUNCTION__); > if (!dev->rtnl_link_ops || > dev->rtnl_link_state == RTNL_LINK_INITIALIZED) > rtmsg_ifinfo(RTM_NEWLINK, dev, ~0U, GFP_KERNEL); > @@ -9788,6 +9791,9 @@ int register_netdev(struct net_device *dev) > > if (rtnl_lock_killable()) > return -EINTR; > + if (dev->rtnl_link_ops) > + printk(KERN_INFO "%lx IFLA_INFO_KIND %s %s\n", dev->rtnl_link_ops, > + dev->rtnl_link_ops->kind, __FUNCTION__); > err = register_netdevice(dev); > rtnl_unlock(); > return err; > diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c > index e476403231f0..e08986ae6238 100644 > --- a/net/core/rtnetlink.c > +++ b/net/core/rtnetlink.c > @@ -520,6 +520,8 @@ static size_t rtnl_link_get_size(const struct > net_device *dev) Google Mail unfortunately wraps lines, so it’s better to attach patches. > if (!ops) > return 0; > > + printk(KERN_INFO "%lx IFLA_INFO_KIND %s %s\n", ops, > + ops->kind, __FUNCTION__); > size = nla_total_size(sizeof(struct nlattr)) + /* IFLA_LINKINFO */ > nla_total_size(strlen(ops->kind) + 1); /* IFLA_INFO_KIND */ > > @@ -1006,6 +1008,9 @@ static size_t rtnl_proto_down_size(const struct > net_device *dev) > static noinline size_t if_nlmsg_size(const struct net_device *dev, > u32 ext_filter_mask) > { > + if (dev->rtnl_link_ops) > + printk(KERN_INFO "%lx IFLA_INFO_KIND %s %s\n", dev->rtnl_link_ops, > + dev->rtnl_link_ops->kind, __FUNCTION__); > return NLMSG_ALIGN(sizeof(struct ifinfomsg)) > + nla_total_size(IFNAMSIZ) /* IFLA_IFNAME */ > + nla_total_size(IFALIASZ) /* IFLA_IFALIAS */ > @@ -3825,7 +3830,9 @@ struct sk_buff *rtmsg_ifinfo_build_skb(int type, > struct net_device *dev, > struct net *net = dev_net(dev); > struct sk_buff *skb; > int err = -ENOBUFS; > - > + if (dev->rtnl_link_ops) > + printk(KERN_INFO "%lx IFLA_INFO_KIND %s %s\n", dev->rtnl_link_ops, > + dev->rtnl_link_ops->kind, __FUNCTION__); > skb = nlmsg_new(if_nlmsg_size(dev, 0), flags); > if (skb == NULL) > goto errout; > @@ -3861,7 +3868,9 @@ static void rtmsg_ifinfo_event(int type, struct > net_device *dev, > > if (dev->reg_state != NETREG_REGISTERED) > return; > - > + if (dev->rtnl_link_ops) > + printk(KERN_INFO "%lx IFLA_INFO_KIND %s %s\n", dev->rtnl_link_ops, > + dev->rtnl_link_ops->kind, __FUNCTION__); > skb = rtmsg_ifinfo_build_skb(type, dev, change, event, flags, new_nsid, > new_ifindex); > if (skb) > @@ -3871,6 +3880,9 @@ static void rtmsg_ifinfo_event(int type, struct > net_device *dev, > void rtmsg_ifinfo(int type, struct net_device *dev, unsigned int change, > gfp_t flags) > { > + if (dev->rtnl_link_ops) > + printk(KERN_INFO "%lx IFLA_INFO_KIND %s %s\n", dev->rtnl_link_ops, > + dev->rtnl_link_ops->kind, __FUNCTION__); > rtmsg_ifinfo_event(type, dev, change, rtnl_get_event(0), flags, > NULL, 0); > } > diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c > index c0b138c20992..fa5b2725811c 100644 > --- a/net/ipv6/sit.c > +++ b/net/ipv6/sit.c > @@ -1919,6 +1919,8 @@ static int __net_init sit_init_net(struct net *net) > * Allowing to move it to another netns is clearly unsafe. > */ > sitn->fb_tunnel_dev->features |= NETIF_F_NETNS_LOCAL; > - > + printk(KERN_INFO "%lx IFLA_INFO_KIND %s %s\n", > + sitn->fb_tunnel_dev->rtnl_link_ops, > + sitn->fb_tunnel_dev->rtnl_link_ops->kind, __FUNCTION__); > err = register_netdev(sitn->fb_tunnel_dev); > if (err) > goto err_reg_dev; Thank you for the diff. I *am* able to reproduce the crash also in a QEMU/KVM virtual machine. config and Linux log is attached. Here is the excerpt with your added messages: ``` $ qemu-system-ppc64 -enable-kvm -nographic -smp cores=1,threads=1 -net none -enable-kvm -M pseries -nodefaults -device spapr-vscsi -serial stdio -m 512 -kernel /dev/shm/linux/vmlinux -append "debug_boot_weak_hash panic=-1 console=ttyS0 rcupdate.rcu_cpu_stall_suppress_at_boot=1 torture.disable_onoff_at_boot rcupdate.rcu_task_stall_timeout=30000 rcupdate.rcu_self_test=1 rcutorture.onoff_interval=1000 rcutorture.onoff_holdoff=30 rcutorture.n_barrier_cbs=4 rcutorture.stat_interval=15 rcutorture.shutdown_secs=420 rcutorture.test_no_idle_hz=1 rcutorture.verbose=1" […] [ 0.445514][ T1] c00000000295c988 IFLA_INFO_KIND ipip register_netdevice [ 0.446330][ T1] c00000000295c988 IFLA_INFO_KIND ipip rtmsg_ifinfo [ 0.447107][ T1] c00000000295c988 IFLA_INFO_KIND ipip rtmsg_ifinfo_event [ 0.447935][ T1] c00000000295c988 IFLA_INFO_KIND ipip rtmsg_ifinfo_build_skb [ 0.448789][ T1] c00000000295c988 IFLA_INFO_KIND ipip if_nlmsg_size [ 0.449563][ T1] c00000000295c988 IFLA_INFO_KIND ipip rtnl_link_get_size [ 0.450497][ T1] NET: Registered PF_INET6 protocol family [ 0.451402][ T1] Segment Routing with IPv6 [ 0.451922][ T1] In-situ OAM (IOAM) with IPv6 [ 0.452480][ T1] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver [ 0.453259][ T1] c00000000295cfd8 IFLA_INFO_KIND (null) sit_init_net [ 0.454035][ T1] c00000000295cfd8 IFLA_INFO_KIND (null) register_netdev [ 0.454939][ T1] c00000000295cfd8 IFLA_INFO_KIND (null) register_netdevice [ 0.455780][ T1] c00000000295cfd8 IFLA_INFO_KIND (null) rtmsg_ifinfo [ 0.456563][ T1] c00000000295cfd8 IFLA_INFO_KIND (null) rtmsg_ifinfo_event [ 0.457409][ T1] c00000000295cfd8 IFLA_INFO_KIND (null) rtmsg_ifinfo_build_skb [ 0.458288][ T1] c00000000295cfd8 IFLA_INFO_KIND (null) if_nlmsg_size [ 0.459085][ T1] c00000000295cfd8 IFLA_INFO_KIND (null) rtnl_link_get_size [ 0.459921][ T1] BUG: Kernel NULL pointer dereference on read at 0x00000000 [ 0.460766][ T1] Faulting instruction address: 0xc00000000090b640 [ 0.461513][ T1] Oops: Kernel access of bad area, sig: 11 [#1] [ 0.462225][ T1] LE PAGE_SIZE=64K MMU=Hash PREEMPT SMP NR_CPUS=16 NUMA pSeries [ 0.463108][ T1] Modules linked in: [ 0.463549][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc4-00219-g43a6dd55dd9d #28 [ 0.464584][ T1] NIP: c00000000090b640 LR: c000000000d9785c CTR: 0000000000000000 [ 0.465499][ T1] REGS: c0000000073e32b0 TRAP: 0380 Not tainted (5.17.0-rc4-00219-g43a6dd55dd9d) [ 0.466581][ T1] MSR: 8000000002009033 CR: 22800c47 XER: 00000000 [ 0.467642][ T1] CFAR: c000000000d97858 IRQMASK: 0 [ 0.467642][ T1] GPR00: c000000000d97850 c0000000073e3550 c000000002919d00 0000000000000000 [ 0.467642][ T1] GPR04: ffffffffffffffff ffffffffff1e7ef8 ffffffffff1e9984 c00000000267ae88 [ 0.467642][ T1] GPR08: 0000000000000003 0000000000000004 c00000000267ae88 0000000000000000 [ 0.467642][ T1] GPR12: 0000000000880000 c000000002ac0000 c000000000012518 0000000000000000 [ 0.467642][ T1] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.467642][ T1] GPR20: 0000000000000000 c00000000281dc00 0000000000000000 0000000000000cc0 [ 0.467642][ T1] GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.467642][ T1] GPR28: c00000000295cfd8 c0000000079d3000 0000000000000000 c0000000073e3550 [ 0.476429][ T1] NIP [c00000000090b640] strlen+0x10/0x30 [ 0.477085][ T1] LR [c000000000d9785c] if_nlmsg_size+0x2dc/0x3b0 [ 0.477822][ T1] Call Trace: [ 0.478190][ T1] [c0000000073e3550] [c000000000d97850] if_nlmsg_size+0x2d0/0x3b0 (unreliable) [ 0.479226][ T1] [c0000000073e3600] [c000000000d9743c] rtmsg_ifinfo_build_skb+0x8c/0x1d0 [ 0.480210][ T1] [c0000000073e36c0] [c000000000d98298] rtmsg_ifinfo+0x88/0x130 [ 0.481086][ T1] [c0000000073e3750] [c000000000d7e118] register_netdevice+0x5c8/0x690 [ 0.482037][ T1] [c0000000073e37e0] [c000000000d7e578] register_netdev+0x58/0xb0 [ 0.482946][ T1] [c0000000073e3850] [c000000000f83ad0] sit_init_net+0x150/0x1a0 [ 0.483838][ T1] [c0000000073e38d0] [c000000000d6469c] ops_init+0x13c/0x1b0 [ 0.484691][ T1] [c0000000073e3930] [c000000000d63c4c] register_pernet_operations+0xec/0x1e0 [ 0.485714][ T1] [c0000000073e3990] [c000000000d63ed0] register_pernet_device+0x60/0xd0 [ 0.486689][ T1] [c0000000073e39e0] [c000000002085228] sit_init+0x54/0x160 [ 0.487530][ T1] [c0000000073e3a70] [c000000000011c58] do_one_initcall+0x108/0x3e0 [ 0.488455][ T1] [c0000000073e3c70] [c000000002006190] do_initcall_level+0xe4/0x1c4 [ 0.489389][ T1] [c0000000073e3cc0] [c00000000200604c] do_initcalls+0x84/0xe4 [ 0.490260][ T1] [c0000000073e3d40] [c000000002005da8] kernel_init_freeable+0x160/0x1ec [ 0.491236][ T1] [c0000000073e3da0] [c00000000001254c] kernel_init+0x3c/0x270 [ 0.492108][ T1] [c0000000073e3e10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64 [ 0.493078][ T1] Instruction dump: [ 0.493509][ T1] eb81ffe0 7c0803a6 4e800020 00000000 00000000 00000000 60000000 60000000 [ 0.494524][ T1] 3883ffff 60000000 60000000 60000000 <8ca40001> 28050000 4082fff8 7c632050 [ 0.495542][ T1] ---[ end trace 0000000000000000 ]--- ``` […] Kind regards, Paul