Bug#1143721: linux-image-6.12.96+deb13-amd64: Fails to boot BUG: kernel NULL pointer dereference, address: 0000000000000000
stable bisect: git bisect start # status: waiting for both good and bad commits # good: [296aabce459470a4c1b68ffd0c0c0920e563aaad] Linux 6.12.95 git bisect good 296aabce459470a4c1b68ffd0c0c0920e563aaad # status: waiting for bad commit, 1 good commit known # bad: [6d15a1029d425b15c59463910ebdccc4afe760d6] Linux 6.12.96 git bisect bad 6d15a1029d425b15c59463910ebdccc4afe760d6 # bad: [6d15a1029d425b15c59463910ebdccc4afe760d6] Linux 6.12.96 git bisect bad 6d15a1029d425b15c59463910ebdccc4afe760d6 # good: [878757163eea684750107a31ea134c103863515d] smb: client: fix double-free in SMB2_flush() replay git bisect good 878757163eea684750107a31ea134c103863515d # bad: [977855894bca4b87afa50d21e3f3e85a5a0e901f] serial: 8250_mid: Disable DMA for selected platforms git bisect bad 977855894bca4b87afa50d21e3f3e85a5a0e901f # good: [ac0774961a6ea174a71d4ffa39966edafbf7662d] media: mtk-jpeg: cancel workqueue on release for supported platforms only git bisect good ac0774961a6ea174a71d4ffa39966edafbf7662d # first bad commit: [977855894bca4b87afa50d21e3f3e85a5a0e901f] serial: 8250_mid: Disable DMA for selected platforms -- /RattusRattus Debian is not always the answer, however it is surprising how many times it is...
Bug#1143721: linux-image-6.12.96+deb13-amd64: Fails to boot BUG: kernel NULL pointer dereference, address: 0000000000000000
Control: tags -1 + moreinfo HI Andy, On Wed, Aug 05, 2026 at 12:42:03PM +0100, Andy Simpkins wrote: > Package: src:linux > Version: 6.12.96-1 > Severity: critical > Justification: breaks the whole system > X-Debbugs-Cc: [email protected], [email protected] > User: [email protected] > Usertags: amd64 kernel > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > My server failed to restert after a dist-upgrade on 2026-08-01 > the only update was the kernel that went from 6.12.88+deb13-amd64 to > 6.12.100+deb13-amd64 > packages had previously been updated... > > > Debugging so far: > 2026-08-01 > > (1) My server failed to restert after a dist-upgrade on 2026-08-01 > the only update was the kernel that went from 6.12.88+deb13-amd64 to > 6.12.100+deb13-amd64 > > Watching the system boot on the local screen showed: > | Loading Linux 6.12.100+deb13-amd64 ... > | Loading initial ramdisk ... > > and nothing else. > > (2) Breaking into the grub menu and removing the qiate option yeilds a > little more information (but not much): > | Loading Linux 6.12.100+deb13-amd64 ... > | Loading initial ramdisk ... > | > | > | EFI stub: Loaded initrd from > LINUX_EFI_INITRD_MEDIA_GUID d > | evice path > | EFI stub: Measured initrd data into PCR 9 > > and nothing else. > > (3) Initial debugging: > - Confirmed that I could still boot the machine with the old kernel > 6.12.88+deb13-amd64 > - Checked that /boot had enough space > - Went to google. Actually not mush referanced EFI stub: Measured > initrd data into PCR 9 apart from > the usual "turn off secure boot" (on this server that isn't turned > on - bad me) > > (4) Start looking for where the fault first occured > - between 6.12.88+deb13 and 6.12.100+deb13 Debian stable has only had > .90 .94 .95 and .96 kernels > - testing them .95 worked and .96 yeilded the same lock up on boot > as .100 > >iSo the problem first appers in the .96 kernel and is not in the .95 > kernel > This is a good place to report a bug, but can I (with a lot of help) > track down this still further > > > 2026-08-02 > >iup until now I have been walking to my garage where the server is > located and standing in front of a rack > with a monitor and keyboard plugged into the machine. However this > machine supports IPMI so I spent a little time getting that up and running so > that I can continue from the relative comfort of my desk (with lights, a > chair and not needing to hold the keyboard with one hand) > > > (5) Sledge had mentioned this problem in irc/#debain-kernal where iam_tj > suggested that we try appending > 'debug earlycon=efifb' to the kernal command line. This yielded 15 > seconds worth of messages before the system locked up the last few messages > being (vmlinuz-6.12.96+deb13-amd64): > | [ 14.663477] RCU Tasks: Setting shift to 5 and lim to > 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. > | [ 14.750474] RCU Tasks Rude: Setting shift to 5 and > lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. > | [ 14.838024] RCU Tasks Trace: Setting shift to 5 and > lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. > | [ 14.929752] NR_IRQS: 524544, nr_irqs: 584, > preallocated irqs: 16 > | [ 15.016814] rcu: srcu_init: Setting srcu_struct > sizes based on contention. > | [ 15.104011] Console: colour dummy device 80x25 > | [ 15.191236] printk: legacy console [tty0] enabled > | [ 15.278249] printk: legacy bootconsole [efifb0] > disabled > > booting the working kernel with the same kernal options yeilds > the SAME messages with slightly differing times, but then continues to login > prompt: > | [ 14.697466] RCU Tasks: Setting shift to 5 and lim to > 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. > | [ 14.784936] RCU Tasks Rude: Setting shift to 5 and > lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. > | [ 14.872067] RCU Tasks Trace: Setting shift to 5 and > lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. > | [ 14.964000] NR_IRQS: 524544, nr_irqs: 584, > preallocated irqs: 16 > | [ 15.051482] rcu: srcu_init: Setting srcu_struct > sizes based on contention. > | [ 15.138589] Console: colour dummy device 80x25 > | [ 15.226079] printk: legacy console [tty0] enabled > | [
Bug#1143721: linux-image-6.12.96+deb13-amd64: Fails to boot BUG: kernel NULL pointer dereference, address: 0000000000000000
Package: src:linux Version: 6.12.96-1 Severity: critical Justification: breaks the whole system X-Debbugs-Cc: [email protected], [email protected] User: [email protected] Usertags: amd64 kernel Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? My server failed to restert after a dist-upgrade on 2026-08-01 the only update was the kernel that went from 6.12.88+deb13-amd64 to 6.12.100+deb13-amd64 packages had previously been updated... Debugging so far: 2026-08-01 (1) My server failed to restert after a dist-upgrade on 2026-08-01 the only update was the kernel that went from 6.12.88+deb13-amd64 to 6.12.100+deb13-amd64 Watching the system boot on the local screen showed: | Loading Linux 6.12.100+deb13-amd64 ... | Loading initial ramdisk ... and nothing else. (2) Breaking into the grub menu and removing the qiate option yeilds a little more information (but not much): | Loading Linux 6.12.100+deb13-amd64 ... | Loading initial ramdisk ... | | | EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID d | evice path | EFI stub: Measured initrd data into PCR 9 and nothing else. (3) Initial debugging: - Confirmed that I could still boot the machine with the old kernel 6.12.88+deb13-amd64 - Checked that /boot had enough space - Went to google. Actually not mush referanced EFI stub: Measured initrd data into PCR 9 apart from the usual "turn off secure boot" (on this server that isn't turned on - bad me) (4) Start looking for where the fault first occured - between 6.12.88+deb13 and 6.12.100+deb13 Debian stable has only had .90 .94 .95 and .96 kernels - testing them .95 worked and .96 yeilded the same lock up on boot as .100 iSo the problem first appers in the .96 kernel and is not in the .95 kernel This is a good place to report a bug, but can I (with a lot of help) track down this still further 2026-08-02 iup until now I have been walking to my garage where the server is located and standing in front of a rack with a monitor and keyboard plugged into the machine. However this machine supports IPMI so I spent a little time getting that up and running so that I can continue from the relative comfort of my desk (with lights, a chair and not needing to hold the keyboard with one hand) (5) Sledge had mentioned this problem in irc/#debain-kernal where iam_tj suggested that we try appending 'debug earlycon=efifb' to the kernal command line. This yielded 15 seconds worth of messages before the system locked up the last few messages being (vmlinuz-6.12.96+deb13-amd64): | [ 14.663477] RCU Tasks: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. | [ 14.750474] RCU Tasks Rude: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. | [ 14.838024] RCU Tasks Trace: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. | [ 14.929752] NR_IRQS: 524544, nr_irqs: 584, preallocated irqs: 16 | [ 15.016814] rcu: srcu_init: Setting srcu_struct sizes based on contention. | [ 15.104011] Console: colour dummy device 80x25 | [ 15.191236] printk: legacy console [tty0] enabled | [ 15.278249] printk: legacy bootconsole [efifb0] disabled booting the working kernel with the same kernal options yeilds the SAME messages with slightly differing times, but then continues to login prompt: | [ 14.697466] RCU Tasks: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. | [ 14.784936] RCU Tasks Rude: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. | [ 14.872067] RCU Tasks Trace: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. | [ 14.964000] NR_IRQS: 524544, nr_irqs: 584, preallocated irqs: 16 | [ 15.051482] rcu: srcu_init: Setting srcu_struct sizes based on contention. | [ 15.138589] Console: colour dummy device 80x25 | [ 15.226079] printk: legacy console [tty0] enabled | [ 15.313751] printk: legacy bootconsole [efifb0] disabled | [ 15.400831] ACPI: Core revision 20240827 | [ 15.401415] clocksource: hpet: mask: 0x max_cycles: 0x, max_idle_ns: 79635855245 ns | [ 15.401464] APIC: Switch to symmetric I/O mode setup
