Re: Regression with 4.7.2 on sun4u

[David Miller]

From: James Clarke 
Date: Fri, 21 Oct 2016 22:52:45 +0100

> This indeed was the case. The attached patch fixes the problem for me,
> generating 0x1062, which gdb can verify is sensible (of course, the
> addresses have shifted slightly):

Please don't use attachments for patch submissions.

Patches must be inline so that they can be commented upon properly
using simply email quoting mechanisms.

Thank you.

Re: Regression with 4.7.2 on sun4u

[James Clarke]

> On 21 Oct 2016, at 18:47, James Clarke  wrote:
>> On 21 Oct 2016, at 18:26, David Miller  wrote:
>> 
>> From: Rob Gardner 
>> Date: Fri, 21 Oct 2016 09:49:30 -0600
>> 
>>> That could be either a stray memory write or a boot time patch gone
>>> wrong.
>> 
>> It could be that we need to use non-predicting branches in the jump
>> label implementation.  We could be overflowing the branch displacement
>> range if the kernel being built is really huge.
>> 
>> Something like the following would fix it if true:
>> 
>> diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c
>> index 59bbeff..841d98e 100644
>> --- a/arch/sparc/kernel/jump_label.c
>> +++ b/arch/sparc/kernel/jump_label.c
>> @@ -19,13 +19,8 @@ void arch_jump_label_transform(struct jump_entry *entry,
>>   if (type == JUMP_LABEL_JMP) {
>>   s32 off = (s32)entry->target - (s32)entry->code;
>> 
>> -#ifdef CONFIG_SPARC64
>> -/* ba,pt %xcc, . + (off << 2) */
>> -val = 0x1068 | ((u32) off >> 2);
>> -#else
>>   /* ba . + (off << 2) */
>>   val = 0x1080 | ((u32) off >> 2);
>> -#endif
>>   } else {
>>   val = 0x0100;
>>   }
>> 
> 
> (Was top-post; moved here)
> 
> Yes, I found that. I don't think its overflowing, more negative (hence the
> 3ff2, which would be f88 or something like that for off). Trying with
> that masked appropriately. If it works I'll send a patch with appropriate
> BUG_ONs.

This indeed was the case. The attached patch fixes the problem for me,
generating 0x1062, which gdb can verify is sensible (of course, the
addresses have shifted slightly):

(gdb) x/10xw 0x5c9880
0x5c9880:   0x400f10d0  0x0100  0x1062  0x0100
0x5c9890:   0x106fffc8  0x0100  0xc611a036  0x05002c36
0x5c98a0:   0x8410a038  0x8328f030
(gdb) x/i 0x5c9888
   0x5c9888:b  %xcc, 0x5c9850
   0x5c988c:nop 

I also took the opportunity to correct the misleading/incorrect comments.
Please let me know if you’d like this properly submitted git-send-email style.

Regards,
James


0001-sparc-Handle-negative-offsets-in-arch_jump_label_tra.patch
Description: Binary data

Re: Regression with 4.7.2 on sun4u

[James Clarke]

(On phone, sorry for top-posting)
Yes, I found that. I don't think its overflowing, more negative (hence the 
3ff2, which would be f88 or something like that for off). Trying with 
that masked appropriately. If it works I'll send a patch with appropriate 
BUG_ONs.

James

