Call trace on boot after upgrade to Linux kernel 6.x
Opened this issue · 3 comments
chr0mag commented
I've been seeing the call trace below when I boot my APU2C4 after moving to 6.x kernels. I've used a few 6.0.x and 6.1.x kernels and they've all exhibited the same behaviour.
I'm currently running:
% uname -a
Linux apu2c4 6.1.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 21 Dec 2022 22:27:55 +0000 x86_64 GNU/Linux
Upgrading to the latest mainline firmware shows the same behaviour:
% dmidecode --string bios-version
v4.17.0.2
I haven't noticed any system instability or other issues as a result.
The call trace:
% journalctl --boot=0 --priority=4 --no-pager
Dec 31 21:00:33 apu2c4 kernel: ------------[ cut here ]------------
Dec 31 21:00:33 apu2c4 kernel: memcpy: detected field-spanning write (size 32) of single field "&device->entry" at drivers/firmware/google/coreboot_table.c:104 (size 8)
Dec 31 21:00:33 apu2c4 kernel: WARNING: CPU: 0 PID: 241 at drivers/firmware/google/coreboot_table.c:104 coreboot_table_probe+0x1ba/0x1e2 [coreboot_table]
Dec 31 21:00:33 apu2c4 kernel: Modules linked in: pcc_cpufreq(-) coreboot_table(+) acpi_cpufreq mac_hid ledtrig_netdev fuse bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 mmc_block sdhci_pci cqhci sdhci mmc_core crc32c_intel xhci_pci xhci_pci_renesas gpio_keys
Dec 31 21:00:33 apu2c4 kernel: CPU: 0 PID: 241 Comm: systemd-udevd Not tainted 6.1.1-arch1-1 #1 9bd09188b430be630e611f984454e4f3c489be77
Dec 31 21:00:33 apu2c4 kernel: Hardware name: PC Engines apu2/apu2, BIOS v4.17.0.2 07/28/2022
Dec 31 21:00:33 apu2c4 kernel: RIP: 0010:coreboot_table_probe+0x1ba/0x1e2 [coreboot_table]
Dec 31 21:00:33 apu2c4 kernel: Code: 08 00 00 00 48 89 c6 48 89 04 24 48 c7 c2 00 a1 57 c0 48 c7 c7 48 a1 57 c0 4c 89 44 24 08 c6 05 f3 1e 00 00 01 e8 b1 a1 a4 e3 <0f> 0b 4c 8b 44 24 08 48 8b 04 24 e9 71 ff ff ff 41 bf ea ff ff ff
Dec 31 21:00:33 apu2c4 kernel: RSP: 0018:ffffafeb40703b48 EFLAGS: 00010286
Dec 31 21:00:33 apu2c4 kernel: RAX: 0000000000000000 RBX: ffff9e76046f2000 RCX: 0000000000000027
Dec 31 21:00:33 apu2c4 kernel: RDX: ffff9e762ac21668 RSI: 0000000000000001 RDI: ffff9e762ac21660
Dec 31 21:00:33 apu2c4 kernel: RBP: ffffafeb400d5018 R08: 0000000000000000 R09: ffffafeb407039d0
Dec 31 21:00:33 apu2c4 kernel: R10: 0000000000000003 R11: ffffffffa52cb768 R12: 0000000000000000
Dec 31 21:00:33 apu2c4 kernel: R13: ffffafeb400d5000 R14: ffff9e7600c0d810 R15: 0000000000000000
Dec 31 21:00:33 apu2c4 kernel: FS: 00007f62a7860080(0000) GS:ffff9e762ac00000(0000) knlGS:0000000000000000
Dec 31 21:00:33 apu2c4 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 31 21:00:33 apu2c4 kernel: CR2: 000055733bf1d2d8 CR3: 000000010259a000 CR4: 00000000000406f0
Dec 31 21:00:33 apu2c4 kernel: Call Trace:
Dec 31 21:00:33 apu2c4 kernel: <TASK>
Dec 31 21:00:33 apu2c4 kernel: platform_probe+0x48/0x90
Dec 31 21:00:33 apu2c4 kernel: really_probe+0xde/0x380
Dec 31 21:00:33 apu2c4 kernel: ? pm_runtime_barrier+0x54/0x90
Dec 31 21:00:33 apu2c4 kernel: __driver_probe_device+0x78/0x170
Dec 31 21:00:33 apu2c4 kernel: driver_probe_device+0x1f/0x90
Dec 31 21:00:33 apu2c4 kernel: __driver_attach+0xd5/0x1d0
Dec 31 21:00:33 apu2c4 kernel: ? __device_attach_driver+0x110/0x110
Dec 31 21:00:33 apu2c4 kernel: bus_for_each_dev+0x8b/0xd0
Dec 31 21:00:33 apu2c4 kernel: bus_add_driver+0x1b2/0x200
Dec 31 21:00:33 apu2c4 kernel: driver_register+0x8d/0xe0
Dec 31 21:00:33 apu2c4 kernel: coreboot_table_driver_init+0x2f/0x1000 [coreboot_table 88ba60255f1ecf81d7bd02d65b11614bb24acd8e]
Dec 31 21:00:33 apu2c4 kernel: ? 0xffffffffc057e000
Dec 31 21:00:33 apu2c4 kernel: do_one_initcall+0x5d/0x220
Dec 31 21:00:33 apu2c4 kernel: do_init_module+0x4a/0x1e0
Dec 31 21:00:33 apu2c4 kernel: __do_sys_init_module+0x17f/0x1b0
Dec 31 21:00:33 apu2c4 kernel: do_syscall_64+0x5f/0x90
Dec 31 21:00:33 apu2c4 kernel: ? handle_mm_fault+0xdf/0x2d0
Dec 31 21:00:33 apu2c4 kernel: ? do_user_addr_fault+0x1e0/0x6a0
Dec 31 21:00:33 apu2c4 kernel: ? do_syscall_64+0x6b/0x90
Dec 31 21:00:33 apu2c4 kernel: ? exc_page_fault+0x74/0x170
Dec 31 21:00:33 apu2c4 kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd
Dec 31 21:00:33 apu2c4 kernel: RIP: 0033:0x7f62a8321eae
Dec 31 21:00:33 apu2c4 kernel: Code: 48 8b 0d dd ee 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d aa ee 0c 00 f7 d8 64 89 01 48
Dec 31 21:00:33 apu2c4 kernel: RSP: 002b:00007ffe9b2cc548 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
Dec 31 21:00:33 apu2c4 kernel: RAX: ffffffffffffffda RBX: 000055733bf17990 RCX: 00007f62a8321eae
Dec 31 21:00:33 apu2c4 kernel: RDX: 00007f62a8824343 RSI: 0000000000003eb7 RDI: 00007f62a693e010
Dec 31 21:00:33 apu2c4 kernel: RBP: 00007f62a8824343 R08: 27d4eb2f165667c5 R09: 85ebca77c2b2ae63
Dec 31 21:00:33 apu2c4 kernel: R10: 00007f62a8315aeb R11: 0000000000000246 R12: 0000000000020000
Dec 31 21:00:33 apu2c4 kernel: R13: 000055733bf16020 R14: 000055733bf17990 R15: 000055733bf15290
Dec 31 21:00:33 apu2c4 kernel: </TASK>
Dec 31 21:00:33 apu2c4 kernel: ---[ end trace 0000000000000000 ]---
mlramd commented
From the coreboot mailing list:
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/FGODC5MC5FEQ6FXAQFPIGQFWVDRGPCT2/
On Thu, Dec 29, 2022 at 6:43 AM Julius Werner wrote:
I can confirm that this warning is a false positive, at least. We're
intentionally copying bytes from beyond the end of the header
structure in this case.I don't know what kind of kernel system detects this stuff at runtime
and how to silence it. Probably need to add a void pointer cast or
something?
metux commented
What happens on 5.x kernels ?
If it's a kernel regression, this should be reported on lkml, so we can take care of it.
We kernel maintains usually don't monitor ticket systems of individual hw vendors.