On 01/13/25 at 10:31pm, Roberto Ricci wrote: ...... > Code starting with the faulting instruction > =========================================== > 0: 0f b6 04 02 movzbl (%rdx,%rax,1),%eax > 4: 84 c0 test %al,%al > 6: 74 08 je 0x10 > 8: 3c 03 cmp $0x3,%al > a: 0f 8e 9d 00 00 00 jle 0xad > 10: 8b 8b 00 4a 00 00 mov 0x4a00(%rbx),%ecx > [ 88.485275] RSP: 0018:ffffffffa4807ce8 EFLAGS: 00010002 > [ 88.485279] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 1ffff11027fff565 > [ 88.485281] RDX: 0000000000000940 RSI: ffffffffa3a89b80 RDI: 0000000000004a00 > [ 88.485283] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffed10234c82c8 > [ 88.485285] R10: ffff88811a641647 R11: ffff88811a635e30 R12: 0000000000000000 > [ 88.485287] R13: 1ffffffff4839048 R14: 0000000000000000 R15: 000000000000003d > [ 88.485290] FS: 0000000000000000(0000) GS:ffff88811a600000(0000) knlGS:0000000000000000 > [ 88.485292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 88.485294] CR2: 000055e8c586c300 CR3: 0000000106eb0000 CR4: 00000000000006f0 > [ 88.485299] Call Trace: > [ 88.485301] <TASK> > [ 88.485306] ? die_addr (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:460) > [ 88.485313] ? exc_general_protection (arch/x86/kernel/traps.c:751 arch/x86/kernel/traps.c:693) > [ 88.485319] ? asm_exc_general_protection (./arch/x86/include/asm/idtentry.h:617) > [ 88.485324] ? next_zone (mm/mmzone.c:20 mm/mmzone.c:37) > [ 88.485336] ? calc_load_nohz_start (kernel/sched/loadavg.c:251 (discriminator 2)) > [ 88.485341] need_update (mm/vmstat.c:2032 (discriminator 2)) > [ 88.485366] quiet_vmstat (mm/vmstat.c:2065 (discriminator 2)) > [ 88.485369] tick_nohz_stop_tick (./include/linux/hrtimer.h:135 kernel/time/tick-sched.c:1044) > [ 88.485373] ? __pfx_tick_nohz_stop_tick (kernel/time/tick-sched.c:970) > [ 88.485376] ? tick_nohz_next_event (kernel/time/tick-sched.c:952 (discriminator 2)) > [ 88.485379] ? __pfx_tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:51) > [ 88.485396] tick_nohz_idle_stop_tick (kernel/time/tick-sched.c:1229) It's weird, how come the change in kexec will impact this tick-sched code. I will try to reproduce and investigate today. > [ 88.485399] do_idle (kernel/sched/idle.c:185 kernel/sched/idle.c:325) > [ 88.485403] ? __pfx_do_idle (kernel/sched/idle.c:253) > [ 88.485406] cpu_startup_entry (kernel/sched/idle.c:422) > [ 88.485409] rest_init (init/main.c:720) > [ 88.485413] ? acpi_subsystem_init (drivers/acpi/bus.c:1314) > [ 88.485417] start_kernel (init/main.c:1000) > [ 88.485422] x86_64_start_reservations (arch/x86/kernel/head64.c:495) > [ 88.485426] x86_64_start_kernel (??:?) > [ 88.485432] common_startup_64 (arch/x86/kernel/head_64.S:415) > [ 88.485437] </TASK> > [ 88.485439] Modules linked in: cfg80211 8021q garp stp mrp llc ppdev evdev input_leds intel_agp e1000 mac_hid intel_gtt pcspkr i2c_piix4 agpgart i2c_smbus parport_pc parport tiny_power_button button rfkill vhost_vsock vmw_vsock_virtio_transport_common vsock vhost_net vhost vhost_iotlb tap vfio_iommu_type1 vfio iommufd uhid hid dm_mod uinput userio ppp_generic slhc tun loop cuse fuse ext4 crc32c_generic crc16 mbcache jbd2 bochs drm_client_lib drm_shmem_helper sd_mod drm_kms_helper ata_generic pata_acpi ata_piix libata drm scsi_mod serio_raw scsi_common qemu_fw_cfg >
