Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
Sure. https://bugzilla.kernel.org/show_bug.cgi?id=213143 - Rich On Thu, May 20, 2021 at 1:16 AM Salvatore Bonaccorso wrote: > > Hi Rich, > > On Wed, May 19, 2021 at 12:14:49AM -0400, Rich wrote: > > 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. > > Thanks, can you then point us to the upstream report once you got to > it? > > Regards, > Salvatore
Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
Hi Rich, On Wed, May 19, 2021 at 12:14:49AM -0400, Rich wrote: > 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. Thanks, can you then point us to the upstream report once you got to it? Regards, Salvatore
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 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 > 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 > > > > > > [ 17.539053] CPU 3 > > > [ 17.539053] kworker/3:1(39): Oops -1 > > > [ 17.539053] pc = [<>] ra = [<>] ps = > > > Tainted: GE > > > [ 17.539053] pc is at 0x0 > > > [ 17.541983] ra is at 0x0 > > > [ 17.542959] v0 = 0007 t0 = fc00026b8fc0 t1 = > > > > > > [ 17.542959] t2 = 0002 t3 = t4 = > > > 644e > > > [ 17.543936] t5 = 4000 t6 = 0001 t7 = > > > fc0004aac000 > > > [ 17.544912] s0 = fc00026b8fc0 s1 = fc00026b8fc0 s2 = > > > fc0002731290 > > > [ 17.544912] s3 = fc0002731290 s4 = fc0002741290 s5 = > > > fc00026b9178 > > > [ 17.545889] s6 = fc00010c9b80 > > > [ 17.545889] a0 = a1 = a2 = > > > 0040 > > > [ 17.546866] a3 = 0040 a4 = a5 = > > > > > > [ 17.548819] t8 = 0001 t9 = 014bbcf4 t10= > > > 0a546000 > > > [ 17.548819] t11= b938 pv = fc000193c640 at = > > > 0001 > > > [ 17.550772] gp = fc0002721290 sp = 9468c7b6 > > > [ 17.550772] Disabling lock debugging due to kernel taint > > > [ 17.550772] Trace: > > > [ 17.551748] [] wait_rcu_exp_gp+0x20/0x50 > > > [ 17.551748] [] process_one_work+0x20c/0x520 > > > [ 17.552725] [] worker_thread+0x90/0x770 > > > [ 17.552725] [] kthread+0x1c4/0x1e0 > > > [ 17.553701] [] worker_thread+0x0/0x770 > > > [ 17.553701] [] ret_from_kernel_thread+0x18/0x20 > > > [ 17.554678] [] kthread+0x0/0x1e0 > > > [ 17.555655] > > > [ 17.555655] Code: > > > [ 17.555655] > > > [ 17.555655] > > > [ 17.556631] 00063301 > > > [ 17.556631] 13d5 > > > [ 17.556631] > > > [ 17.556631] 52a3 > > > [ 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::2-: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
Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
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 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 > > > > [ 17.539053] CPU 3 > > [ 17.539053] kworker/3:1(39): Oops -1 > > [ 17.539053] pc = [<>] ra = [<>] ps = > > Tainted: GE > > [ 17.539053] pc is at 0x0 > > [ 17.541983] ra is at 0x0 > > [ 17.542959] v0 = 0007 t0 = fc00026b8fc0 t1 = > > > > [ 17.542959] t2 = 0002 t3 = t4 = > > 644e > > [ 17.543936] t5 = 4000 t6 = 0001 t7 = > > fc0004aac000 > > [ 17.544912] s0 = fc00026b8fc0 s1 = fc00026b8fc0 s2 = > > fc0002731290 > > [ 17.544912] s3 = fc0002731290 s4 = fc0002741290 s5 = > > fc00026b9178 > > [ 17.545889] s6 = fc00010c9b80 > > [ 17.545889] a0 = a1 = a2 = > > 0040 > > [ 17.546866] a3 = 0040 a4 = a5 = > > > > [ 17.548819] t8 = 0001 t9 = 014bbcf4 t10= > > 0a546000 > > [ 17.548819] t11= b938 pv = fc000193c640 at = > > 0001 > > [ 17.550772] gp = fc0002721290 sp = 9468c7b6 > > [ 17.550772] Disabling lock debugging due to kernel taint > > [ 17.550772] Trace: > > [ 17.551748] [] wait_rcu_exp_gp+0x20/0x50 > > [ 17.551748] [] process_one_work+0x20c/0x520 > > [ 17.552725] [] worker_thread+0x90/0x770 > > [ 17.552725] [] kthread+0x1c4/0x1e0 > > [ 17.553701] [] worker_thread+0x0/0x770 > > [ 17.553701] [] ret_from_kernel_thread+0x18/0x20 > > [ 17.554678] [] kthread+0x0/0x1e0 > > [ 17.555655] > > [ 17.555655] Code: > > [ 17.555655] > > [ 17.555655] > > [ 17.556631] 00063301 > > [ 17.556631] 13d5 > > [ 17.556631] > > [ 17.556631] 52a3 > > [ 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::2-: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
Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
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 > > [ 17.539053] CPU 3 > [ 17.539053] kworker/3:1(39): Oops -1 > [ 17.539053] pc = [<>] ra = [<>] ps = > Tainted: GE > [ 17.539053] pc is at 0x0 > [ 17.541983] ra is at 0x0 > [ 17.542959] v0 = 0007 t0 = fc00026b8fc0 t1 = > > [ 17.542959] t2 = 0002 t3 = t4 = > 644e > [ 17.543936] t5 = 4000 t6 = 0001 t7 = > fc0004aac000 > [ 17.544912] s0 = fc00026b8fc0 s1 = fc00026b8fc0 s2 = > fc0002731290 > [ 17.544912] s3 = fc0002731290 s4 = fc0002741290 s5 = > fc00026b9178 > [ 17.545889] s6 = fc00010c9b80 > [ 17.545889] a0 = a1 = a2 = > 0040 > [ 17.546866] a3 = 0040 a4 = a5 = > > [ 17.548819] t8 = 0001 t9 = 014bbcf4 t10= > 0a546000 > [ 17.548819] t11= b938 pv = fc000193c640 at = > 0001 > [ 17.550772] gp = fc0002721290 sp = 9468c7b6 > [ 17.550772] Disabling lock debugging due to kernel taint > [ 17.550772] Trace: > [ 17.551748] [] wait_rcu_exp_gp+0x20/0x50 > [ 17.551748] [] process_one_work+0x20c/0x520 > [ 17.552725] [] worker_thread+0x90/0x770 > [ 17.552725] [] kthread+0x1c4/0x1e0 > [ 17.553701] [] worker_thread+0x0/0x770 > [ 17.553701] [] ret_from_kernel_thread+0x18/0x20 > [ 17.554678] [] kthread+0x0/0x1e0 > [ 17.555655] > [ 17.555655] Code: > [ 17.555655] > [ 17.555655] > [ 17.556631] 00063301 > [ 17.556631] 13d5 > [ 17.556631] > [ 17.556631] 52a3 > [ 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::2-: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
Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
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 [ 17.539053] CPU 3 [ 17.539053] kworker/3:1(39): Oops -1 [ 17.539053] pc = [<>] ra = [<>] ps = Tainted: GE [ 17.539053] pc is at 0x0 [ 17.541983] ra is at 0x0 [ 17.542959] v0 = 0007 t0 = fc00026b8fc0 t1 = [ 17.542959] t2 = 0002 t3 = t4 = 644e [ 17.543936] t5 = 4000 t6 = 0001 t7 = fc0004aac000 [ 17.544912] s0 = fc00026b8fc0 s1 = fc00026b8fc0 s2 = fc0002731290 [ 17.544912] s3 = fc0002731290 s4 = fc0002741290 s5 = fc00026b9178 [ 17.545889] s6 = fc00010c9b80 [ 17.545889] a0 = a1 = a2 = 0040 [ 17.546866] a3 = 0040 a4 = a5 = [ 17.548819] t8 = 0001 t9 = 014bbcf4 t10= 0a546000 [ 17.548819] t11= b938 pv = fc000193c640 at = 0001 [ 17.550772] gp = fc0002721290 sp = 9468c7b6 [ 17.550772] Disabling lock debugging due to kernel taint [ 17.550772] Trace: [ 17.551748] [] wait_rcu_exp_gp+0x20/0x50 [ 17.551748] [] process_one_work+0x20c/0x520 [ 17.552725] [] worker_thread+0x90/0x770 [ 17.552725] [] kthread+0x1c4/0x1e0 [ 17.553701] [] worker_thread+0x0/0x770 [ 17.553701] [] ret_from_kernel_thread+0x18/0x20 [ 17.554678] [] kthread+0x0/0x1e0 [ 17.555655] [ 17.555655] Code: [ 17.555655] [ 17.555655] [ 17.556631] 00063301 [ 17.556631] 13d5 [ 17.556631] [ 17.556631] 52a3 [ 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::2-: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. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information system type : Tsunami system variation: Clipper system revision : 0 platform string : N/A ** Network interface configuration: *** /etc/network/interfaces: source /etc/network/interfaces.d/* auto lo iface lo inet loopback allow-hotplug enp0s1 iface enp0s1 inet dhcp ** PCI devices: 00:00.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8] (prog-if 00 [VGA controller]) Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Kernel driver in use: virtio-pci Kernel modules: virtio_pci 00:02.0 IDE interface [0101]: Silicon Image, Inc. PCI0646 [1095:0646] (rev 07) (prog-if 8f [PCI native mode controller, supports both channels switched to ISA compatibility mode, supports bus mastering]) Subsystem: Red Hat, Inc. PCI0646 [1af4:1100] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- pn fdutils pn linux-doc-5.10 Versions of packages linux-image-5.10.0-6-alpha-smp is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn
