I am not so sure about this yet until I can rebuild the required grub
binaries with full debug info. For at least a year ( or more ) I have
seen "really bad things"(tm) happen when I try to make a new initrd on
sparc64. Generally the machine seems to pack up and go away with nary a
single packet out to the world. To look into this problem I use a serial attached good old 9600 baud console and watch what happens when I try to
do a make install from within the Linux source tree :


root@hades:~# [80684.783560] watchdog: BUG: soft lockup - CPU#0 stuck
for 26s! [grub-probe:47798]
[80684.880888] Modules linked in: sg(E) envctrl(E) display7seg(E)
flash(E) fuse(E) drm(E) drm_panel_orientation_quirks(E) i2c_core(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) sym53c8xx(E)
scsi_transport_spi(E) scsi_mod(E) scsi_common(E) sunhme(E)
[80685.320414] CPU: 0 PID: 47798 Comm: grub-probe Tainted: G
E 5.16.0-6-sparc64 #1 Debian 5.16.18-1
[80685.454308] TSTATE: 0000000011001607 TPC: 00000000009555d0 TNPC: 00000000009555d4 Y: 00000000 Tainted: G E
[80685.601952] TPC: <misc_open+0x50/0x180>
[80685.652373] g0: 0000000000000000 g1: 0000000000000098 g2:
0000000000000000 g3: 000000000714ebe0
[80685.766856] g4: fffff8000137ae40 g5: 0000000062462570 g6:
fffff800097a8000 g7: 0000000000a88958
[80685.881335] o0: 0000000000fa7a08 o1: fffff800097ab8ec o2:
fffff800002f72d0 o3: 0000000000000001
[80685.995814] o4: fffff8000087f968 o5: 0000000000000000 sp:
fffff800097aaf81 ret_pc: 00000000009555a0
[80686.114867] RPC: <misc_open+0x20/0x180>
[80686.165292] l0: fffff800001b9800 l1: 0000000000fa7800 l2:
0000000000685d20 l3: 00000006dc08077e
[80686.279793] l4: 0000000000000470 l5: ffffffffffffff9c l6:
fffff800097a8000 l7: 000000000067e1a0
[80686.394261] i0: fffff8000087f968 i1: fffff80001121960 i2:
0000000000fa7800 i3: 0000000000fa7a20
[80686.508740] i4: 00000000000000ec i5: 0000000010074830 i6:
fffff800097ab031 i7: 0000000000686958
[80686.623218] I7: <chrdev_open+0x98/0x1c0>
[80686.674783] Call Trace:
[80686.706910] [<0000000000686958>] chrdev_open+0x98/0x1c0
[80686.775642] [<000000000067bef0>] do_dentry_open+0x170/0x420
[80686.848946] [<000000000067da08>] vfs_open+0x28/0x40
[80686.913099] [<0000000000693500>] path_openat+0xb20/0x10e0
[80686.984115] [<00000000006948c0>] do_filp_open+0x60/0x100
[80687.053986] [<000000000067dcf0>] do_sys_openat2+0x70/0x180
[80687.126146] [<000000000067e1e8>] sys_openat+0x48/0xc0
[80687.192588] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [80708.777890] watchdog: BUG: soft lockup - CPU#0 stuck for 48s! [grub-probe:47798]
[80708.875209] Modules linked in: sg(E) envctrl(E) display7seg(E)
flash(E) fuse(E) drm(E) drm_panel_orientation_quirks(E) i2c_core(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) sym53c8xx(E)
scsi_transport_spi(E) scsi_mod(E) scsi_common(E) sunhme(E)
[80709.314756] CPU: 0 PID: 47798 Comm: grub-probe Tainted: G
EL 5.16.0-6-sparc64 #1 Debian 5.16.18-1
[80709.448637] TSTATE: 0000000011001607 TPC: 00000000009555d0 TNPC: 00000000009555d4 Y: 00000000 Tainted: G EL
[80709.596283] TPC: <misc_open+0x50/0x180>
[80709.646701] g0: 0000000000000000 g1: 0000000000000098 g2:
0000000000000000 g3: 000000000714ebe0
[80709.761187] g4: fffff8000137ae40 g5: 0000000062462570 g6:
fffff800097a8000 g7: 0000000000a88958
[80709.875665] o0: 0000000000fa7a08 o1: fffff800097ab8ec o2:
fffff800002f72d0 o3: 0000000000000001
[80709.990145] o4: fffff8000087f968 o5: 0000000000000000 sp:
fffff800097aaf81 ret_pc: 00000000009555a0
[80710.109199] RPC: <misc_open+0x20/0x180>
[80710.159618] l0: fffff800001b9800 l1: 0000000000fa7800 l2:
0000000000685d20 l3: 00000006dc08077e
[80710.274105] l4: 0000000000000470 l5: ffffffffffffff9c l6:
fffff800097a8000 l7: 000000000067e1a0
[80710.388583] i0: fffff8000087f968 i1: fffff80001121960 i2:
0000000000fa7800 i3: 0000000000fa7a20
[80710.503061] i4: 00000000000000ec i5: 0000000010074830 i6:
fffff800097ab031 i7: 0000000000686958
[80710.617539] I7: <chrdev_open+0x98/0x1c0>
[80710.669104] Call Trace:
[80710.701126] [<0000000000686958>] chrdev_open+0x98/0x1c0
[80710.769859] [<000000000067bef0>] do_dentry_open+0x170/0x420
[80710.843164] [<000000000067da08>] vfs_open+0x28/0x40
[80710.907316] [<0000000000693500>] path_openat+0xb20/0x10e0
[80710.978333] [<00000000006948c0>] do_filp_open+0x60/0x100
[80711.048204] [<000000000067dcf0>] do_sys_openat2+0x70/0x180
[80711.120364] [<000000000067e1e8>] sys_openat+0x48/0xc0
[80711.186805] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [80732.772223] watchdog: BUG: soft lockup - CPU#0 stuck for 71s! [grub-probe:47798]
[80732.869531] Modules linked in: sg(E) envctrl(E) display7seg(E)
flash(E) fuse(E) drm(E) drm_panel_orientation_quirks(E) i2c_core(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) sym53c8xx(E)
scsi_transport_spi(E) scsi_mod(E) scsi_common(E) sunhme(E)
[80733.309077] CPU: 0 PID: 47798 Comm: grub-probe Tainted: G
EL 5.16.0-6-sparc64 #1 Debian 5.16.18-1
[80733.442959] TSTATE: 0000000011001607 TPC: 00000000009555d0 TNPC: 00000000009555d4 Y: 00000000 Tainted: G EL
[80733.590605] TPC: <misc_open+0x50/0x180>
[80733.641023] g0: 0000000000000000 g1: 0000000000000098 g2:
0000000000000000 g3: 000000000714ebe0
[80733.755510] g4: fffff8000137ae40 g5: 0000000062462570 g6:
fffff800097a8000 g7: 0000000000a88958
[80733.869989] o0: 0000000000fa7a08 o1: fffff800097ab8ec o2:
fffff800002f72d0 o3: 0000000000000001
[80733.984466] o4: fffff8000087f968 o5: 0000000000000000 sp:
fffff800097aaf81 ret_pc: 00000000009555a0
[80734.103520] RPC: <misc_open+0x20/0x180>
[80734.153941] l0: fffff800001b9800 l1: 0000000000fa7800 l2:
0000000000685d20 l3: 00000006dc08077e
[80734.268427] l4: 0000000000000470 l5: ffffffffffffff9c l6:
fffff800097a8000 l7: 000000000067e1a0
[80734.382906] i0: fffff8000087f968 i1: fffff80001121960 i2:
0000000000fa7800 i3: 0000000000fa7a20
[80734.497385] i4: 00000000000000ec i5: 0000000010074830 i6:
fffff800097ab031 i7: 0000000000686958
[80734.611862] I7: <chrdev_open+0x98/0x1c0>
[80734.663427] Call Trace:
[80734.695450] [<0000000000686958>] chrdev_open+0x98/0x1c0
[80734.764181] [<000000000067bef0>] do_dentry_open+0x170/0x420
[80734.837487] [<000000000067da08>] vfs_open+0x28/0x40
[80734.901639] [<0000000000693500>] path_openat+0xb20/0x10e0
[80734.972655] [<00000000006948c0>] do_filp_open+0x60/0x100
[80735.042528] [<000000000067dcf0>] do_sys_openat2+0x70/0x180
[80735.114688] [<000000000067e1e8>] sys_openat+0x48/0xc0
[80735.181128] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [80756.766556] watchdog: BUG: soft lockup - CPU#0 stuck for 93s! [grub-probe:47798]
[80756.863855] Modules linked in: sg(E) envctrl(E) display7seg(E)
flash(E) fuse(E) drm(E) drm_panel_orientation_quirks(E) i2c_core(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) sym53c8xx(E)
scsi_transport_spi(E) scsi_mod(E) scsi_common(E) sunhme(E)
[80757.303402] CPU: 0 PID: 47798 Comm: grub-probe Tainted: G
EL 5.16.0-6-sparc64 #1 Debian 5.16.18-1
[80757.437285] TSTATE: 0000000011001607 TPC: 00000000009555d0 TNPC: 00000000009555d4 Y: 00000000 Tainted: G EL
[80757.584931] TPC: <misc_open+0x50/0x180>
[80757.635347] g0: 0000000000000000 g1: 0000000000000098 g2:
0000000000000000 g3: 000000000714ebe0
[80757.749835] g4: fffff8000137ae40 g5: 0000000062462570 g6:
fffff800097a8000 g7: 0000000000a88958
[80757.864314] o0: 0000000000fa7a08 o1: fffff800097ab8ec o2:
fffff800002f72d0 o3: 0000000000000001
[80757.978791] o4: fffff8000087f968 o5: 0000000000000000 sp:
fffff800097aaf81 ret_pc: 00000000009555a0
[80758.097845] RPC: <misc_open+0x20/0x180>
[80758.148266] l0: fffff800001b9800 l1: 0000000000fa7800 l2:
0000000000685d20 l3: 00000006dc08077e
[80758.262753] l4: 0000000000000470 l5: ffffffffffffff9c l6:
fffff800097a8000 l7: 000000000067e1a0
[80758.377230] i0: fffff8000087f968 i1: fffff80001121960 i2:
0000000000fa7800 i3: 0000000000fa7a20
[80758.491708] i4: 00000000000000ec i5: 0000000010074830 i6:
fffff800097ab031 i7: 0000000000686958
[80758.606188] I7: <chrdev_open+0x98/0x1c0>
[80758.657750] Call Trace:
[80758.689774] [<0000000000686958>] chrdev_open+0x98/0x1c0
[80758.758506] [<000000000067bef0>] do_dentry_open+0x170/0x420
[80758.831810] [<000000000067da08>] vfs_open+0x28/0x40
[80758.895962] [<0000000000693500>] path_openat+0xb20/0x10e0
[80758.966979] [<00000000006948c0>] do_filp_open+0x60/0x100
[80759.036852] [<000000000067dcf0>] do_sys_openat2+0x70/0x180
[80759.109012] [<000000000067e1e8>] sys_openat+0x48/0xc0
[80759.175453] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [80780.760889] watchdog: BUG: soft lockup - CPU#0 stuck for 115s! [grub-probe:47798]
[80780.859325] Modules linked in: sg(E) envctrl(E) display7seg(E)
flash(E) fuse(E) drm(E) drm_panel_orientation_quirks(E) i2c_core(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) sym53c8xx(E)
scsi_transport_spi(E) scsi_mod(E) scsi_common(E) sunhme(E)
[80781.298872] CPU: 0 PID: 47798 Comm: grub-probe Tainted: G
EL 5.16.0-6-sparc64 #1 Debian 5.16.18-1
[80781.432753] TSTATE: 0000009911001607 TPC: 00000000009555c0 TNPC: 00000000009555c4 Y: 00000000 Tainted: G EL
[80781.580400] TPC: <misc_open+0x40/0x180>
[80781.630818] g0: 0000000000000000 g1: 0000000010074848 g2:
0000000000000000 g3: 000000000714ebe0
[80781.745304] g4: fffff8000137ae40 g5: 0000000062462570 g6:
fffff800097a8000 g7: 0000000000a88958
[80781.859782] o0: 0000000000fa7a08 o1: fffff800097ab8ec o2:
fffff800002f72d0 o3: 0000000000000001
[80781.974261] o4: fffff8000087f968 o5: 0000000000000000 sp:
fffff800097aaf81 ret_pc: 00000000009555a0
[80782.093315] RPC: <misc_open+0x20/0x180>
[80782.143735] l0: fffff800001b9800 l1: 0000000000fa7800 l2:
0000000000685d20 l3: 00000006dc08077e
[80782.258222] l4: 0000000000000470 l5: ffffffffffffff9c l6:
fffff800097a8000 l7: 000000000067e1a0
[80782.372700] i0: fffff8000087f968 i1: fffff80001121960 i2:
0000000000fa7800 i3: 0000000000fa7a20
[80782.487179] i4: 00000000000000ec i5: 0000000010074830 i6:
fffff800097ab031 i7: 0000000000686958
[80782.601657] I7: <chrdev_open+0x98/0x1c0>
[80782.653220] Call Trace:
[80782.685244] [<0000000000686958>] chrdev_open+0x98/0x1c0
[80782.753977] [<000000000067bef0>] do_dentry_open+0x170/0x420
[80782.827280] [<000000000067da08>] vfs_open+0x28/0x40
[80782.891434] [<0000000000693500>] path_openat+0xb20/0x10e0
[80782.962449] [<00000000006948c0>] do_filp_open+0x60/0x100
[80783.032322] [<000000000067dcf0>] do_sys_openat2+0x70/0x180
[80783.104482] [<000000000067e1e8>] sys_openat+0x48/0xc0
[80783.170923] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [80804.755221] watchdog: BUG: soft lockup - CPU#0 stuck for 138s! [grub-probe:47798]

