Re: Setting up systemd throws a fit. Actually any update does the same.
Hello!
On 12/4/20 6:51 AM, Dennis Clarke wrote:
> ceres# apt-get update
> Hit:1 http://deb.debian.org/debian-ports sid InRelease
> Reading package lists... Done
> ceres# apt-get upgrade
> E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to
> correct the problem.
> ceres# dpkg --configure -a
> Setting up apt-utils (2.1.12) ...
> Setting up sntp (1:4.2.8p15+dfsg-1) ...
> Setting up systemd (247.1-2) ...
> [ 1107.427103] systemd[1]: systemd 247.1-2 running in system mode. (+PAM
> +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD -SECCOMP +BLKID +ELFUTILS +KMOD
> +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
> [ 1107.719698] systemd[1]: Detected architecture sparc64.
> [ 1135.085892] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]
> [ 1135.175251] Modules linked in: drm(E) drm_panel_orientation_quirks(E)
> i2c_core(E) sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) configfs(E)
> ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E)
> crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E)
> crct10dif_common(E) ata_generic(E) pata_cmd64x(E) libata(E) sym53c8xx(E)
> scsi_transport_spi(E) sunhme(E) scsi_mod(E)
> [ 1135.643279] CPU: 0 PID: 1 Comm: systemd Tainted: G E
> 5.9.0-2-sparc64 #1 Debian 5.9.6-1
> [ 1135.764572] TSTATE: 0000009911001604 TPC: 00000000008f0260 TNPC:
> 00000000008f0264 Y: 00000000 Tainted: G E
> [ 1135.912246] TPC: <misc_open+0x40/0x180>
> [ 1135.962638] g0: fffff80038781800 g1: 0000000010044830 g2:
> 0000000000000000 g3: 0000000000000002
> [ 1136.077124] g4: fffff8003a171100 g5: 0000000000e47214 g6:
> fffff8003a16c000 g7: 00000000000002c5
> [ 1136.191602] o0: 0000000000e3be08 o1: fffff80037d97a10 o2:
> 0000000000040000 o3: 0000000000000000
> [ 1136.306081] o4: 0000000000000000 o5: 0000000000000000 sp:
> fffff8003a16ef81 ret_pc: 00000000008f0240
> [ 1136.425143] RPC: <misc_open+0x20/0x180>
> [ 1136.475560] l0: 0000000000e3bc00 l1: fffff8003a1a3021 l2:
> 000000036a85ab20 l3: 000000036a85ab20
> [ 1136.590045] l4: 0000000000000470 l5: ffffffffffffff9c l6:
> fffff8003a16c000 l7: 000000000064fa00
> [ 1136.704523] i0: fffff80035194850 i1: fffff80037d97a00 i2:
> 0000000000e3bc00 i3: 0000000000e3be20
> [ 1136.819004] i4: 00000000000000eb i5: 0000000010044818 i6:
> fffff8003a16f031 i7: 0000000000658c98
> [ 1136.933496] I7: <chrdev_open+0x98/0x1e0>
> [ 1136.985044] Call Trace:
> [ 1137.017079] [<0000000000658c98>] chrdev_open+0x98/0x1e0
> [ 1137.085817] [<000000000064da30>] do_dentry_open+0x170/0x420
> [ 1137.159113] [<000000000064f268>] vfs_open+0x28/0x40
> [ 1137.223270] [<0000000000664a88>] path_openat+0x988/0x1100
> [ 1137.294286] [<0000000000667530>] do_filp_open+0x50/0x100
> [ 1137.364156] [<000000000064f510>] do_sys_openat2+0x70/0x180
> [ 1137.436316] [<000000000064fa48>] sys_openat+0x48/0xc0
> [ 1137.502769] [<0000000000406174>] linux_sparc_syscall+0x34/0x44
> ~
> Type 'go' to resume
> ok
>
> No idea what the real problem is ... but if I can dig into it then
> let me know.
Yes, please. I don't have any capacity left on my side and I also don't see
this issues on our newer machines so it might be a bug that affects older
machines only.
It might be the same issue that Meelis has been reporting to the Linux
SPARC kernel mailing list.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: