So it reproduces identically on 5.10.28 and 5.12.4 vanilla, but 5.13.0-rc2 fails differently, so I'm going to report that.
On Sun, May 16, 2021 at 11:13 AM Rich <rincebr...@gmail.com> wrote: > > Sure, I'll try 5.12.4 once I'm done with the build I'm running. (I > have no idea how long that'll be, though, I've never built it > before...) > > - Rich > > On Sun, May 16, 2021 at 11:08 AM Salvatore Bonaccorso <car...@debian.org> > wrote: > > > > Control: tags -1 + moreinfo > > > > Hi, > > > > On Sat, May 15, 2021 at 10:01:32PM -0400, Rich wrote: > > > Package: src:linux > > > Version: 5.10.28-1 > > > Severity: normal > > > X-Debbugs-Cc: rincebr...@gmail.com > > > > > > Dear Maintainer, > > > > > > (This might also affect upstream, I haven't built a vanilla kernel to > > > experiment.) > > > > > > On my (qemu-provided) alpha system, attempting to boot with the SMP kernel > > > yields the following message during boot: > > > > > > > > > [ 17.538076] Unable to handle kernel paging request at virtual address > > > 0000000000000000 > > > [ 17.539053] CPU 3 > > > [ 17.539053] kworker/3:1(39): Oops -1 > > > [ 17.539053] pc = [<0000000000000000>] ra = [<0000000000000000>] ps = > > > 0000 Tainted: G E > > > [ 17.539053] pc is at 0x0 > > > [ 17.541983] ra is at 0x0 > > > [ 17.542959] v0 = 0000000000000007 t0 = fffffc00026b8fc0 t1 = > > > 0000000000000000 > > > [ 17.542959] t2 = 0000000000000002 t3 = 0000000000000000 t4 = > > > 000000000000644e > > > [ 17.543936] t5 = 0000000000004000 t6 = 0000000000000001 t7 = > > > fffffc0004aac000 > > > [ 17.544912] s0 = fffffc00026b8fc0 s1 = fffffc00026b8fc0 s2 = > > > fffffc0002731290 > > > [ 17.544912] s3 = fffffc0002731290 s4 = fffffc0002741290 s5 = > > > fffffc00026b9178 > > > [ 17.545889] s6 = fffffc00010c9b80 > > > [ 17.545889] a0 = 0000000000000000 a1 = 0000000000000000 a2 = > > > 0000000000000040 > > > [ 17.546866] a3 = 0000000000000040 a4 = 0000000000000000 a5 = > > > 0000000000000000 > > > [ 17.548819] t8 = 0000000000000001 t9 = 00000000014bbcf4 t10= > > > 000000000a546000 > > > [ 17.548819] t11= 000000000000b938 pv = fffffc000193c640 at = > > > 0000000000000001 > > > [ 17.550772] gp = fffffc0002721290 sp = 000000009468c7b6 > > > [ 17.550772] Disabling lock debugging due to kernel taint > > > [ 17.550772] Trace: > > > [ 17.551748] [<fffffc00010cc330>] wait_rcu_exp_gp+0x20/0x50 > > > [ 17.551748] [<fffffc000105958c>] process_one_work+0x20c/0x520 > > > [ 17.552725] [<fffffc0001059930>] worker_thread+0x90/0x770 > > > [ 17.552725] [<fffffc00010633d4>] kthread+0x1c4/0x1e0 > > > [ 17.553701] [<fffffc00010598a0>] worker_thread+0x0/0x770 > > > [ 17.553701] [<fffffc0001011848>] ret_from_kernel_thread+0x18/0x20 > > > [ 17.554678] [<fffffc0001063210>] kthread+0x0/0x1e0 > > > [ 17.555655] > > > [ 17.555655] Code: > > > [ 17.555655] 00000000 > > > [ 17.555655] 00000000 > > > [ 17.556631] 00063301 > > > [ 17.556631] 000013d5 > > > [ 17.556631] 00001111 > > > [ 17.556631] 000052a3 > > > [ 17.556631] > > > > > > which is not especially informative. I _suspect_ this may be somewhere in > > > the network stack, because the boot process shortly thereafter blocks > > > indefinitely on systemd-timesyncd starting... > > > > > > Since it could conceivably be relevant, my qemu command line for spawning > > > this VM is: > > > > > > qemu-system-alpha -m 4096 -vnc :12 -net nic,model=virtio-net-pci -net > > > user,hostfwd=tcp::20000-:22 -drive file=alpha,format=raw -smp 4 -kernel > > > vmlinux-5.10.0-6-alpha-generic -initrd initrd.img-5.10.0-6-alpha-generic > > > -append console=ttyS0 root=UUID=f5487547-65eb-4330-8644-39e494b5d972 > > > -nographic > > > > > > (with s/-generic/-smp/g for when it breaks) > > > > > > (I also have tried nic,model=e1000 and nic,model=ne2k_pci, it does not > > > change the printout.) > > > > > > The qemu version is qemu-system misc 5.2+dfsg-9~bpo10+1 from > > > buster-backports, on an x86_64 buster host. > > > > Can you please try to verify upstream as well and then report the > > issue directly to upstream (keep the Debian bug in the loop). > > > > Regards, > > Salvatore
