It looks very much like it isn't specifically a kernel bug at all, but either
something
wrong with the Debian kernel config, or with newer gcc versions.
I still think it's a kernel bug.
Very well.
Tracing through all possible kernel config parameters is probably not feasible
anyway.
It's probably due to CONFIG_DEBUG_INFO. Try turning that off. Debian builds the
kernel with debug
symbols enabled and then runs the strip command afterwards. This way both a
debug and a standard
kernel package can be provided from the same build.
Ah thanks, that did the trick.
I built a 6.10.0 kernel using the Debian 6.10.7-sparc64-smp config, with module
signing turned off.
This kernel crashed instantly at boot, just after checking the rootfs. The fsck output
was intermingled with the kernel log, but it did complete with a "done."
Begin: Will now check root file system ... fsck from util-linux 2.38.1
[ 68.420534] \|/ ____ \|/
[ 68.420534] "@'/ .. \`@"
[ 68.420534] /_| \__/ |_\
[ 68.420534] \__U_/
[ 68.630552] mount(192): Kernel illegal instruction [#1]
[ 68.715911] CPU: 0 PID: 192 Comm: mount Tainted: G E 6.10.0
#28
[ 68.828841] TSTATE: 0000000011001605 TPC: 0000000010320158 TNPC:
000000001032015c Y: 00000000 Tainted: G E
[ 68.994452] TPC: <ext4_find_extent+0x3f8/0x580 [ext4]>
[ 69.078729] g0: 0000000000000001 g1: 0000000000010000 g2: 0000000000000000
g3: 0000000000000000
[ 69.209968] g4: fff000100210ac00 g5: fff000103e442000 g6: fff0000000598000
g7: 0000000000000000
[ 69.341210] o0: 0000000000000200 o1: fff00000029cc3e8 o2: 0000000000000001
o3: 00000000103cc1b0
[ 69.472457] o4: 0000000000001678 o5: 000000000000b000 sp: fff000000059a8d1
ret_pc: 0000000000ea309c
[ 69.608287] RPC: <__cond_resched+0x1c/0x60>
[ 69.679947] l0: fff0000000d06416 l1: fff00000029cc128 l2: 0000000100010000
l3: 0000000000ffffff
[ 69.811203] l4: 0000000000000000 l5: 0000000000000005 l6: 0000000000010001
l7: 0000000000000002
[ 69.942448] i0: 0000000000010001 i1: 0000000000000000 i2: 0000000000000000
i3: 0000000000000000
[ 70.070570] i4: 0000000000000000 i5: 0000000000000001 i6: fff000000059a9a1
i7: 0000000010325748
[ 70.185151] I7: <ext4_ext_map_blocks+0x68/0x2060 [ext4]>
[ 70.255147] Call Trace:
[ 70.287221] [<0000000010325748>] ext4_ext_map_blocks+0x68/0x2060 [ext4]
[ 70.374417] [<000000001033ee38>] ext4_map_blocks+0x98/0x6c0 [ext4]
[ 70.455872] [<000000001033fd34>] ext4_iomap_begin+0x254/0x2e0 [ext4]
[ 70.539621] [<00000000007f494c>] iomap_iter+0x14c/0x420
[ 70.608470] [<00000000007fa5f0>] iomap_bmap+0x70/0xe0
[ 70.674929] [<000000001033bd3c>] ext4_bmap+0x9c/0xe0 [ext4]
[ 70.748366] [<0000000000789404>] bmap+0x24/0x40
[ 70.808051] [<00000000102d7e54>] jbd2_journal_init_inode+0x14/0x120 [jbd2]
[ 70.898675] [<0000000010385c2c>] ext4_load_and_init_journal+0xec/0xd20 [ext4]
[ 70.992740] [<000000001038bd78>] ext4_fill_super+0x2638/0x2aa0 [ext4]
[ 71.077631] [<000000000076ae5c>] get_tree_bdev+0xfc/0x1c0
[ 71.148774] [<0000000010377c34>] ext4_get_tree+0x14/0x40 [ext4]
[ 71.226799] [<000000000076b4c0>] vfs_get_tree+0x20/0x120
[ 71.296792] [<0000000000796f0c>] path_mount+0x40c/0xa60
[ 71.365539] [<0000000000797a94>] sys_mount+0xf4/0x1c0
[ 71.431997] [<0000000000406274>] linux_sparc_syscall+0x34/0x44
I'll try a bisect with that config now, perhaps I can find something.