So then. That is what I call "really bad". There is nothing I can do
other than to fire a BREAK over the serial lines to the console and drop
the machine to firmware prompt. Nasty.

Once the machine gathers its wits and stands up once again with a
running situation I dig into what is really going on. We have a nifty
script called /usr/sbin/grub-mkconfig that does a whack of stuff but
certainly it runs /usr/sbin/grub-probe very early and gathers some
information therein.

We see these lines :

# Device containing our userland. Typically used for root= parameter. GRUB_DEVICE="`${grub_probe} --target=device /`" GRUB_DEVICE_UUID="`${grub_probe} --device ${GRUB_DEVICE}
--target=fs_uuid 2> /dev/null`" || true
GRUB_DEVICE_PARTUUID="`${grub_probe} --device ${GRUB_DEVICE}
--target=partuuid 2> /dev/null`" || true


Well at the very least we can run /usr/sbin/grub-probe with command line parameters "--target=device /" :


oot@hades:~# TERM=dumb LC_ALL=C /usr/bin/gdb -q /usr/sbin/grub-probe
Reading symbols from /usr/sbin/grub-probe...
Download failed: Function not implemented. Continuing without debug
info for /usr/sbin/grub-probe.
(No debugging symbols found in /usr/sbin/grub-probe)
(gdb) run --target=device /
Starting program: /usr/sbin/grub-probe --target=device /
Download failed: Function not implemented. Continuing without debug
info for /lib/sparc64-linux-gnu/libdevmapper.so.1.02.1.
Download failed: Function not implemented. Continuing without debug
info for /lib/sparc64-linux-gnu/libselinux.so.1.
Download failed: Function not implemented. Continuing without debug
info for /lib/sparc64-linux-gnu/libudev.so.1.
Download failed: Function not implemented. Continuing without debug
info for /lib/sparc64-linux-gnu/libblkid.so.1.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1". Download failed: Function not implemented. Continuing without debug
info for /lib/sparc64-linux-gnu/libpcre2-8.so.0.
/dev/sda4
[Inferior 1 (process 416) exited normally]
(gdb) quit
root@hades:~#


OKay that works. Yes /dev/sda4 seems correct. I see :

root@hades:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 485M 0 485M 0% /dev
tmpfs 100M 752K 99M 1% /run
/dev/sda4 11G 1.6G 8.8G 16% /
tmpfs 497M 0 497M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/sda1 1.9G 106M 1.7G 6% /boot
/dev/sda5 3.6G 44K 3.4G 1% /home
/dev/sda6 15G 2.9G 12G 20% /usr/local
root@hades:~#

The next line in the script /usr/sbin/grub-mkconfig fires off this :


# /usr/sbin/grub-probe --device /dev/sda4 --target=fs_uuid


The machine never recovers from that. Very bad things happen.

To demonstrate :


root@hades:~# TERM=dumb LC_ALL=C /usr/bin/gdb -q /usr/sbin/grub-probe
Reading symbols from /usr/sbin/grub-probe...
Download failed: Function not implemented. Continuing without debug
info for /usr/sbin/grub-probe.
(No debugging symbols found in /usr/sbin/grub-probe)
(gdb) run --device /dev/sda4 --target=fs_uuid
Starting program: /usr/sbin/grub-probe --device /dev/sda4 --target=fs_uuid Download failed: Function not implemented. Continuing without debug
info for /lib/sparc64-linux-gnu/libdevmapper.so.1.02.1.
Download failed: Function not implemented. Continuing without debug
info for /lib/sparc64-linux-gnu/libselinux.so.1.
Download failed: Function not implemented. Continuing without debug
info for /lib/sparc64-linux-gnu/libudev.so.1.
Download failed: Function not implemented. Continuing without debug
info for /lib/sparc64-linux-gnu/libblkid.so.1.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1". Download failed: Function not implemented. Continuing without debug
info for /lib/sparc64-linux-gnu/libpcre2-8.so.0.
[16160.118042] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [grub-probe:422]
[16160.213138] Modules linked in: sg(E) envctrl(E) display7seg(E)
flash(E) fuse(E) drm(E) drm_panel_orientation_quirks(E) i2c_core(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) sym53c8xx(E)
scsi_transport_spi(E) scsi_mod(E) scsi_common(E) sunhme(E)
[16160.652768] CPU: 0 PID: 422 Comm: grub-probe Tainted: G E
5.16.0-6-sparc64 #1 Debian 5.16.18-1
[16160.784374] TSTATE: 0000009911001602 TPC: 00000000009555c0 TNPC: 00000000009555c4 Y: 00000000 Tainted: G E
[16160.932019] TPC: <misc_open+0x40/0x180>
[16160.982440] g0: 0000000000000000 g1: 0000000010074848 g2:
0000000000000000 g3: 000000000745f218
[16161.096924] g4: fffff8000070b780 g5: 000000006247619b g6:
fffff80007270000 g7: 0000000000a2db10
[16161.211402] o0: 0000000000fa7a08 o1: fffff800072738ec o2:
fffff800002f63d0 o3: 0000000000000001
[16161.325882] o4: fffff800008db6a0 o5: 0000000000000000 sp:
fffff80007272f81 ret_pc: 00000000009555a0
[16161.444935] RPC: <misc_open+0x20/0x180>
[16161.495359] l0: fffff800001b8000 l1: 0000000000fa7800 l2:
0000000000685d20 l3: 00000006b480d616
[16161.609863] l4: 0000000000000470 l5: ffffffffffffff9c l6:
fffff80007270000 l7: 000000000067e1a0
[16161.724329] i0: fffff800008db6a0 i1: fffff80004829ce0 i2:
0000000000fa7800 i3: 0000000000fa7a20
[16161.838808] i4: 00000000000000ec i5: 0000000010074830 i6:
fffff80007273031 i7: 0000000000686958
[16161.953287] I7: <chrdev_open+0x98/0x1c0>
[16162.004852] Call Trace:
[16162.036979] [<0000000000686958>] chrdev_open+0x98/0x1c0
[16162.105711] [<000000000067bef0>] do_dentry_open+0x170/0x420
[16162.179015] [<000000000067da08>] vfs_open+0x28/0x40
[16162.243168] [<0000000000693500>] path_openat+0xb20/0x10e0
[16162.314185] [<00000000006948c0>] do_filp_open+0x60/0x100
[16162.384057] [<000000000067dcf0>] do_sys_openat2+0x70/0x180
[16162.456217] [<000000000067e1e8>] sys_openat+0x48/0xc0
[16162.522657] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [16184.112473] watchdog: BUG: soft lockup - CPU#0 stuck for 48s! [grub-probe:422]
[16184.207504] Modules linked in: sg(E) envctrl(E) display7seg(E)
flash(E) fuse(E) drm(E) drm_panel_orientation_quirks(E) i2c_core(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) sym53c8xx(E)
scsi_transport_spi(E) scsi_mod(E) scsi_common(E) sunhme(E)
[16184.647054] CPU: 0 PID: 422 Comm: grub-probe Tainted: G EL
5.16.0-6-sparc64 #1 Debian 5.16.18-1
[16184.778649] TSTATE: 0000009911001602 TPC: 00000000009555c0 TNPC: 00000000009555c4 Y: 00000000 Tainted: G EL
[16184.926296] TPC: <misc_open+0x40/0x180>
[16184.976713] g0: 0000000000000000 g1: 0000000010074848 g2:
0000000000000000 g3: 000000000745f218
[16185.091200] g4: fffff8000070b780 g5: 000000006247619b g6:
fffff80007270000 g7: 0000000000a2db10
[16185.205678] o0: 0000000000fa7a08 o1: fffff800072738ec o2:
fffff800002f63d0 o3: 0000000000000001
[16185.320157] o4: fffff800008db6a0 o5: 0000000000000000 sp:
fffff80007272f81 ret_pc: 00000000009555a0
[16185.439210] RPC: <misc_open+0x20/0x180>
[16185.489632] l0: fffff800001b8000 l1: 0000000000fa7800 l2:
0000000000685d20 l3: 00000006b480d616
[16185.604118] l4: 0000000000000470 l5: ffffffffffffff9c l6:
fffff80007270000 l7: 000000000067e1a0
[16185.718596] i0: fffff800008db6a0 i1: fffff80004829ce0 i2:
0000000000fa7800 i3: 0000000000fa7a20
[16185.833075] i4: 00000000000000ec i5: 0000000010074830 i6:
fffff80007273031 i7: 0000000000686958
[16185.947553] I7: <chrdev_open+0x98/0x1c0>
[16185.999117] Call Trace:
[16186.031141] [<0000000000686958>] chrdev_open+0x98/0x1c0
[16186.099874] [<000000000067bef0>] do_dentry_open+0x170/0x420
[16186.173178] [<000000000067da08>] vfs_open+0x28/0x40
[16186.237331] [<0000000000693500>] path_openat+0xb20/0x10e0
[16186.308347] [<00000000006948c0>] do_filp_open+0x60/0x100
[16186.378220] [<000000000067dcf0>] do_sys_openat2+0x70/0x180
[16186.450380] [<000000000067e1e8>] sys_openat+0x48/0xc0
[16186.516820] [<0000000000406174>] linux_sparc_syscall+0x34/0x44


So therefore I think that there is a bug in /usr/sbin/grub-probe and it
really kills the whole "make install" process from within the Linux
kernel source tree or any other way you choose to run it.

Has anyone else seen this ?


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/1/22 22:03, Stan Johnson wrote:

Hi Dennis,

Unless you already know that your system's memory is ok...

Sparc machines generally have ECC memory and the diagnostics are quite
well trusted.

However ... just for giggles ( yes the battery is crap ) :


root@hades:~#
root@hades:~# shutdown -h 'now'
root@hades:~# [ OK ] Removed slic Stopping Rescue Shell...
Stopping Load/Save Random Seed...
[ OK ] Stopped Rescue Shell.
[ OK ] Stopped target System Initialization.
[ OK ] Unset automount Arbitrary b&s File System Automount Point.
[ OK ] Stopped target Local Encrypted Volumes.
[ OK ] Stopped Dispatch Password b&ts to Console Directory Watch.
[ OK ] Stopped target Local Integrity Protected Volumes.
[ OK ] Stopped target Swaps.
[ OK ] Stopped target Local Verity Protected Volumes.
Deactivating swap /dev/disb&_3CD0ZHE200007120K5BC-part2...
Stopping Record System Boot/Shutdown in UTMP...
[ OK ] Deactivated swap /dev/diskb&00:01:02.0-scsi-0:0:0:0-part2.
[ OK ] Deactivated swap /dev/diskb&6G_3CD0ZHE200007120K5BC-part2.
[ OK ] Deactivated swap /dev/sda2.
[ OK ] Stopped ifup for eth0.
[ OK ] Stopped Load/Save Random Seed.
[ OK ] Deactivated swap /dev/diskb&2-e35a-4ff4-b7f5-f7d028c4ca2c.
[ OK ] Stopped Record System Boot/Shutdown in UTMP.
[ OK ] Stopped Apply Kernel Variables.
[ OK ] Stopped Load Kernel Modules.
[ OK ] Stopped Create Volatile Files and Directories.
[ OK ] Stopped target Local File Systems.
Unmounting /boot...
Unmounting /home...
Unmounting /run/credentials/systemd-sysusers.service...
Unmounting /usr/local...
[ OK ] Unmounted /boot.
[ OK ] Unmounted /home.
[ OK ] Unmounted /run/credentials/systemd-sysusers.service.
[ OK ] Unmounted /usr/local.
[ OK ] Reached target Unmount All Filesystems.
[ OK ] Stopped File System Check b&6-88fb-4134-88c5-485c34d4614c.
[ OK ] Stopped File System Check b&f-421e-477d-b5e3-830365a86b19.
[ OK ] Stopped File System Check b&9-00f1-497b-8b83-d726e914d044.
[ OK ] Removed slice Slice /system/systemd-fsck.
[ OK ] Stopped target Preparation for Local File Systems.
[ OK ] Stopped Create Static Device Nodes in /dev.
[ OK ] Stopped Create System Users.
[ OK ] Stopped Remount Root and Kernel File Systems.
[ OK ] Reached target System Shutdown.
[ OK ] Reached target Late Shutdown Services.
[ OK ] Finished System Power Off.
[ OK ] Reached target System Power Off.
[ 4732.049137] systemd-shutdown[1]: Syncing filesystems and block devices.
[ 4732.541119] systemd-shutdown[1]: Sending SIGTERM to remaining
processes...
[ 4732.650924] systemd-journald[183]: Received SIGTERM from PID 1 (systemd-shutdow).
[ 4732.886493] systemd-shutdown[1]: Sending SIGKILL to remaining
processes...
[ 4732.995664] systemd-shutdown[1]: Unmounting file systems.
[ 4733.075318] [308]: Remounting '/' read-only with options 'errors=remount-ro'.
[ 4733.223777] EXT4-fs (sda4): re-mounted. Opts: errors=remount-ro.
Quota mode: none.
[ 4733.335759] systemd-shutdown[1]: All filesystems unmounted.
[ 4733.409207] systemd-shutdown[1]: Deactivating swaps.
[ 4733.474932] systemd-shutdown[1]: All swaps deactivated.
[ 4733.543741] systemd-shutdown[1]: Detaching loop devices.
[ 4733.614459] systemd-shutdown[1]: All loop devices detached.
[ 4733.687858] systemd-shutdown[1]: Stopping MD devices.
[ 4733.755436] systemd-shutdown[1]: All MD devices stopped.
[ 4733.825318] systemd-shutdown[1]: Detaching DM devices.
[ 4733.893652] systemd-shutdown[1]: All DM devices detached.
[ 4733.964778] systemd-shutdown[1]: All filesystems, swaps, loop
devices, MD devices and DM devices detached.
[ 4734.136742] systemd-shutdown[1]: Syncing filesystems and block devices.
[ 4734.227936] systemd-shutdown[1]: Powering off.
[ 4734.286653] sd 0:0:1:0: [sdb] Synchronizing SCSI cache
[ 4734.354622] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 4734.423032] reboot: Power down

LOM event: power off


Get a coffee or whiskey or both and let the electrons settle...



LOM event: power on

ps/2 kbd check: 0000.0000.0000.00fe
Checking Sun KB Done
%o0 = 0000.0000.0055.4001

Executing Power On SelfTest


SPARCengine(tm)Ultra CP 1500 POST 1.17 ME created 03/06/00
WARRNING: NVRAM battery is either bad or just replaced!
Time Stamp [hour:min:sec] 33:30:02

Init POST BSS
Init System BSS

Probing system keyboard : Done
DMMU TLB Tags
DMMU TLB Tag Access Test
DMMU TLB RAM
DMMU TLB RAM Access Test
Ecache Tests
Probe Ecache
ecache_size = 0x00200000
Ecache RAM Addr Test
Ecache Tag Addr Test
Ecache RAM Test
Ecache Tag Test
Invalidate Ecache Tags
All CPU Basic Tests
V9 Instruction Test
CPU Tick and Tick Compare Reg Test
CPU Soft Trap Test
CPU Softint Reg and Int Test
All Basic MMU Tests
DMMU Primary Context Reg Test
DMMU Secondary Context Reg Test
DMMU TSB Reg Test
DMMU Tag Access Reg Test
DMMU VA Watchpoint Reg Test
DMMU PA Watchpoint Reg Test
IMMU TSB Reg Test
IMMU Tag Access Reg Test
IMMU TLB RAM Access Test
IMMU TLB Tag Access Test
All Basic Cache Tests
Dcache RAM Test
Dcache Tag Test
Icache RAM Test
Icache Tag Test
Icache Next Test
Icache Predecode Test
UltraSPARC IIi MCU Control & Status Regs Init and Tests
Init UltraSPARC IIi MCU Control & Status Regs
CPU speed : 440 Mhz, mc1 set : 0x544cb9dd
Memory Probe and Init
Probe Memory
INFO: All the memory Group in 10 bit column mode
Group 0: 256MB
Group 1: 256MB
Group 2: 256MB
Group 3: 256MB
Malloc Post Memory
Init Post Memory
..........
Memory Addr w/ Ecache
Map PROM/STACK/NVRAM in DMMU
Load Post In Memory
Run POST from MEM
..........
loaded POST in memory
Update Master Stack/Frame Pointers
All FPU Basic Tests
FPU Regs Test
FPU State Reg Test
FPU Functional Test
FPU Trap Test
Memory Tests
Init Memory
...............
................
................
................
................
................
................
................
Memory Addr w/ Ecache Test
ECC Memory Addr Test
Block Memory Addr Test
Block Memory Test
...............
...............

................
................

................
................

................
................

................
................

................
................

................
................

................
................

ECC Blk Memory Test
...............
...............

................
................

................
................

................
................

................
................

................
................

................
................

................
................

All Basic UltraSPARC IIi PBM Tests
Init UltraSPARC IIi PBM
PIO Decoder and BCT Test
PCI Byte Enable Test
UltraSPARC IIi IOMMU Regs Test
UltraSPARC IIi IOMMU RAM NTA Test
UltraSPARC IIi IOMMU CAM NTA Test
UltraSPARC IIi IOMMU RAM Address Test
UltraSPARC IIi IOMMU CAM Address Test
IOMMU TLB Compare Test
IOMMU TLB Flush Test
PBM Control/Status Reg Test
PBM Diag Reg Test
UltraSPARC IIi PBM Regs Test
All Advanced CPU Tests
DMMU Hit/Miss Test
DMMU Little Endian Test
IU ASI Access Test
FPU ASI Access Test
Ecache Thrash Test
All CPU Error Reporting Tests
CPU Addr Align Trap Test
DMMU Access Priv Page Test
DMMU Write Protected Page Test
All Advanced UltraSPARC IIi PBM Tests
Init UltraSPARC IIi PBM
Consist DMA Wr, IOMMU hit Ebus Test
All Basic Cheerio Tests
Cheerio Ebus PCI Config Space Test
Cheerio Ethernet PCI Config Space Test
Cheerio Ebus Engine Reg Test
Cheerio Init
All Basic I2c Tests
Init i2c bus
Thermister Reading Test
Thermister Position Readings (in Hex)
CPU 0x4e
All Basic PCI-PCI Bridge Tests
PCI-PCI Bridge Config Space Test
All Basic Symbios 875 SCSI controller Tests
Symbios 875 SCSI controller PCI Config Space Test

Extended POST:
Start Extended POST : No EXT POST is found


Power On Selftest Completed
Status = 0000.0000.0000.0000 ffff.ffff.f100.1db0 019f.3333.3a50.0011

Software Power ON

@(#) SPARCengine(tm)Ultra CP 1500 3.10.27 ME created 2000/06/22 16:45
Enter Checking KB
ps/2 kbd check: 0000.0000.0000.00fe
Checking Sun KB
Clearing E$ Tags Done
Clearing I/D TLBs Done
Probing Memory
Group Info[0000.0000.0000.0003] : 0000.0000.0000.0110
Group Info[0000.0000.0000.0002] : 0000.0000.0000.0110
Group Info[0000.0000.0000.0001] : 0000.0000.0000.0110
Group Info[0000.0000.0000.0000] : 0000.0000.0000.0110
Done
Clearing Memory...Done
MEM BASE = 0000.0000.3800.0000
MEM SIZE = 0000.0000.0800.0000
MMUs ON
Copy Done
PC = 0000.01ff.f000.30dc
PC = 0000.0000.0000.3120
Decompressing into Memory Done
Size = 0000.0000.0008.7710
ttya initialized
flashprom flashprom Incorrect configuration checksum;
Setting NVRAM parameters to default values.
Setting diag-switch? NVRAM parameter to true
Reset Control: BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0
UltraSPARC-IIi Version 9.1 (E$=2 MB) 2-2 module
Advanced PCI Bridge Version 1.3
Probing Memory Group #0 128 + 128 : 256 Megabytes
Probing Memory Group #1 128 + 128 : 256 Megabytes
Probing Memory Group #2 128 + 128 : 256 Megabytes
Probing Memory Group #3 128 + 128 : 256 Megabytes
Initialise 2nd I2c controller
Environmental monitoring: Enabled
i2c adc gpio gpio
i2c Probing Floppy: No drives detected
Probing /pci@1f,0/pci@1,1 at Device 1 network
Probing /pci@1f,0/pci@1,1 at Device 2 scsi disk tape
Probing /pci@1f,0/pci@1,1 at Device 3 network
Probing /pci@1f,0/pci@1 at Device 1 pci
Probing /pci@1f,0/pci@1/pci@1 at Device 0 Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device 1 Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device 2 Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device 3 Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device 4 Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device 5 Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device 6 Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device 7 Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device 8 Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device 9 Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device a Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device b Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device c Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device d Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device e Nothing there
Probing /pci@1f,0/pci@1/pci@1 at Device f Nothing there

Netra t1 (UltraSPARC-IIi 440MHz), No Keyboard
OpenBoot 3.10.27 ME, 1024 MB memory installed, Serial #12731976.
Ethernet address 8:0:20:c2:46:48, Host ID: 80c24648.



Boot device: net File and args:
Using External Transceiver - Link Up.
3a000
Server IP address: 172.16.35.58
Client IP address: 172.16.35.33
Using External Transceiver - Link Up.
ramdisk-root |

Well at this point the machine will try to boot the diag-device which is
simply "net" and yes the machine can netboot fine. That works.

I will break and stop it and then boot local linux and we get a machine
with well tested ECC memory.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Dennis!

On 4/2/22 03:34, Dennis Clarke wrote:

I am not so sure about this yet until I can rebuild the required grub binaries with full debug info. For at least a year ( or more ) I have
seen "really bad things"(tm) happen when I try to make a new initrd on sparc64. Generally the machine seems to pack up and go away with nary a single packet out to the world. To look into this problem I use a serial attached good old 9600 baud console and watch what happens when I try to
do a make install from within the Linux source tree :
(...)
So therefore I think that there is a bug in /usr/sbin/grub-probe and it really kills the whole "make install" process from within the Linux
kernel source tree or any other way you choose to run it.

Has anyone else seen this ?

This isn't a bug in GRUB but a kernel bug that affects older SPARC machines like your UltraSPARC IIIi. Unfortunately, no one has had the time yet to bisect this issue.

But since you seem to have a reliable reproducer, you can start trying to bisect
the kernel to find the commit that introduced this regression.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/2/22 03:30, John Paul Adrian Glaubitz wrote:

Hello Dennis!

On 4/2/22 03:34, Dennis Clarke wrote:

I am not so sure about this yet until I can rebuild the required grub
binaries with full debug info. For at least a year ( or more ) I have
seen "really bad things"(tm) happen when I try to make a new initrd on
sparc64. Generally the machine seems to pack up and go away with nary a
single packet out to the world. To look into this problem I use a serial
attached good old 9600 baud console and watch what happens when I try to
do a make install from within the Linux source tree :
(...)
So therefore I think that there is a bug in /usr/sbin/grub-probe and it
really kills the whole "make install" process from within the Linux
kernel source tree or any other way you choose to run it.

Has anyone else seen this ?

This isn't a bug in GRUB but a kernel bug that affects older SPARC machines like your UltraSPARC IIIi. Unfortunately, no one has had the time yet to bisect
this issue.

But since you seem to have a reliable reproducer, you can start trying to bisect
the kernel to find the commit that introduced this regression.

That will be nearly impossible. I can not even recall when the bug first appeared or when was the last time that I could run update-grub without
the machine locking up. At least two years now. Maybe three.

Also this is an even older UltraSparc IIi type machine. Really I should
have tossed it out long ago but the next machine I have handy is a
Fujitsu M3000 unit and I thought I had heard it was impossible to get
Linux on such a beast for unknown reasons. Could be myth or rumour but I thought the M3000 was somehow "special". The larger M4000 seems to be
fine but those are just nasty large beasts to run in a home lab.

Dragging the deep waters looking for that kernel bug will take a lot of
time. Possibly even some luck.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello!

On 4/3/22 13:42, Dennis Clarke wrote:

But since you seem to have a reliable reproducer, you can start trying to bisect
the kernel to find the commit that introduced this regression.

That will be nearly impossible. I can not even recall when the bug first appeared or when was the last time that I could run update-grub without
the machine locking up. At least two years now. Maybe three.

What do you mean is impossible? Bisecting the bug or the fact that it is
a kernel bug? I know very well it's a kernel bug because it does not occur
when using the 4.19 kernel on any of the affected SPARCs and it does not
occur on any of the newer SPARCs with a current kernel.

The SPARC T2 and T5 we are using don't have the problem at all, for example.

Also this is an even older UltraSparc IIi type machine. Really I should
have tossed it out long ago but the next machine I have handy is a
Fujitsu M3000 unit and I thought I had heard it was impossible to get
Linux on such a beast for unknown reasons. Could be myth or rumour but I thought the M3000 was somehow "special". The larger M4000 seems to be
fine but those are just nasty large beasts to run in a home lab.

Dragging the deep waters looking for that kernel bug will take a lot of
time. Possibly even some luck.

Not really. You cross-build the kernel, transfer it to the machine and see if update-grub works. If it doesn't, you mark the commit as bad. If it does, you mark the commit as good. You start from a good known working kernel such as 4.19.

But I can do it myself if I find the time, I have an Ultra 45 that can be used for that. Thought it would just be nice if I can get a helping hand, especially since cross-compiling and bisecting the kernel isn't really hard, it just takes time.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/3/22 07:57, John Paul Adrian Glaubitz wrote:

Hello!

On 4/3/22 13:42, Dennis Clarke wrote:

But since you seem to have a reliable reproducer, you can start trying to bisect
the kernel to find the commit that introduced this regression.

That will be nearly impossible. I can not even recall when the bug first
appeared or when was the last time that I could run update-grub without
the machine locking up. At least two years now. Maybe three.

What do you mean is impossible? Bisecting the bug or the fact that it is
a kernel bug? I know very well it's a kernel bug because it does not occur when using the 4.19 kernel on any of the affected SPARCs and it does not occur on any of the newer SPARCs with a current kernel.

Are you sure of 4.19 ? I see that 4.19.237 exists but I will guess the
same bug exists there also. I was going to begin with 4.19.114 which was released 02-Apr-2020. A solid two years ago seems like as good a place
to start as any. However building the kernel will require that I create
an initrd and also update grub etc etc. I can do that manually and then
bypass the "update-grub" process entirely.

The SPARC T2 and T5 we are using don't have the problem at all, for example.

Also this is an even older UltraSparc IIi type machine. Really I should
have tossed it out long ago but the next machine I have handy is a
Fujitsu M3000 unit and I thought I had heard it was impossible to get
Linux on such a beast for unknown reasons. Could be myth or rumour but I
thought the M3000 was somehow "special". The larger M4000 seems to be
fine but those are just nasty large beasts to run in a home lab.

Dragging the deep waters looking for that kernel bug will take a lot of
time. Possibly even some luck.

Not really. You cross-build the kernel, transfer it to the machine and see if update-grub works.

Hold on. This sounds like a chicken and egg scenario. The update-grub
will fail every time. I will need to do the process by hand with an edit
to grub.cfg and with the files needed dropped into /boot with the few
kernel modules needed in /lib/modules/foo. That should be enough to at
least boot.

But I can do it myself if I find the time, I have an Ultra 45 that can be used
for that. Thought it would just be nice if I can get a helping hand, especially
since cross-compiling and bisecting the kernel isn't really hard, it just takes
time.

Right. The one thing that no one can save or store or get more. Time.

I have already started the process but I am starting with 4.19.114.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I am curious if you can get the linux-4.19.114 kernel to compile.  For
me it just blows up with :

.
.
.
arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name': arch/sparc/kernel/mdesc.c:648:22: error: 'strcmp' reading 1 or more
bytes from a region of size 0 [-Werror=stringop-overread]
  648 |                 if (!strcmp(names + ep[ret].name_offset, name))
      |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc' of size 16
   78 |         struct mdesc_hdr        mdesc;
      |                                 ^~~~~
arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property': arch/sparc/kernel/mdesc.c:693:22: error: 'strcmp' reading 1 or more
bytes from a region of size 0 [-Werror=stringop-overread]
  693 |                 if (!strcmp(names + ep->name_offset, name)) {
      |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc' of size 16
   78 |         struct mdesc_hdr        mdesc;
      |                                 ^~~~~
arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc': arch/sparc/kernel/mdesc.c:720:21: error: 'strcmp' reading 1 or more
bytes from a region of size 0 [-Werror=stringop-overread]
  720 |                 if (strcmp(names + ep->name_offset, arc_type))
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc' of size 16
   78 |         struct mdesc_hdr        mdesc;
      |                                 ^~~~~
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:304: arch/sparc/kernel/mdesc.o]
Error 1
make[1]: *** [scripts/Makefile.build:544: arch/sparc/kernel] Error 2
make: *** [Makefile:1053: arch/sparc] Error 2

Not sure what to make of that.

Drat :

https://github.com/torvalds/linux/commit/fc7c028dcdbfe981bca75d2a7b95f363eb691ef3


So something after 4.19.114 may work.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/3/22 10:39, Stan Johnson wrote:

Hello Adrian and Dennis,

If this problem is expected to occur on an Ultra 5 or an Ultra 30,
please let me know and I'll be happy to help with a git bisect, using a
spare 9 GB disk for the installation.

The Ultra 5 is even older. At least I think so. There were two flavours
of those bizarre PC style machines where one was a tower looking thing
called the Ultra 10 and it could have a Creator3D OpenGL hardware frame
buffer whereas the Ultra 5 was a modified weird pizza box thing. Both
are from well before the UltraSparc III existed.

Please feel free to jump in.

I am curious if you can get the linux-4.19.114 kernel to compile. For
me it just blows up with :

.
.
.
arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name': arch/sparc/kernel/mdesc.c:648:22: error: 'strcmp' reading 1 or more
bytes from a region of size 0 [-Werror=stringop-overread]
648 | if (!strcmp(names + ep[ret].name_offset, name))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object
'mdesc' of size 16
78 | struct mdesc_hdr mdesc;
| ^~~~~
arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property': arch/sparc/kernel/mdesc.c:693:22: error: 'strcmp' reading 1 or more
bytes from a region of size 0 [-Werror=stringop-overread]
693 | if (!strcmp(names + ep->name_offset, name)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object
'mdesc' of size 16
78 | struct mdesc_hdr mdesc;
| ^~~~~
arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc': arch/sparc/kernel/mdesc.c:720:21: error: 'strcmp' reading 1 or more
bytes from a region of size 0 [-Werror=stringop-overread]
720 | if (strcmp(names + ep->name_offset, arc_type))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object
'mdesc' of size 16
78 | struct mdesc_hdr mdesc;
| ^~~~~
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:304: arch/sparc/kernel/mdesc.o] Error 1 make[1]: *** [scripts/Makefile.build:544: arch/sparc/kernel] Error 2
make: *** [Makefile:1053: arch/sparc] Error 2


Not sure what to make of that.

My intuition here tells me the bug is likely in
arch/sparc/kernel/syscalls.S which changed slightly since the 4.19.114
days. Looking
previous I see no change in that source file. Regardless, this is just a
hunch without a shred of proof. Yet.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Stan!

On 4/3/22 16:39, Stan Johnson wrote:

If this problem is expected to occur on an Ultra 5 or an Ultra 30,
please let me know and I'll be happy to help with a git bisect, using a
spare 9 GB disk for the installation.

I think you should see the issue on both the Ultra 5 and Ultra 30.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/3/22 14:23, Dennis Clarke wrote:

Are you sure of 4.19 ? I see that 4.19.237 exists but I will guess the
same bug exists there also. I was going to begin with 4.19.114 which was released 02-Apr-2020. A solid two years ago seems like as good a place
to start as any. However building the kernel will require that I create
an initrd and also update grub etc etc. I can do that manually and then bypass the "update-grub" process entirely.

Of course, there is a kernel 4.19 tag:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/refs/tags

4.19.114 an LTS release of the 4.19.x series, you don't need it. Just use Linus'
tree and start bisecting between 4.19 and HEAD.

# git bisect start
# git bisect good 4.19
# git bisect bad HEAD

then compile and test. Mark good commits with "git bisect good", bad ones with "git bisect bad".

Not really. You cross-build the kernel, transfer it to the machine and see if
update-grub works.

Hold on. This sounds like a chicken and egg scenario. The update-grub
will fail every time. I will need to do the process by hand with an edit
to grub.cfg and with the files needed dropped into /boot with the few
kernel modules needed in /lib/modules/foo. That should be enough to at
least boot.

Well, that depends where update-grub fails. If it leaves a broken GRUB configuration
behind, it will be a bit tricky. But if it already fails before writing anything to
disk, you should be safe.

I have already started the process but I am starting with 4.19.114.

That makes no sense. You're not on Linus' tree but on the stable tree.

Stable: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Linus' tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

It makes no sense to test the stable tree since the different stable versions lie on different branches, so you will never see the regression in the first place.

You must Linus' tree since that's the only tree with a linear history.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/3/22 17:19, Dennis Clarke wrote:

I am curious if you can get the linux-4.19.114 kernel to compile. For me it just blows up with :

.
.
.
arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name': arch/sparc/kernel/mdesc.c:648:22: error: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
648 | if (!strcmp(names + ep[ret].name_offset, name))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc' of size 16
78 | struct mdesc_hdr mdesc;
| ^~~~~
arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property': arch/sparc/kernel/mdesc.c:693:22: error: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
693 | if (!strcmp(names + ep->name_offset, name)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc' of size 16
78 | struct mdesc_hdr mdesc;
| ^~~~~
arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc': arch/sparc/kernel/mdesc.c:720:21: error: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
720 | if (strcmp(names + ep->name_offset, arc_type))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc' of size 16
78 | struct mdesc_hdr mdesc;
| ^~~~~
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:304: arch/sparc/kernel/mdesc.o] Error 1 make[1]: *** [scripts/Makefile.build:544: arch/sparc/kernel] Error 2
make: *** [Makefile:1053: arch/sparc] Error 2

Not sure what to make of that.

Well, it's up right there, you are building with -Werror enabled. You have to disable that.

My intuition here tells me the bug is likely in arch/sparc/kernel/syscalls.S which changed slightly since the 4.19.114 days. Looking
previous I see no change in that source file. Regardless, this is just a hunch without a shred of proof. Yet.

There is no bug. Just your compiler set to treat warning as errors as can be seen
from the error message above. You have to disable CONFIG_WERROR.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/3/22 23:54, Dennis Clarke wrote:

No, I am not. I am going with whatever is in the Makefile.

https://github.com/torvalds/linux/commit/fc7c028dcdbfe981bca75d2a7b95f363eb691ef3

So this was seen before regardless.

Please just follow my advise and use Linus' tree and don't use any LTS kernels which may have some changes from the latest kernels backported.

I know that cross-compiling and bisecting works 100%, so we really don't need to
argue about this. You didn't find some hidden bug that the daily CI hasn't caught.

The kernel developers are regularly rebuilding the kernel for most targets with all the various standard kernel configuration presets, so it's extremely unlikely
that you run a kernel that won't compile due to a bug.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/3/22 12:13, John Paul Adrian Glaubitz wrote:

On 4/3/22 17:19, Dennis Clarke wrote:

I am curious if you can get the linux-4.19.114 kernel to compile. For me it just blows up with :

.
.
.
arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name':
arch/sparc/kernel/mdesc.c:648:22: error: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
648 | if (!strcmp(names + ep[ret].name_offset, name))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc' of size 16
78 | struct mdesc_hdr mdesc;
| ^~~~~
arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property':
arch/sparc/kernel/mdesc.c:693:22: error: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
693 | if (!strcmp(names + ep->name_offset, name)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc' of size 16
78 | struct mdesc_hdr mdesc;
| ^~~~~
arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc':
arch/sparc/kernel/mdesc.c:720:21: error: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
720 | if (strcmp(names + ep->name_offset, arc_type))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc' of size 16
78 | struct mdesc_hdr mdesc;
| ^~~~~
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:304: arch/sparc/kernel/mdesc.o] Error 1 >> make[1]: *** [scripts/Makefile.build:544: arch/sparc/kernel] Error 2
make: *** [Makefile:1053: arch/sparc] Error 2


Not sure what to make of that.

Well, it's up right there, you are building with -Werror enabled. You have to disable that.

No, I am not. I am going with whatever is in the Makefile.

https://github.com/torvalds/linux/commit/fc7c028dcdbfe981bca75d2a7b95f363eb691ef3

So this was seen before regardless.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I have working Ultra 5 if it is of any help…..

root@xray:/boot/grub# uname -a
Linux xray 5.10.0-8-sparc64 #1 Debian 5.10.46-4 (2021-08-03) sparc64 GNU/Linux

On Apr 3, 2022, at 8:28 PM, Stan Johnson <userm57@yahoo.com> wrote:

On 4/3/22 11:04 AM, John Paul Adrian Glaubitz wrote:

Hi Stan!

On 4/3/22 16:39, Stan Johnson wrote:

If this problem is expected to occur on an Ultra 5 or an Ultra 30,
please let me know and I'll be happy to help with a git bisect, using a
spare 9 GB disk for the installation.

I think you should see the issue on both the Ultra 5 and Ultra 30.
...

I wasn't able to get my Ultra 5 working; the video signal kept cycling
on and off for some reason, and the CD drive wasn't seen, though it was
seen well enough to boot the installation and get to the point where it
said no CD drive was found.

But I was able to confirm that the "grub-probe" bug doesn't seem to
affect the Ultra 30.

root@xray:/boot/grub# /sbin/grub-probe --target=drive --device /dev/sda1 (hostdisk//dev/sda,sun1)

-----

There were a few oddities, but only #6 is serious (apparently a libc
bug, not a kernel bug).

1) I see that /dev/sda1 is mounted as /boot, not /boot/grub. So all the kernels will end up in /dev/sda1. I haven't tested how (or whether) that
will affect kernels for other operating systems (e.g. Gentoo).

2) Please confirm that grub-install never needs to be run. It appears
not to be needed, since update-grub updates /boot/grub/grub.cfg directly.

3) At system boot, when GRUB runs, it complains that it is out of
memory, but it seems to work anyway.

4) During installation, the disk partitioner said "The disk has 562253 cylinders which is greater than the maximum of 65536.", but that error
didn't seem to affect anything.

All 4 of the above have also been witnessed on my machine.

6) In Xfce, a login at the console worked once, but it is now failing consistently (even after a reboot), with this error message in dmesg:

xfce4-session[3980]: segfault at 0 ip fffff8010263c9b4 (rpc
fffff801020efbb8) sp 000007feff8dc451 error 1 in libc-2.33.so[fffff801025b0000+164000]

I’m using lightdm and it seems to be fine. But support for the graphics card is lacking as explained on other emails to this list.

mgt@xray:~$ inxi -G
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] RV100 [Radeon 7000 / Radeon VE] driver: radeonfb v: N/A
Display: server: X.org 1.20.11 driver: loaded: ati,fbdev unloaded: modesetting,radeon tty: 138x43
Message: Advanced graphics data unavailable in console. Try -G --display







<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><span style="font-size: 14px;" class="">I have working Ultra 5 if
it is of any help…..</span><div class=""><span style="font-size: 14px;" class=""><br class=""></span></div><div class=""><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-
ligatures; font-size: 14px;" class="">root@xray:/boot/grub# uname -a</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures; font-size: 14px;" class="">Linux xray
5.10.0-8-sparc64 #1 Debian 5.10.46-4 (2021-08-03) sparc64 GNU/Linux</span></div><div><span style="font-size: 14px;" class=""><br class=""></span><blockquote type="cite" class=""><div class=""><span style="font-size: 14px;" class="">On Apr 3, 2022, at 8:
28 PM, Stan Johnson &lt;<a href="mailto:userm57@yahoo.com" class="">userm57@yahoo.com</a>&gt; wrote:</span></div><span style="font-size: 14px;" class=""><br class="Apple-interchange-newline"></span><div class=""><div class=""><span style="font-size: 14px;
" class="">On 4/3/22 11:04 AM, John Paul Adrian Glaubitz wrote:<br class=""></span><blockquote type="cite" class=""><span style="font-size: 14px;" class="">Hi Stan!<br class=""><br class="">On 4/3/22 16:39, Stan Johnson wrote:<br class=""></span><
blockquote type="cite" class=""><span style="font-size: 14px;" class="">If this problem is expected to occur on an Ultra 5 or an Ultra 30,<br class="">please let me know and I'll be happy to help with a git bisect, using a<br class="">spare 9 GB disk for
the installation.<br class=""></span></blockquote><span style="font-size: 14px;" class=""><br class="">I think you should see the issue on both the Ultra 5 and Ultra 30.<br class="">...<br class=""></span></blockquote><span style="font-size: 14px;" class=
""><br class="">I wasn't able to get my Ultra 5 working; the video signal kept cycling<br class="">on and off for some reason, and the CD drive wasn't seen, though it was<br class="">seen well enough to boot the installation and get to the point where it<
br class="">said no CD drive was found.<br class=""><br class="">But I was able to confirm that the "grub-probe" bug doesn't seem to<br class="">affect the Ultra 30.<br class=""></span></div></div></blockquote><div><span style="font-size: 14px;" class="">
<br class=""></span></div><div><span style="font-size: 14px;" class=""><br class=""></span></div><div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures; font-size: 14px;"
class="">root@xray:/boot/grub# /sbin/grub-probe --target=drive --device /dev/sda1</span></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures; font-size: 14px;" class=
"">(hostdisk//dev/sda,sun1)</span></div></div><span style="font-size: 14px;" class=""><br class=""></span><blockquote type="cite" class=""><div class=""><div class=""><span style="font-size: 14px;" class=""><br class=""><br class="">-----<br class=""><br
class="">There were a few oddities, but only #6 is serious (apparently a libc<br class="">bug, not a kernel bug).<br class=""><br class="">1) I see that /dev/sda1 is mounted as /boot, not /boot/grub. So all the<br class="">kernels will end up in /dev/
sda1. I haven't tested how (or whether) that<br class="">will affect kernels for other operating systems (e.g. Gentoo).<br class=""><br class="">2) Please confirm that grub-install never needs to be run. It appears<br class="">not to be needed, since
update-grub updates /boot/grub/grub.cfg directly.<br class=""><br class="">3) At system boot, when GRUB runs, it complains that it is out of<br class="">memory, but it seems to work anyway.<br class=""><br class="">4) During installation, the disk
partitioner said "The disk has 562253<br class="">cylinders which is greater than the maximum of 65536.", but that error<br class="">didn't seem to affect anything.<br class=""></span></div></div></blockquote><div><span style="font-size: 14px;" class=""><
br class=""></span></div><div><span style="font-size: 14px;" class=""><br class=""></span></div><div><span style="font-size: 14px;" class="">All 4 of the above have also been witnessed on my machine.</span></div><span style="font-size: 14px;" class=""><
br class=""></span><blockquote type="cite" class=""><div class=""><div class=""><span style="font-size: 14px;" class=""><br class="">6) In Xfce, a login at the console worked once, but it is now failing<br class="">consistently (even after a reboot),
with this error message in dmesg:<br class=""><br class="">xfce4-session[3980]: segfault at 0 ip fffff8010263c9b4 (rpc<br class="">fffff801020efbb8) sp 000007feff8dc451 error 1 in<br class="">libc-2.33.so[fffff801025b0000+164000]<br class=""></span></div>
</div></blockquote></div><span style="font-size: 14px;" class=""><br class=""></span></div><div class=""><span style="font-size: 14px;" class="">I’m using lightdm and it seems to be fine. But support for the&nbsp;graphics card is lacking as explained
on other emails to this list.</span></div><div class=""><span style="font-size: 14px;" class=""><br class=""></span></div><div class=""><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><span style="font-size: 14px;" class=""><
span style="font-variant-ligatures: no-common-ligatures; color: #2fb41d" class=""><b class="">mgt@xray</b></span><span style="font-variant-ligatures: no-common-ligatures" class="">:</span><span style="font-variant-ligatures: no-common-ligatures; color: #
400bd9" class=""><b class="">~</b></span><span style="font-variant-ligatures: no-common-ligatures" class="">$ inxi -G</span></span></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><span style="font-size: 14px;" class="">
<span style="font-variant-ligatures: no-common-ligatures; color: #400bd9" class=""><b class="">Graphics:&nbsp; Device-1:</b></span><span style="font-variant-ligatures: no-common-ligatures" class=""> Advanced Micro Devices [AMD/ATI] RV100 [Radeon 7000 /
Radeon VE] </span><span style="font-variant-ligatures: no-common-ligatures; color: #400bd9" class=""><b class="">driver:</b></span><span style="font-variant-ligatures: no-common-ligatures" class=""> radeonfb </span><span style="font-variant-ligatures: no-
common-ligatures; color: #400bd9" class=""><b class="">v:</b></span><span style="font-variant-ligatures: no-common-ligatures" class=""> N/A&nbsp;</span></span></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><span style=
"font-size: 14px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span><span style="font-variant-ligatures: no-common-ligatures; color: #400bd9" class=""><b class="">Display:</b></
span><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #400bd9" class=""><b class="">server:</b></span><span style="font-variant-ligatures: no-common-ligatures"
class=""> <a href="http://X.org" class="">X.org</a> 1.20.11 </span><span style="font-variant-ligatures: no-common-ligatures; color: #400bd9" class=""><b class="">driver:</b></span><span style="font-variant-ligatures: no-common-ligatures" class=""> </span>
<span style="font-variant-ligatures: no-common-ligatures; color: #400bd9" class=""><b class="">loaded:</b></span><span style="font-variant-ligatures: no-common-ligatures" class=""> ati,fbdev </span><span style="font-variant-ligatures: no-common-ligatures;
color: #400bd9" class=""><b class="">unloaded:</b></span><span style="font-variant-ligatures: no-common-ligatures" class=""> modesetting,radeon </span><span style="font-variant-ligatures: no-common-ligatures; color: #400bd9" class=""><b class="">tty:</b>
</span><span style="font-variant-ligatures: no-common-ligatures" class=""> 138x43&nbsp;</span></span></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><span style="font-size: 14px;" class=""><span style="font-variant-
ligatures: no-common-ligatures" class="">&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span><span style="font-variant-ligatures: no-common-ligatures; color: #400bd9" class=""><b class="">Message:</b></span><span style="font-variant-ligatures: no-common-
ligatures" class=""> Advanced graphics data unavailable in console. Try -G --display&nbsp;</span></span></div></div><div class=""><span style="font-variant-ligatures: no-common-ligatures; font-size: 14px;" class=""><br class=""></span></div><div class="">
<span style="font-variant-ligatures: no-common-ligatures; font-size: 14px;" class=""><br class=""></span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures; font-size: 14px;" class=""><br class=""></span></div><div class=""><
span style="font-size: 14px;" class=""><br class=""></span></div><div class=""><span style="font-size: 14px;" class=""><br class=""></span></div><div class=""><br class=""></div></body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)