Re: Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
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 <rincebrain@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 <carnil@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: rincebrain@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
Reply to: