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
