Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #71659 > unrolled thread

Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot

Started byRich <rincebrain@gmail.com>
First post2021-05-16 04:10 +0200
Last post2021-05-16 17:20 +0200
Articles 7 — 3 participants

Back to article view | Back to linux.debian.kernel

Contents

  Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot Rich <rincebrain@gmail.com> - 2021-05-16 04:10 +0200
    Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot Salvatore Bonaccorso <carnil@debian.org> - 2021-05-16 17:20 +0200
      Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot Rich <rincebrain@gmail.com> - 2021-05-16 17:20 +0200
        Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot Rich <rincebrain@gmail.com> - 2021-05-19 06:20 +0200
          Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot Salvatore Bonaccorso <carnil@debian.org> - 2021-05-20 07:30 +0200
            Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot Rich <rincebrain@gmail.com> - 2021-05-20 08:00 +0200
    Processed: Re: Bug#988573: linux-image-5.10.0-6-alpha-smp  dereferences a null pointer on boot "Debian Bug Tracking System" <owner@bugs.debian.org> - 2021-05-16 17:20 +0200

#71659 — Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot

FromRich <rincebrain@gmail.com>
Date2021-05-16 04:10 +0200
SubjectBug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
Message-ID<Cfeo9-4jv-1@gated-at.bofh.it>
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.

-- 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- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Region 0: Memory at 0a000000 (32-bit, prefetchable) [size=32M]
	Region 1: Memory at 09054000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at 09040000 [virtual] [disabled] [size=64K]
	Kernel driver in use: cirrus
	Kernel modules: cirrusfb, cirrus

00:01.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device [1af4:1000]
	Subsystem: Red Hat, Inc. Virtio network device [1af4:0001]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 24
	Region 0: I/O ports at 8000 [size=32]
	Region 4: Memory at 09050000 (64-bit, prefetchable) [size=16K]
	Expansion ROM at 09000000 [virtual] [disabled] [size=256K]
	Capabilities: <access denied>
	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- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 28
	Region 0: I/O ports at 8030 [size=8]
	Region 1: I/O ports at 8040 [size=4]
	Region 2: I/O ports at 8038 [size=8]
	Region 3: I/O ports at 8044 [size=4]
	Region 4: I/O ports at 8020 [size=16]
	Kernel driver in use: pata_cmd64x
	Kernel modules: pata_cmd64x, ata_generic


** USB devices:
not available


-- System Information:
Debian Release: 11.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable'), (1, 'experimental')
Architecture: alpha

Kernel: Linux 5.10.0-6-alpha-generic
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.10.0-6-alpha-smp depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod                                    28-1
ii  linux-base                              4.6

Versions of packages linux-image-5.10.0-6-alpha-smp recommends:
ii  apparmor             2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-6-alpha-smp suggests:
ii  aboot                   1.0~pre20200212-1
pn  debian-kernel-handbook  <none>
pn  fdutils                 <none>
pn  linux-doc-5.10          <none>

Versions of packages linux-image-5.10.0-6-alpha-smp is related to:
pn  firmware-amd-graphics     <none>
pn  firmware-atheros          <none>
pn  firmware-bnx2             <none>
pn  firmware-bnx2x            <none>
pn  firmware-brcm80211        <none>
pn  firmware-cavium           <none>
pn  firmware-intel-sound      <none>
pn  firmware-intelwimax       <none>
pn  firmware-ipw2x00          <none>
pn  firmware-ivtv             <none>
pn  firmware-iwlwifi          <none>
pn  firmware-libertas         <none>
pn  firmware-linux-nonfree    <none>
pn  firmware-misc-nonfree     <none>
pn  firmware-myricom          <none>
pn  firmware-netxen           <none>
pn  firmware-qlogic           <none>
pn  firmware-realtek          <none>
pn  firmware-samsung          <none>
pn  firmware-siano            <none>
pn  firmware-ti-connectivity  <none>
pn  xen-hypervisor            <none>

-- no debconf information

[toc] | [next] | [standalone]

#71666

FromSalvatore Bonaccorso <carnil@debian.org>
Date2021-05-16 17:20 +0200
Message-ID<Cfqz0-3cH-7@gated-at.bofh.it>
In reply to#71659
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

[toc] | [prev] | [next] | [standalone]

#71667

FromRich <rincebrain@gmail.com>
Date2021-05-16 17:20 +0200
Message-ID<CfqIG-3fT-1@gated-at.bofh.it>
In reply to#71666
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

[toc] | [prev] | [next] | [standalone]

#71700

FromRich <rincebrain@gmail.com>
Date2021-05-19 06:20 +0200
Message-ID<CglQD-3NV-5@gated-at.bofh.it>
In reply to#71667
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

[toc] | [prev] | [next] | [standalone]

#71710

FromSalvatore Bonaccorso <carnil@debian.org>
Date2021-05-20 07:30 +0200
Message-ID<CgJpT-1ex-1@gated-at.bofh.it>
In reply to#71700
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

[toc] | [prev] | [next] | [standalone]

#71714

FromRich <rincebrain@gmail.com>
Date2021-05-20 08:00 +0200
Message-ID<CgJSV-1nU-9@gated-at.bofh.it>
In reply to#71710
Sure.

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

- Rich

On Thu, May 20, 2021 at 1:16 AM Salvatore Bonaccorso <carnil@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#71668 — Processed: Re: Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2021-05-16 17:20 +0200
SubjectProcessed: Re: Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
Message-ID<CfqIG-3fT-11@gated-at.bofh.it>
In reply to#71659
Processing control commands:

> tags -1 + moreinfo
Bug #988573 [src:linux] linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot
Added tag(s) moreinfo.

-- 
988573: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988573
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web