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.

Hi,

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

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

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.

Hi Rich,

Thanks, can you then point us to the upstream report once you got to
it?

Regards,
Salvatore

Sure.

https://bugzilla.kernel.org/show_bug.cgi?id=213143

- Rich