BUG: kernel NULL pointer dereference, address: 0000000000000001
Package: src:linuxtemp_thermal uvcvideo intel_powerclamp snd_intel_sdw_acpi processor_thermal_wt_hint coretemp videobuf2_vmalloc iwlmvm btusb snd_hda_codec binfmt_misc processor_thermal_rfim drm_buddy kvm_intel uvc drm_display_helper btrtl snd_hda_core mac80211 intel_rapl_
Version: 6.12.27-1
Severity: important
X-Debbugs-Cc: debian-amd64@lists.debian.org
User: debian-amd64@lists.debian.org
Usertags: amd64
Dear Maintainer,
I noticed a kernel BUG line in the logs.
BUG: kernel NULL pointer dereference, address: 0000000000000001
-- Package-specific info:
** Version:
Linux version 6.12.27-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC Debian 6.12.27-1 (2025-05-06)
** Command line:
BOOT_IMAGE=/vmlinuz-6.12.27-amd64 root=/dev/mapper/spisula--vg-root ro quiet
** Tainted: D (128)
* kernel died recently, i.e. there was an OOPS or BUG
** Kernel log:
[ 15.089146] RDX: ffffffff83326d30 RSI: 0000000000000202 RDI: ffff9a9190947504
[ 15.089148] RBP: ffff9a9190947420 R08: ffff9a919c498be8 R09: 0000000000000000
[ 15.089149] R10: ffffb83f40d27ac8 R11: 0000000000000009 R12: ffff9a919c498d50
[ 15.089151] R13: 0000000000000000 R14: 0000000000000001 R15: ffff9a919c498b30
[ 15.089153] FS: 00007f10b2d30940(0000) GS:ffff9a91fbd00000(0000) knlGS:0000000000000000
[ 15.089155] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 15.089157] CR2: 0000000000000001 CR3: 000000011c33c000 CR4: 0000000000352ef0
[ 15.089159] Call Trace:
[ 15.089163] <TASK>
[ 15.089167] bmc150_accel_buffer_postenable+0x5d/0x90 [bmc150_accel_core] [ 15.089173] __iio_update_buffers+0x731/0xb20 [industrialio]
[ 15.089198] enable_store+0x84/0xe0 [industrialio]
[ 15.089214] kernfs_fop_write_iter+0x13b/0x1f0
[ 15.089222] vfs_write+0x28d/0x450
[ 15.089230] ksys_write+0x6d/0xf0
[ 15.089235] do_syscall_64+0x82/0x190
[ 15.089241] ? syscall_exit_to_user_mode+0x4d/0x210
[ 15.089245] ? do_syscall_64+0x8e/0x190
[ 15.089248] ? __memcg_slab_free_hook+0xf7/0x140
[ 15.089253] ? __x64_sys_close+0x3c/0x80
[ 15.089255] ? kmem_cache_free+0x3ee/0x440
[ 15.089260] ? syscall_exit_to_user_mode+0x4d/0x210
[ 15.089263] ? do_syscall_64+0x8e/0x190
[ 15.089265] ? kernfs_fop_write_iter+0x9d/0x1f0
[ 15.089268] ? vfs_write+0x28d/0x450
[ 15.089272] ? syscall_exit_to_user_mode+0x4d/0x210
[ 15.089275] ? clear_bhb_loop+0x25/0x80
[ 15.089279] ? clear_bhb_loop+0x25/0x80
[ 15.089281] ? clear_bhb_loop+0x25/0x80
[ 15.089284] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 15.089288] RIP: 0033:0x7f10b31369ee
[ 15.089319] Code: 08 0f 85 f5 4b ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 80 00 00 00 00 48 83 ec 08
[ 15.089321] RSP: 002b:00007ffc6dbe57d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 15.089324] RAX: ffffffffffffffda RBX: 00007f10b2d30940 RCX: 00007f10b31369ee
[ 15.089325] RDX: 0000000000000001 RSI: 00007ffc6dbe5980 RDI: 0000000000000009
[ 15.089327] RBP: 00007ffc6dbe5980 R08: 0000000000000000 R09: 0000000000000000
[ 15.089328] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
[ 15.089329] R13: 0000559ac7f662a0 R14: 00007f10b3281e80 R15: 0000000000000001
[ 15.089333] </TASK>
[ 15.089333] Modules linked in: snd_hda_ext_core snd_soc_core snd_compress snd_pcm_dmaengine overlay bnep zram processor_thermal_device_pci_legacy snd_hda_intel lz4hc_compress snd_intel_dspcfg lz4_compress i915(+) processor_thermal_device x86_pkg_
[ 15.089389] intel_cstate pcspkr mc wmi_bmof memstick pmt_telemetry soundcore rfkill mei i2c_algo_bit intel_soc_dts_iosf industrialio int3400_thermal ac acer_wireless int3403_thermal pmt_class soc_button_array button acpi_thermal_rel int340x_thermal_zone joydev evdev msr parport_pc ppdev lp parport efi_pstore configfs nfnetlink efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic rtsx_usb_sdmmc rtsx_usb dm_crypt dm_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_
[ 15.089449] CR2: 0000000000000001
[ 15.089451] ---[ end trace 0000000000000000 ]---
[ 15.207536] RIP: 0010:bmc150_accel_set_interrupt+0x68/0x120 [bmc150_accel_core]
[ 15.207561] Code: 84 86 00 00 00 ba 01 00 00 00 f0 0f c1 10 83 c2 01 83 fa 01 7f 64 49 8b 3c 24 be 01 00 00 00 e8 5e fc ff ff 89 c3 85 c0 75 52 <41> 0f b6 55 01 41 0f b6 75 00 45 31 c9 45 31 c0 49 8b 3c 24 6a 00
[ 15.207563] RSP: 0018:ffffb83f40d27ab0 EFLAGS: 00010246
[ 15.207567] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000ffffff01
Can you please test 6.12.29-1 from unstable (and which should migrate
soon to trixie)?
If you can reproduce the issue, can you please post the full kernel
log once the issue has happened, so we get the full context (The
previous log is capped).
On Sun, May 25, 2025 at 04:50:14PM +0200, Salvatore Bonaccorso wrote:
Can you please test 6.12.29-1 from unstable (and which should migrate
soon to trixie)?
If you can reproduce the issue, can you please post the full kernel
log once the issue has happened, so we get the full context (The
previous log is capped).
Output of `journalctl --boot --dmseg` from 6.12.29 attached.
So far it seems to happen on every boot, between unlocking LUKS and the
login manager starting.
I wonder if this is related to another symptom this machine has, where
it fails to complete suspend and goes into a state where the only action
that has any effect is a long-press of the power button to turn it off.
On Sun, May 25, 2025 at 04:50:14PM +0200, Salvatore Bonaccorso wrote:
Can you please test 6.12.29-1 from unstable (and which should migrate
soon to trixie)?
If you can reproduce the issue, can you please post the full kernel
log once the issue has happened, so we get the full context (The
previous log is capped).
Output of `journalctl --boot --dmseg` from 6.12.29 attached.
So far it seems to happen on every boot, between unlocking LUKS and the
login manager starting.
I wonder if this is related to another symptom this machine has, where
it fails to complete suspend and goes into a state where the only action
that has any effect is a long-press of the power button to turn it off.
May 30 19:21:47 spisula kernel: bmc150_accel_i2c i2c-BOSC0200:00: supply vdd not found, using dummy regulator[...]
May 30 19:21:47 spisula kernel: bmc150_accel_i2c i2c-BOSC0200:00: supply vddio not found, using dummy regulator
May 30 19:21:47 spisula kernel: bmc150_accel_i2c i2c-BOSC0200:base: supply vdd not found, using dummy regulator
May 30 19:21:47 spisula kernel: bmc150_accel_i2c i2c-BOSC0200:base: supply vddio not found, using dummy regulator
May 30 19:21:49 spisula kernel: BUG: kernel NULL pointer dereference, address: 0000000000000001
May 30 19:21:49 spisula kernel: #PF: supervisor read access in kernel mode May 30 19:21:49 spisula kernel: #PF: error_code(0x0000) - not-present page May 30 19:21:49 spisula kernel: PGD 0 P4D 0
May 30 19:21:49 spisula kernel: Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
May 30 19:21:49 spisula kernel: CPU: 2 UID: 0 PID: 805 Comm: iio-sensor-prox Not tainted 6.12.29-amd64 #1 Debian 6.12.29-1
May 30 19:21:49 spisula kernel: Hardware name: Acer TravelMate Spin B311R-31/Maracas_GL, BIOS V1.18 08/26/2021
May 30 19:21:49 spisula kernel: RIP: 0010:bmc150_accel_set_interrupt+0x68/0x120 [bmc150_accel_core]
May 30 19:21:49 spisula kernel: Code: 84 86 00 00 00 ba 01 00 00 00 f0 0f c1 10 83 c2 01 83 fa 01 7f 64 49 8b 3c 24 be 01 00 00 00 e8 5e fc ff ff 89 c3 85 c0 75 52 <41> 0f b6 55 01 41 0f b6 75 00 45 31 c9 45 31 c0 49 8b 3c 24 6a 00
May 30 19:21:49 spisula kernel: RSP: 0018:ffffb44780e03b10 EFLAGS: 00010246 May 30 19:21:49 spisula kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000ffffff01
May 30 19:21:49 spisula kernel: RDX: ffffffff8d12acf0 RSI: 0000000000000202 RDI: ffffa06a42513904
May 30 19:21:49 spisula kernel: RBP: ffffa06a42513820 R08: ffffa06a4b33fbe8 R09: 0000000000000000
May 30 19:21:49 spisula kernel: R10: ffffb44780e03b28 R11: 0000000000000009 R12: ffffa06a4b33fd50
May 30 19:21:49 spisula kernel: R13: 0000000000000000 R14: 0000000000000001 R15: ffffa06a4b33fb30
May 30 19:21:49 spisula kernel: FS: 00007f368a3d9940(0000) GS:ffffa06abbd00000(0000) knlGS:0000000000000000
May 30 19:21:49 spisula kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
May 30 19:21:49 spisula kernel: CR2: 0000000000000001 CR3: 0000000105610000 CR4: 0000000000352ef0
May 30 19:21:49 spisula kernel: Call Trace:
May 30 19:21:49 spisula kernel: <TASK>
May 30 19:21:49 spisula kernel: bmc150_accel_buffer_postenable+0x5d/0x90 [bmc150_accel_core]
May 30 19:21:49 spisula kernel: __iio_update_buffers+0x731/0xb20 [industrialio]
May 30 19:21:49 spisula kernel: ? __kernfs_setattr+0xa0/0xb0
May 30 19:21:49 spisula kernel: enable_store+0x84/0xe0 [industrialio]
May 30 19:21:49 spisula kernel: kernfs_fop_write_iter+0x13b/0x1f0
May 30 19:21:49 spisula kernel: vfs_write+0x28d/0x450
May 30 19:21:49 spisula kernel: ksys_write+0x6d/0xf0
May 30 19:21:49 spisula kernel: do_syscall_64+0x82/0x190
May 30 19:21:49 spisula kernel: ? do_filp_open+0xc4/0x170
May 30 19:21:49 spisula kernel: ? do_sys_openat2+0x9c/0xe0
May 30 19:21:49 spisula kernel: ? syscall_exit_to_user_mode+0x4d/0x210
May 30 19:21:49 spisula kernel: ? do_syscall_64+0x8e/0x190
May 30 19:21:49 spisula kernel: ? do_syscall_64+0x8e/0x190
May 30 19:21:49 spisula kernel: ? clear_bhb_loop+0x40/0x90
May 30 19:21:49 spisula kernel: ? clear_bhb_loop+0x40/0x90
May 30 19:21:49 spisula kernel: ? clear_bhb_loop+0x40/0x90
May 30 19:21:49 spisula kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
May 30 19:21:49 spisula kernel: RIP: 0033:0x7f368a7df9ee
May 30 19:21:49 spisula kernel: Code: 08 0f 85 f5 4b ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 80 00 00 00 00 48 83 ec 08
May 30 19:21:49 spisula kernel: RSP: 002b:00007fffd76b67e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
On Fri, May 30, 2025 at 07:42:12PM +0200, Kim Alvefur wrote:
So far it seems to happen on every boot, between unlocking LUKS and the
login manager starting.
I wonder if this is related to another symptom this machine has, where
it fails to complete suspend and goes into a state where the only action
that has any effect is a long-press of the power button to turn it off.
Looking through the boot log I'm noticing the following:
May 30 19:21:47 spisula kernel: bmc150_accel_i2c i2c-BOSC0200:00: supply vdd not found, using dummy regulator[...]
May 30 19:21:47 spisula kernel: bmc150_accel_i2c i2c-BOSC0200:00: supply vddio not found, using dummy regulator
May 30 19:21:47 spisula kernel: bmc150_accel_i2c i2c-BOSC0200:base: supply vdd not found, using dummy regulator
May 30 19:21:47 spisula kernel: bmc150_accel_i2c i2c-BOSC0200:base: supply vddio not found, using dummy regulator
and iio-sensor-proxy might fail to handle then the bosch 0200
accelerometer. You proobably cannot temporary purge the
iio-sensor-proxy if installed by reverse dependencies, but might you
try to temporarily mask the service and retest a boot?
One additional preliminary question, since I missed to ask it in the
earlier reply: Is this a regression you are seeing when updating to
6.12.27-1 (and later)? If so can you pinpoint the Debian revision
where you first saw this happening?
In case we have a regression, would you be able to bisect the
respective upstream stable versions to pinpoint the breaking commit,
which would be helpful for the upstream report?
Hi Salvatore,
On Sat, May 31, 2025 at 08:53:26PM +0200, Salvatore Bonaccorso wrote:
One additional preliminary question, since I missed to ask it in the earlier reply: Is this a regression you are seeing when updating to 6.12.27-1 (and later)? If so can you pinpoint the Debian revision
where you first saw this happening?
Looking at earlier kernel logs in the journal, this happened for the
first time in March, which was after I upgraded to Debian 13.
Using Debian snapshots I tried a few older kernels, the earliest being 6.12.6-1 from late 2024 and it happened there too.
In case we have a regression, would you be able to bisect the
respective upstream stable versions to pinpoint the breaking commit,
which would be helpful for the upstream report?
I can certainly try, at least using repository snapshots to narrow it
down. It has been many years since I last compiled a kernel, so I could
do with a refresher there :)
Any suggestions for how far back to go?
If you updates from bookworm to trixie then start with the bookworm
based kernel and bisect there the debian image versions first until we
get a closer range where an upstream change happened.
Note I have forwarded the report to usptream but so far no reaction.
It might actually be that with the trixie system and the older kernel
you will hit now the issue as well as it is just undovered by having >iio-sensor-proxy running (you could double check in your apt/dpkg logs
if it was already installed under bookworm though).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 148:31:20 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,747 |