> On 21 Oct 2016, at 18:26, David Miller  wrote:
> 
> From: Rob Gardner 
> Date: Fri, 21 Oct 2016 09:49:30 -0600
> 
>> That could be either a stray memory write or a boot time patch gone
>> wrong.
> 
> It could be that we need to use non-predicting branches in the jump
> label implementation.  We could be overflowing the branch displacement
> range if the kernel being built is really huge.
> 
> Something like the following would fix it if true:
> 
> diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c
> index 59bbeff..841d98e 100644
> --- a/arch/sparc/kernel/jump_label.c
> +++ b/arch/sparc/kernel/jump_label.c
> @@ -19,13 +19,8 @@ void arch_jump_label_transform(struct jump_entry *entry,
>if (type == JUMP_LABEL_JMP) {
>s32 off = (s32)entry->target - (s32)entry->code;
> 
> -#ifdef CONFIG_SPARC64
> -/* ba,pt %xcc, . + (off << 2) */
> -val = 0x1068 | ((u32) off >> 2);
> -#else
>/* ba . + (off << 2) */
>val = 0x1080 | ((u32) off >> 2);
> -#endif
>} else {
>val = 0x0100;
>}
> 

Re: Regression with 4.7.2 on sun4u

[David Miller]

From: Rob Gardner 
Date: Fri, 21 Oct 2016 09:49:30 -0600

> That could be either a stray memory write or a boot time patch gone
> wrong.

It could be that we need to use non-predicting branches in the jump
label implementation.  We could be overflowing the branch displacement
range if the kernel being built is really huge.

Something like the following would fix it if true:

diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c
index 59bbeff..841d98e 100644
--- a/arch/sparc/kernel/jump_label.c
+++ b/arch/sparc/kernel/jump_label.c
@@ -19,13 +19,8 @@ void arch_jump_label_transform(struct jump_entry *entry,
if (type == JUMP_LABEL_JMP) {
s32 off = (s32)entry->target - (s32)entry->code;
 
-#ifdef CONFIG_SPARC64
-   /* ba,pt %xcc, . + (off << 2) */
-   val = 0x1068 | ((u32) off >> 2);
-#else
/* ba . + (off << 2) */
val = 0x1080 | ((u32) off >> 2);
-#endif
} else {
val = 0x0100;
}

Re: Regression with 4.7.2 on sun4u

[James Clarke]

> On 21 Oct 2016, at 16:49, Rob Gardner  wrote:
> 
> On 10/21/2016 06:57 AM, Anatoly Pugachev wrote:
>> On Fri, Oct 21, 2016 at 12:12 PM, Anatoly Pugachev  
>> wrote:
>>> On Wed, Sep 7, 2016 at 1:01 PM, Anatoly Pugachev  wrote:
 On Wed, Sep 7, 2016 at 12:22 PM, John Paul Adrian Glaubitz
  wrote:
> Hello!
> 
> After kernel 4.7.2 entered Debian unstable, I decided to upgrade the 
> buildds and ran into an
> apparent regression with the 4.7.x kernels on sun4u machines:
 It's not only with sun4u, we're getting kernel OOPS on sun4v as well:
>>> debian packaged 4.7.6 kernel, machine is a LDOM on T5-2 server, OOPS
>>> after kernel boot within a few minutes:
>> 
>> reproduced with latest git 4.9.0-rc1+ (v4.9-rc1-148-g6f33d645) kernel.
>> Machine boots ok, i can login as unprivileged user (via ssh), compile
>> and install kernel, run sudo, install packages (apt upgrade),
>> apache/mysql and other startup daemons works, but if I try to login as
>> root via ssh, it throws kernel oops / illegal instruction.
>> 
>> Any idea how to debug this?
>> 
>> otherhost$ ssh ttip -l root -v
>> ...
>> debug1: channel 0: new [client-session]
>> debug1: Requesting no-more-sessi...@openssh.com
>> debug1: Entering interactive session.
>> Write failed: Broken pipe
>> $
>> 
>> I can strace -f -p $pid_of_sshd , but not sure it would help.
>> 
>> URL version => http://paste.debian.net/plain/884751
>> kernel config => http://paste.debian.net/plain/884806
>> 
>> NOTICE: Entering OpenBoot.
>> NOTICE: Fetching Guest MD from HV.
>> NOTICE: Starting additional cpus.
>> NOTICE: Initializing LDC services.
>> NOTICE: Probing PCI devices.
>> NOTICE: Finished PCI probing.
>> 
>> SPARC T5-2, No Keyboard
>> Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved.
>> OpenBoot 4.38.5, 32. GB memory available, Serial #83494642.
>> Ethernet address 0:14:4f:fa:6:f2, Host ID: 84fa06f2.
>> 
>> 
>> 
>> Boot device: vdisk1  File and args:
>> SILO Version 1.4.14
>> boot:
>> Allocated 64 Megs of memory at 0x4000 for kernel
>> Uncompressing image...
>> Loaded kernel version 4.9.0
>> Loading initial ramdisk (13616359 bytes at 0x7400 phys, 0x40C0 
>> virt)...
>> 
>> [0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.38.5 2016/06/22 19:36'
>> [0.00] PROMLIB: Root node compatible: sun4v
>> [0.00] Linux version 4.9.0-rc1+ (mator@ttip) (gcc version
>> 6.2.0 20161010 (Debian 6.2.0-6+sparc64) ) #19 SMP Fri Oct 21 14:47:01
>> MSK 2016
>> [0.00] bootconsole [earlyprom0] enabled
>> [0.00] ARCH: SUN4V
>> ... snip ...
>> [5446612.115339] dbus-daemon(521): Kernel illegal instruction [#3]
>> [5446612.115342] CPU: 15 PID: 521 Comm: dbus-daemon Tainted: G  D
>>4.9.0-rc1+ #19
>> [5446612.115347] task: fff800080b331bc0 task.stack: fff80007f937c000
>> [5446612.115349] TSTATE: 004411001606 TPC: 005ccfec TNPC:
>> 005ccff0 Y: Tainted: G  D
>> [5446612.115353] TPC: <__kmalloc_track_caller+0x14c/0x240>
>> [5446612.115355] g0: fff800080fb28b00 g1: 0040 g2:
>>  g3: c000
>> [5446612.115357] g4: fff800080b331bc0 g5: fff800082c5b g6:
>> fff80007f937c000 g7: 3c06
>> [5446612.115358] o0:  o1: 025106c0 o2:
>> 5a5a5a5a o3: fff800080fb28b00
>> [5446612.115360] o4: 5a5a5a5a5a5a5a5a o5: 0028 sp:
>> fff80007f937eda1 ret_pc: 005ccfe4
>> [5446612.115362] RPC: <__kmalloc_track_caller+0x144/0x240>
>> [5446612.115365] l0: fff830402800 l1: 07feffe44e40 l2:
>> 07feffe452b0 l3: 
>> [5446612.115367] l4:  l5: 0020 l6:
>> fff8000100b875c8 l7: fff800010026bf30
>> [5446612.115368] i0: 0240 i1: 025106c0 i2:
>> 00864e00 i3: 025106c0
>> [5446612.115371] i4:  i5: 025106c0 i6:
>> fff80007f937ee51 i7: 00864d40
>> [5446612.115376] I7: <__kmalloc_reserve.isra.5+0x20/0x80>
>> [5446612.115376] Call Trace:
>> [5446612.115378]  [00864d40] __kmalloc_reserve.isra.5+0x20/0x80
>> [5446612.115381]  [00864e00] __alloc_skb+0x60/0x180
>> [5446612.115383]  [00864f68] alloc_skb_with_frags+0x48/0x1c0
>> [5446612.115390]  [0085f54c] sock_alloc_send_pskb+0x1ec/0x220
>> [5446612.115400]  [009367a8] unix_stream_sendmsg+0x228/0x380
>> [5446612.115404]  [00859ddc] sock_sendmsg+0x3c/0x80
>> [5446612.115406]  [0085a810] ___sys_sendmsg+0x250/0x260
>> [5446612.115409]  [0085b794] __sys_sendmsg+0x34/0x80
>> [5446612.115411]  [0085b800] SyS_sendmsg+0x20/0x40
>> [5446612.115415]  [004061f4] linux_sparc_syscall+0x34/0x44
>> [5446612.115417] Caller[00864d40]: __kmalloc_reserve.isra.5+0x20/0x80
>> [5446612.115419] Caller[00864e00]: __alloc_skb+0x60/0x180
>> [5446612.115423] 

Re: Regression with 4.7.2 on sun4u

[Rob Gardner]

On 10/21/2016 06:57 AM, Anatoly Pugachev wrote:

On Fri, Oct 21, 2016 at 12:12 PM, Anatoly Pugachev  wrote:

On Wed, Sep 7, 2016 at 1:01 PM, Anatoly Pugachev  wrote:

On Wed, Sep 7, 2016 at 12:22 PM, John Paul Adrian Glaubitz
 wrote:

Hello!

After kernel 4.7.2 entered Debian unstable, I decided to upgrade the buildds 
and ran into an
apparent regression with the 4.7.x kernels on sun4u machines:

It's not only with sun4u, we're getting kernel OOPS on sun4v as well:

debian packaged 4.7.6 kernel, machine is a LDOM on T5-2 server, OOPS
after kernel boot within a few minutes:


reproduced with latest git 4.9.0-rc1+ (v4.9-rc1-148-g6f33d645) kernel.
Machine boots ok, i can login as unprivileged user (via ssh), compile
and install kernel, run sudo, install packages (apt upgrade),
apache/mysql and other startup daemons works, but if I try to login as
root via ssh, it throws kernel oops / illegal instruction.

Any idea how to debug this?

otherhost$ ssh ttip -l root -v
...
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
Write failed: Broken pipe
$

I can strace -f -p $pid_of_sshd , but not sure it would help.

URL version => http://paste.debian.net/plain/884751
kernel config => http://paste.debian.net/plain/884806

NOTICE: Entering OpenBoot.
NOTICE: Fetching Guest MD from HV.
NOTICE: Starting additional cpus.
NOTICE: Initializing LDC services.
NOTICE: Probing PCI devices.
NOTICE: Finished PCI probing.

SPARC T5-2, No Keyboard
Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved.
OpenBoot 4.38.5, 32. GB memory available, Serial #83494642.
Ethernet address 0:14:4f:fa:6:f2, Host ID: 84fa06f2.



Boot device: vdisk1  File and args:
SILO Version 1.4.14
boot:
Allocated 64 Megs of memory at 0x4000 for kernel
Uncompressing image...
Loaded kernel version 4.9.0
Loading initial ramdisk (13616359 bytes at 0x7400 phys, 0x40C0 virt)...

[0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.38.5 2016/06/22 19:36'
[0.00] PROMLIB: Root node compatible: sun4v
[0.00] Linux version 4.9.0-rc1+ (mator@ttip) (gcc version
6.2.0 20161010 (Debian 6.2.0-6+sparc64) ) #19 SMP Fri Oct 21 14:47:01
MSK 2016
[0.00] bootconsole [earlyprom0] enabled
[0.00] ARCH: SUN4V
[0.00] Ethernet address: 00:14:4f:fa:06:f2
[0.00] MM: PAGE_OFFSET is 0xfff8 (max_phys_bits == 47)
[0.00] MM: VMALLOC [0x0001 --> 0x0006]
[0.00] MM: VMEMMAP [0x0006 --> 0x000c]
[0.00] Kernel: Using 3 locked TLB entries for main kernel image.
[0.00] Remapping the kernel... [0.00] done.
[0.00] OF stdout device is: /virtual-devices@100/console@1
[0.00] PROM: Built device tree with 67418 bytes of memory.
[0.00] MDESC: Size is 29648 bytes.
[0.00] PLATFORM: banner-name [SPARC T5-2]
[0.00] PLATFORM: name [ORCL,SPARC-T5-2]
[0.00] PLATFORM: hostid [84fa06f2]
[0.00] PLATFORM: serial# [0035260e]
[0.00] PLATFORM: stick-frequency [3b9aca00]
[0.00] PLATFORM: mac-address [144ffa06f2]
[0.00] PLATFORM: watchdog-resolution [1000 ms]
[0.00] PLATFORM: watchdog-max-timeout [3153600 ms]
[0.00] PLATFORM: max-cpus [1024]
[0.00] Top of RAM: 0x82f94e000, Total RAM: 0x7ff386000
[0.00] Memory hole size: 773MB
[0.00] Allocated 24576 bytes for kernel page tables.
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x3040-0x00082f94dfff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x3040-0x6feb]
[0.00]   node   0: [mem 0x6ff4-0x6ff47fff]
[0.00]   node   0: [mem 0x7000-0x00082f8b3fff]
[0.00]   node   0: [mem 0x00082f944000-0x00082f94dfff]
[0.00] Initmem setup node 0 [mem 0x3040-0x00082f94dfff]
[0.00] Booting Linux...
[0.00] CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,n2,mul32]
[0.00] CPU CAPS: [div32,v8plus,popc,vis,vis2,ASIBlkInit,fmaf,vis3]
[0.00] CPU CAPS: [hpc,ima,pause,cbcond,aes,des,kasumi,camellia]
[0.00] CPU CAPS: [md5,sha1,sha256,sha512,mpmul,montmul,montsqr,crc32c]
[0.00] percpu: Embedded 10 pages/cpu @fff800082d00 s43096
r8192 d30632 u131072
[0.00] SUN4V: Mondo queue sizes [cpu(131072) dev(16384) r(8192) nr(256)]
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 4155855
[0.00] Kernel command line: root=/dev/vdiska2 ro
zswap.enabled=1 noresume
[0.00] log_buf_len individual max cpu contribution: 4096 bytes
[0.00] log_buf_len total cpu_extra contributions: 1044480 bytes
[0.00] log_buf_len min size: 131072 bytes
[0.00] 

Re: Regression with 4.7.2 on sun4u

[David Miller]

From: Anatoly Pugachev 
Date: Fri, 21 Oct 2016 15:57:16 +0300

> Any idea how to debug this?

Bisection may be the quickest way.

Re: Regression with 4.7.2 on sun4u

[Anatoly Pugachev]

On Fri, Oct 21, 2016 at 12:12 PM, Anatoly Pugachev  wrote:
> On Wed, Sep 7, 2016 at 1:01 PM, Anatoly Pugachev  wrote:
>> On Wed, Sep 7, 2016 at 12:22 PM, John Paul Adrian Glaubitz
>>  wrote:
>>> Hello!
>>>
>>> After kernel 4.7.2 entered Debian unstable, I decided to upgrade the 
>>> buildds and ran into an
>>> apparent regression with the 4.7.x kernels on sun4u machines:
>>
>> It's not only with sun4u, we're getting kernel OOPS on sun4v as well:
>
> debian packaged 4.7.6 kernel, machine is a LDOM on T5-2 server, OOPS
> after kernel boot within a few minutes:


reproduced with latest git 4.9.0-rc1+ (v4.9-rc1-148-g6f33d645) kernel.
Machine boots ok, i can login as unprivileged user (via ssh), compile
and install kernel, run sudo, install packages (apt upgrade),
apache/mysql and other startup daemons works, but if I try to login as
root via ssh, it throws kernel oops / illegal instruction.

Any idea how to debug this?

otherhost$ ssh ttip -l root -v
...
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
Write failed: Broken pipe
$

I can strace -f -p $pid_of_sshd , but not sure it would help.

URL version => http://paste.debian.net/plain/884751
kernel config => http://paste.debian.net/plain/884806

NOTICE: Entering OpenBoot.
NOTICE: Fetching Guest MD from HV.
NOTICE: Starting additional cpus.
NOTICE: Initializing LDC services.
NOTICE: Probing PCI devices.
NOTICE: Finished PCI probing.

SPARC T5-2, No Keyboard
Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved.
OpenBoot 4.38.5, 32. GB memory available, Serial #83494642.
Ethernet address 0:14:4f:fa:6:f2, Host ID: 84fa06f2.



Boot device: vdisk1  File and args:
SILO Version 1.4.14
boot:
Allocated 64 Megs of memory at 0x4000 for kernel
Uncompressing image...
Loaded kernel version 4.9.0
Loading initial ramdisk (13616359 bytes at 0x7400 phys, 0x40C0 virt)...

[0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.38.5 2016/06/22 19:36'
[0.00] PROMLIB: Root node compatible: sun4v
[0.00] Linux version 4.9.0-rc1+ (mator@ttip) (gcc version
6.2.0 20161010 (Debian 6.2.0-6+sparc64) ) #19 SMP Fri Oct 21 14:47:01
MSK 2016
[0.00] bootconsole [earlyprom0] enabled
[0.00] ARCH: SUN4V
[0.00] Ethernet address: 00:14:4f:fa:06:f2
[0.00] MM: PAGE_OFFSET is 0xfff8 (max_phys_bits == 47)
[0.00] MM: VMALLOC [0x0001 --> 0x0006]
[0.00] MM: VMEMMAP [0x0006 --> 0x000c]
[0.00] Kernel: Using 3 locked TLB entries for main kernel image.
[0.00] Remapping the kernel... [0.00] done.
[0.00] OF stdout device is: /virtual-devices@100/console@1
[0.00] PROM: Built device tree with 67418 bytes of memory.
[0.00] MDESC: Size is 29648 bytes.
[0.00] PLATFORM: banner-name [SPARC T5-2]
[0.00] PLATFORM: name [ORCL,SPARC-T5-2]
[0.00] PLATFORM: hostid [84fa06f2]
[0.00] PLATFORM: serial# [0035260e]
[0.00] PLATFORM: stick-frequency [3b9aca00]
[0.00] PLATFORM: mac-address [144ffa06f2]
[0.00] PLATFORM: watchdog-resolution [1000 ms]
[0.00] PLATFORM: watchdog-max-timeout [3153600 ms]
[0.00] PLATFORM: max-cpus [1024]
[0.00] Top of RAM: 0x82f94e000, Total RAM: 0x7ff386000
[0.00] Memory hole size: 773MB
[0.00] Allocated 24576 bytes for kernel page tables.
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x3040-0x00082f94dfff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x3040-0x6feb]
[0.00]   node   0: [mem 0x6ff4-0x6ff47fff]
[0.00]   node   0: [mem 0x7000-0x00082f8b3fff]
[0.00]   node   0: [mem 0x00082f944000-0x00082f94dfff]
[0.00] Initmem setup node 0 [mem 0x3040-0x00082f94dfff]
[0.00] Booting Linux...
[0.00] CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,n2,mul32]
[0.00] CPU CAPS: [div32,v8plus,popc,vis,vis2,ASIBlkInit,fmaf,vis3]
[0.00] CPU CAPS: [hpc,ima,pause,cbcond,aes,des,kasumi,camellia]
[0.00] CPU CAPS: [md5,sha1,sha256,sha512,mpmul,montmul,montsqr,crc32c]
[0.00] percpu: Embedded 10 pages/cpu @fff800082d00 s43096
r8192 d30632 u131072
[0.00] SUN4V: Mondo queue sizes [cpu(131072) dev(16384) r(8192) nr(256)]
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 4155855
[0.00] Kernel command line: root=/dev/vdiska2 ro
zswap.enabled=1 noresume
[0.00] log_buf_len individual max cpu contribution: 4096 bytes
[0.00] log_buf_len total cpu_extra contributions: 1044480 bytes
[0.00] log_buf_len min size: 131072 bytes
[0.00] log_buf_len: 

Re: Regression with 4.7.2 on sun4u

[Anatoly Pugachev]

On Wed, Sep 7, 2016 at 1:01 PM, Anatoly Pugachev  wrote:
> On Wed, Sep 7, 2016 at 12:22 PM, John Paul Adrian Glaubitz
>  wrote:
>> Hello!
>>
>> After kernel 4.7.2 entered Debian unstable, I decided to upgrade the buildds 
>> and ran into an
>> apparent regression with the 4.7.x kernels on sun4u machines:
>
> It's not only with sun4u, we're getting kernel OOPS on sun4v as well:

debian packaged 4.7.6 kernel, machine is a LDOM on T5-2 server, OOPS
after kernel boot within a few minutes:

[  OK  ] Started Update UTMP about System Runlevel Changes.

Debian GNU/Linux stretch/sid ttip console

ttip login: [5435944.506755] systemd-journald[334]: File
/var/log/journal/c02366aaa6e44182ba0caa130d880aac/user-1000.journal
corrupted or uncleanly shut down, renaming and replacing.
[5435988.433976]   \|/  \|/
[5435988.433976]   "@'/ .. \`@"
[5435988.433976]   /_| \__/ |_\
[5435988.433976]  \__U_/
[5435988.434000] systemd(1): Kernel illegal instruction [#1]
[5435988.434008] CPU: 0 PID: 1 Comm: systemd Not tainted
4.7.0-1-sparc64-smp #1 Debian 4.7.6-1
[5435988.434016] task: fff8000815f43620 ti: fff8000815f44000 task.ti:
fff8000815f44000
[5435988.434023] TSTATE: 004411001603 TPC: 005c2a9c TNPC:
005c2aa0 Y: Not tainted
[5435988.434039] TPC: <__kmalloc_track_caller+0x13c/0x200>
[5435988.434044] g0: fff800082c3e6000 g1: 0040 g2:
 g3: 0001
[5435988.434051] g4: fff8000815f43620 g5: fff800082c3e6000 g6:
fff8000815f44000 g7: 00636500
[5435988.434057] o0:  o1: 03ff o2:
 o3: 
[5435988.434063] o4: 00b0d450 o5: 00b0d400 sp:
fff8000815f46f01 ret_pc: 005c2a94
[5435988.434075] RPC: <__kmalloc_track_caller+0x134/0x200>
[5435988.434082] l0: 4000 l1: fff8304020e0 l2:
000612208db8 l3: 
[5435988.434091] l4: fff800082d00de68 l5: 000612208dd8 l6:
 l7: fff8000100e9a000
[5435988.434101] i0: fff8304020e0 i1: 024000c0 i2:
00585ffc i3: 024000c0
[5435988.434110] i4: 000b i5: 024000c0 i6:
fff8000815f46fb1 i7: 00585f88
[5435988.434127] I7: 
[5435988.434132] Call Trace:
[5435988.434140]  [00585f88] kstrdup+0x28/0x60
[5435988.434148]  [00585ffc] kstrdup_const+0x3c/0x60
[5435988.434158]  [00657b10] __kernfs_new_node+0x10/0xc0
[5435988.434165]  [00658d64] kernfs_new_node+0x24/0x60
[5435988.434173]  [0065913c] kernfs_create_dir_ns+0x1c/0x80
[5435988.434182]  [004fb864] cgroup_mkdir+0x1c4/0x2c0
[5435988.434189]  [00658cbc] kernfs_iop_mkdir+0x5c/0xa0
[5435988.434198]  [005e7a78] vfs_mkdir+0xd8/0x160
[5435988.434205]  [005ed4fc] SyS_mkdirat+0xdc/0x160
[5435988.434212]  [005ed598] SyS_mkdir+0x18/0x40
[5435988.434223]  [004061f4] linux_sparc_syscall+0x34/0x44
[5435988.434229] Disabling lock debugging due to kernel taint
[5435988.434237] Caller[00585f88]: kstrdup+0x28/0x60
[5435988.434245] Caller[00585ffc]: kstrdup_const+0x3c/0x60
[5435988.434252] Caller[00657b10]: __kernfs_new_node+0x10/0xc0
[5435988.434259] Caller[00658d64]: kernfs_new_node+0x24/0x60
[5435988.434266] Caller[0065913c]: kernfs_create_dir_ns+0x1c/0x80
[5435988.434273] Caller[004fb864]: cgroup_mkdir+0x1c4/0x2c0
[5435988.434281] Caller[00658cbc]: kernfs_iop_mkdir+0x5c/0xa0
[5435988.434288] Caller[005e7a78]: vfs_mkdir+0xd8/0x160
[5435988.434295] Caller[005ed4fc]: SyS_mkdirat+0xdc/0x160
[5435988.434302] Caller[005ed598]: SyS_mkdir+0x18/0x40
[5435988.434309] Caller[004061f4]: linux_sparc_syscall+0x34/0x44
[5435988.434316] Caller[fff80001001ef870]: 0xfff80001001ef870
[5435988.434322] Instruction DUMP: a018  400eed9b  0100
<3fed> 0100  106fffc3  0100  c611a036  05002be5
[5435988.435227]   \|/  \|/
[5435988.435227]   "@'/ .. \`@"
[5435988.435227]   /_| \__/ |_\
[5435988.435227]  \__U_/
[5435988.435250] systemd(1): Kernel illegal instruction [#2]
[5435988.435259] CPU: 0 PID: 1 Comm: systemd Tainted: G  D
4.7.0-1-sparc64-smp #1 Debian 4.7.6-1
[5435988.435273] task: fff8000815f43620 ti: fff8000815f44000 task.ti:
fff8000815f44000
[5435988.435285] TSTATE: 004411001602 TPC: 005c30a0 TNPC:
005c30a4 Y: 00198519Tainted: G  D
[5435988.435300] TPC: <__kmalloc+0x140/0x200>
[5435988.435309] g0: 00b4bc00 g1: 0040 g2:
 g3: 0800ad84
[5435988.435322] g4: fff8000815f43620 g5: fff800082c3e6000 g6:
fff8000815f44000 g7: 
[5435988.435336] o0:  o1: 03ff o2:
fff800080fd08e80 o3: 
[5435988.435349] o4: fff800081292cb80 o5: fff874278300 sp: