On Tue, Apr 18, 2023 at 02:21:04PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.15.108 release. There are 91 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 20 Apr 2023 12:02:44 +0000. Anything received after that time might be too late.
Build results: total: 160 pass: 146 fail: 14 Failed builds: alpha:allmodconfig arm:omap2plus_defconfig arm:vexpress_defconfig arm64:defconfig i386:defconfig ia64:defconfig mips:defconfig parisc:allmodconfig parisc64:generic-64bit_defconfig powerpc:defconfig powerpc:ppc64e_defconfig powerpc:cell_defconfig s390:defconfig x86_64:defconfig Qemu test results: total: 499 pass: 452 fail: 47 Failed tests: mipsel64:64r6el_defconfig:notests:nonet:smp:ide:hd mipsel64:64r6el_defconfig:notests:nonet:smp:ide:hd mipsel64:64r6el_defconfig:notests:nonet:smp:ide:cd <all riscv32, riscv64, s390>
Build failures:
kernel/cgroup/cpuset.c: In function 'cpuset_can_fork': kernel/cgroup/cpuset.c:2979:30: error: 'cgroup_mutex' undeclared
riscv32/riscv64 images crash.
[ 0.000000] Linux version 5.15.108-rc1-00092-g0b6a5617247c (groeck@server.roeck-us.net) (riscv32-linux-gcc (GCC) 11.3.0, GNU ld (GNU Binutils) 2.39) #1 SMP Tue Apr 18 14:19:32 PDT 2023 [ 0.000000] random: crng init done [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000 [ 0.000000] Machine model: riscv-virtio,qemu [ 0.000000] earlycon: uart8250 at MMIO 0x10000000 (options '115200') [ 0.000000] printk: bootconsole [uart8250] enabled [ 0.000000] efi: UEFI not found. [ 0.000000] Unable to handle kernel paging request at virtual address 00600001 [ 0.000000] Oops [#1] [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.108-rc1-00092-g0b6a5617247c #1 [ 0.000000] Hardware name: riscv-virtio,qemu (DT) [ 0.000000] epc : fdt_check_header+0x6/0x1ac [ 0.000000] ra : __unflatten_device_tree+0x32/0x106 [ 0.000000] epc : c04cf1dc ra : c0859f08 sp : c1c01f30 [ 0.000000] gp : c1d6dca8 tp : c1c0a9c0 t0 : 00000000 [ 0.000000] t1 : c100f4fc t2 : 00000000 s0 : c1c01f40 [ 0.000000] s1 : c0c25000 a0 : 00600000 a1 : 00000000 [ 0.000000] a2 : c1d74044 a3 : c0c253ae a4 : 00000000 [ 0.000000] a5 : c173a000 a6 : c1c01f2c a7 : 00000001 [ 0.000000] s2 : 00600000 s3 : c1d74044 s4 : c0c253ae [ 0.000000] s5 : 00000000 s6 : 00000000 s7 : 8001b020 [ 0.000000] s8 : 00002000 s9 : 800312e4 s10: 00000000 [ 0.000000] s11: 00000000 t3 : 00000000 t4 : 00000000 [ 0.000000] t5 : a0000000 t6 : 80400000 [ 0.000000] status: 00000100 badaddr: 00600001 cause: 0000000d [ 0.000000] [<c04cf1dc>] fdt_check_header+0x6/0x1ac [ 0.000000] ---[ end trace 6977e3ccdb629cdf ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
Bisect points to
08ace525df14 riscv: Do not set initial_boot_params to the linear address of the dtb
This is not surprising, because that commit says:
"early_init_dt_verify() is already called in parse_dtb() and since the dtb address does not change anymore (it is now in the fixmap region), no need to reset initial_boot_params by calling early_init_dt_verify() again. "
However, the patch which actually moves the early dtb mapping into the fixmap region was not backported (and looks quite invasive to me). That makes me wonder ... why is this a stable release candidate in the first place ?
Guenter